A data-centre lease expires in eleven months and will not be renewed. The team plans to rehost about 300 virtual machines with no application changes. Which benefit is the one rehosting reliably delivers and therefore the one the plan should be justified on?

The deciding property

The constraint in the stem is a date, not a cost and not a capability. Rehosting is the only one of the migration treatments whose duration is predictable enough to commit to a hard external deadline, because it deliberately changes nothing about the application. That predictability is the product.

What rehosting actually buys

• A date you can hold. Server-for-server moves have a known unit of work and can be parallelised across a large estate. Re-architecting 300 workloads cannot be scheduled with the same confidence, and the lease does not care.
• Optionality afterwards. Once workloads are on elastic infrastructure, replatforming and right-sizing become incremental and individually fundable, rather than one programme that has to succeed.
• Removal of a capital cycle. No more hardware refresh decisions that force five-year bets.

What it costs

The bill usually goes up at first, and the mechanism is straightforward: on-premises capacity was bought once for peak and idle hours were free, while rented capacity is billed by the hour whether the CPU is busy or not. An estate sized for peak and running at low average utilisation pays for its headroom every hour of the year.

So the plan must carry a right-sizing and scheduling workstream with a date of its own. Switching non-production off outside working hours is the single largest lever available, because roughly two-thirds of the hours in a week fall outside a 08:00 to 18:00 weekday pattern.

Why the other options fail

• A lower bill from the first month. This is the promise that discredits migrations. It is achievable, but only after right-sizing, reserved or committed-use purchasing and switching off idle capacity, none of which is part of rehosting. Selling the move on cost and then reporting a higher bill in month two costs the programme its credibility.
• Higher availability from redundant hardware. The provider's hardware is more redundant; your application's single instance with a local disk and no health check is not. Availability is a property of the architecture that was deliberately left unchanged. Rehosting can even reduce availability, because shared infrastructure fails in ways the application has never seen and instances are replaced rather than repaired.
• Faster feature delivery. Delivery speed is set by the application's structure, its test suite and its release process. Moving the same code to a different hypervisor changes none of them. This benefit is real for replatforming and re-architecting, and claiming it for rehosting is the most common misattribution in migration business cases.

When this is the wrong answer

If there is no deadline, rehosting is usually the wrong treatment. Absent an external forcing event, the better portfolio move is to retire and retain aggressively first, then replatform the small number of workloads where a managed substitute removes real operational load. Rehosting an estate nobody was forced to move produces a higher bill and the same applications, which is the outcome that makes the next modernisation harder to fund.