Relocate Disposition

A data-centre lease ends in seven months. 900 virtual machines have to leave. The portfolio review assigned every one of them to rehost, and the team rebuilds about 25 machines a week on native cloud instances. 900 at 25 a week is 36 weeks against a 30-week deadline, and that is the optimistic figure, because rehosting rates fall as the easy machines run out and the entangled ones remain.

Every other treatment on the disposition menu has the machine or the application as its unit of work, so its duration is proportional to the size of the estate. Relocate is the exception: it moves a hypervisor-managed cluster to a target running the same hypervisor, leaving the application, the operating system and the virtualisation layer alone, so addresses, agents, cluster membership and the existing runbooks survive. Gartner named five migration strategies in 2011 and an AWS post expanded them to six in 2016, which is the list most people learned; AWS Prescriptive Guidance now names seven, and relocate is the addition.

Why it matters

Modernisation programmes fail on dates more often than on technology, and the date in a data-centre exit is set by a landlord. Relocate is the only disposition that can meet a date the per-machine rate cannot.

It also catches a specific mistake: accepting a disposition table built from application attributes without checking it against the team's throughput. A table assigning rehost to 900 machines and a team that moves 25 a week are not a plan, and the gap is usually found with three months left.

Implementation patterns

• Derive the throughput first. Use the achieved rate from the first two waves, not the planned rate, and recompute the finish date weekly. If the projection passes the hard date, effort does not fix it.
• Treat relocation as wave zero. Each machine still needs a real treatment afterwards, and that follow-on programme must be funded in the same decision or it will not happen.
• Retire ahead of the move. The cheapest machines to relocate are the ones that do not travel; a pass that retires 15 to 30% of a long-lived estate is normal.
• Verify the licence position before committing, because hypervisor and operating-system licensing on a provider-hosted cluster is frequently the largest new line and the item that breaks the approved case.
• Measure the inter-machine flows anyway, since anything left behind on a user-facing path picks up a round trip per call.

Industry example

Relocate exists in the frameworks because of hypervisor-based estates and the compatible cloud services that run them, VMware Cloud on AWS being the service that prompted the seventh entry. The archetype to reason from is an enterprise application vendor's own internal estate, in the position a vendor such as SAP occupies: thousands of long-lived machines and a support matrix that pins operating-system versions. Rebuilding each machine natively invalidates that matrix machine by machine, so the hypervisor-level move keeps every certification intact while the date is met. No programme is attributed here; the constraint shape is what transfers.

Failure scenarios

• The case was approved on cloud savings. Relocate does not produce them and often costs more than the data centre, so credibility is spent and the follow-on work becomes unfundable.
• Wave zero becomes the end state. The deadline is met, phase two is never funded, and the estate sits on a pricier platform with the same architecture for years.
• The hypervisor version is unsupported on the target, discovered late, which removes the option with months fewer to work in.
• Latency to what stayed behind. A chatty pair exchanging 200 messages per user action becomes unusable.
• Operational complacency, because the runbooks still work, so the new platform's noisy-neighbour behaviour is found during an incident.

Trade-offs

When not to use it

Do not relocate when the estate fits in the window. 200 machines at 25 a week is two months, and rehosting leaves no extra platform layer to operate and later leave. Relocate is bought with a schedule constraint; without one it is deferral at a premium.

Do not choose it when the approved benefit is cost reduction or elasticity, because it delivers neither, and not before an honest retire pass, which can shrink 900 machines to 500 and change which disposition is needed at all.

Interview question

Q: "Your lease ends in seven months. There are 900 virtual machines on a hypervisor cluster and your team has demonstrated 25 rehosts a week. The portfolio review says rehost everything. What do you tell the steering committee?"

What a strong answer covers: the arithmetic first, since 36 weeks against 30 settles it before any technical argument; relocate as the disposition whose duration does not scale with the estate; the explicit statement that it buys the date and none of the benefits, so the approved cloud saving will not appear; a request to fund the follow-on replatforming in the same decision; and the licence check that most often breaks the new case. A strong answer names what would flip it: a lease extension, or an estate under about 200 machines.

Quick check

Quiz: 900 machines must leave in 30 weeks and the team rehosts 25 a week. Which disposition fits, and what does it fail to deliver? — Relocate, because its unit of work is the cluster rather than the machine; it delivers no managed services, no elasticity and usually a higher bill.

Flashcard: The disposition menu has six entries and a lease expires in seven months. What is the seventh? — Relocate: a hypervisor-level move with the application, operating system and virtualisation layer unchanged, chosen when the binding constraint is a date the per-machine rate cannot meet.