A data-centre lease ends in seven months and 900 virtual machines on an on-premises hypervisor cluster have to leave. The portfolio review assigned every one of them "rehost" — rebuild each machine on native cloud instances. The team moves about 25 machines a week. Which disposition fits the constraint?
Show the full answer Hide the answer
The deciding number
900 machines at 25 a week is 36 weeks. The lease ends in roughly 30 weeks, so the assigned plan misses the only immovable date in the programme by about a month and a half — and that is the optimistic figure, because rehosting rates fall as the easy machines run out and the entangled ones remain.
The disposition menu most teams know has six entries, which grew from the five migration strategies named in 2011 and the six published in 2016. A seventh, relocate, exists precisely for this case: moving a hypervisor-managed estate to a hypervisor-compatible target without changing the application, the operating system or the virtualisation layer. The machines cross as machines. Addresses, agents, cluster membership and the operations runbooks survive.
Why relocate fits
The constraint here is a date, not a cost target and not a technical debt target. Relocate is the only disposition whose unit of work is the cluster rather than the machine, so its duration does not scale with 900. It delivers nothing else: no managed services, no elasticity benefit, no architectural improvement, and usually a licence bill that is higher than the data centre it left.
That is the trade it makes. It buys the date and defers every other decision, leaving a second, unfunded programme to replatform the estate afterwards from a position that is no better than before. Say that out loud when you propose it, because the saving the business was promised does not arrive at relocation time.
Why the other options fail
- Rehost each machine as planned. This is the right disposition for most of the estate and the wrong one for this deadline. It would be correct with eighteen months, or with 300 machines, or with a team that could sustain 35 machines a week. The review did the dispositions and never checked them against the throughput.
- Replatform the databases first. This maximises benefit per machine and is the slowest option on the menu. It adds schema work, driver changes and performance re-validation to the critical path of a deadline that is already missed. Correct for the twelve machines that stay afterwards; wrong as a wave-one strategy.
- Retain and renegotiate. Worth one conversation, and usually unavailable: the landlord's decision not to renew is frequently the reason the programme exists. Treating a renewal as a plan when it has already been refused is how programmes arrive at the last month with no option left.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| The lease is extended by a year | Rehost in waves | The date stops binding and the per-machine benefit becomes worth the time |
| The estate is under about 200 machines | Rehost | 200 at 25 a week fits inside two months of slack |
| The hypervisor is not supported on any target | Rehost, and start now | Relocate is not available at any price |
| Half the estate is already retired or retirable | Retire first then rehost | The cheapest 400 machines to move are the ones that do not move |
When this is the wrong call
Relocate is the wrong answer when the business case was approved on the strength of cloud cost savings, because it will not produce them and the credibility loss is permanent. It is also wrong when the estate is small enough to rehost inside the window, since relocate adds a platform layer that someone has to run and eventually leave. Run the throughput arithmetic before accepting any disposition table; a disposition that cannot finish in the available time is not a disposition.