I know this is an old question (related to when I'm answering) but I can say that this is something that the Cisco ACE can do using a few simple configuration directives.
Say that you have your site set up using a simple configuration similar to this:
rserver host HOST1
ip address 1.2.3.4
inservice
rserver host HOST2
ip address 5.6.7.8
inservice
serverfarm host OURWEBSITE
probe <your-probe>
rserver HOST1 80
inservice
rserver HOST2 80
inservice
class-map match-all VIP-OURWEBSITE
match virtual-address 1.1.1.1 tcp eq www
policy-map type loadbalance first-match LB-OURWEBSITE
class class-default
serverfarm OURWEBSITE
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
loadbalance vip inservice
loadbalance policy LB-OURWEBSITE
loadbalance vip icmp-reply active
This is one of the more basic type of load balancing setup that you can configure on an ACE. All it does is simply reverse-proxy requests back to the real servers. The naming conventions are simply for example puroposes; you can choose to name them whatever you'd like.
What you're wanting to do is to match the host header that comes from the client -- if it is "ourwebsite" then the request should be sent to a redirect serverfarm that forces a HTTP 30x "ourwebsite.ourcompany.org" redirect to the client.
rserver redirect REDIRECT-OURWEBSITE
webhost-redirection http://ourwebsite.ourcompany.org%p 301
inservice
serverfarm redirect REDIRECT-OURWEBSITE
rserver REDIRECT-OURWEBSITE
inservice
The above sets up the redirection object. In the "webhost-redirection" directive, you'll notice a %p and a 301. The %p is a variable that takes the path from the client request and adds it to the redirect - that way if someone has, say, http://ourwebsite/somepage.html bookmarked, the redirect will automatically send them to http://ourwebsite.ourcompany.org/somepage.html rather than sending them to a statically-configured page. It's purely optional, so if you'd rather them be sent to a configured page rather than be automatically redirected, just leave of that %p variable and replace it with the URL you want to be redirected to. The 301 makes the redirect send a HTTP code 301 - which tells the requesting client that the page has "moved permanently" to this new address.
Now we'll move to setting up the object that matches host header requests for http://ourwebsite.
class-map match-all MATCH-OURWEBSITE
match http header Host header-value "ourwebsite"
policy-map type loadbalance first-match LB-OURWEBSITE
class MATCH-OURWEBSITE
serverfarm REDIRECT-OURWEBSITE
The new class map will set up a matching class that looks for "ourwebsite" in the HTTP Host header. The matching rules use simple regular expressions so the above will not match "ourwebsite.ourcompany.org".
The second directive above, from the previously defined policy map LB-OURWEBSITE, inserts the new matching class into the load balancing policy. If the only class you have in a policy map is class-default, this new class will be inserted above that. If you already have one or more classes above class-default, you can insert this rule above any of them using class MATCH-OURWEBSITE insert-before and it will insert it above the class you specify.
Once that's all complete, it is usually a good practice to cycle the VIP by doing a no loadbalance vip inservice followed by a loadbalance vip inservice in the service policy:
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
no loadbalance vip inservice
loadbalance vip inservice
It isn't necessarily needed for the addition of a match into the load balancing policy map, but some other directives require a cycle of the VIP service policy so it is a good habit to get into.
The full configuration after setting this all up would look like this:
rserver host HOST1
ip address 1.2.3.4
inservice
rserver host HOST2
ip address 5.6.7.8
inservice
rserver redirect REDIRECT-OURWEBSITE
webhost-redirection http://ourwebsite.ourcompany.org%p 301
inservice
serverfarm host OURWEBSITE
probe <your-probe>
rserver HOST1 80
inservice
rserver HOST2 80
inservice
serverfarm redirect REDIRECT-OURWEBSITE
rserver REDIRECT-OURWEBSITE
inservice
class-map match-all MATCH-OURWEBSITE
match http header Host header-value "ourwebsite"
class-map match-all VIP-OURWEBSITE
match virtual-address 1.1.1.1 tcp eq www
policy-map type loadbalance first-match LB-OURWEBSITE
class MATCH-OURWEBSITE
serverfarm REDIRECT-OURWEBSITE
class class-default
serverfarm OURWEBSITE
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
loadbalance vip inservice
loadbalance policy LB-OURWEBSITE
loadbalance vip icmp-reply active
From there, depending on your decommission process, you could either disable the DNS entry after a time, or even modify the webhost-redirection directive to point to a page telling users to stop using the hostname to connect to the website. It's all up to your decommissioning policy.
Hope this helps!