Lift-and-shift the VDI estate. Don't replatform it.
A 2,400-seat estate, the full cost build-up, and the one case where replatforming actually earns its keep.
Every VDI migration I’ve scoped arrives with the same instinct attached: while we’re moving it, let’s modernize it. Re-architect the desktops, refactor the apps, land on a clean managed platform. It feels responsible. On a three-year horizon it usually isn’t, and I can show you why with the only thing that settles this argument — the build-up.
Here’s the estate. 2,400 seats, a mixed Citrix-on-vSphere environment, roughly forty published apps, two of which are old enough to vote. The board wants it on AWS inside the fiscal year. The delivery team wants to replatform to a managed DaaS and refactor the app layer on the way. Both can’t be true inside the budget, so somebody has to do the arithmetic.
The cost build-up
Two paths, same estate, three-year window. Rehost lifts the existing brokered desktops onto AWS more or less as-is. Replatform re-architects to managed desktops and refactors the published apps so they run natively.
| Line item | Lift & shift | Replatform |
|---|---|---|
| One-time migration | 180,000 | 960,000 |
| Run / year | 1,920,000 | 1,440,000 |
| Run × 3 years | 5,760,000 | 4,320,000 |
| Dual-run during cutover | 120,000 | 720,000 |
| 3-year total | 6,060,000 | 6,000,000 |
| Time to cutover | 11 wks | 9 mo |
Read that bottom line carefully, because it’s the whole post. On a three-year horizon the two paths land within 1% of each other — a €60,000 gap on a six-million-euro programme, which is rounding error, not a decision. The replatform’s lower run rate (€480k/year cheaper) is real, but it spends nearly all of that saving paying down a €780k heavier migration and a dual-run tail that’s six months longer.
The run-rate saving is real. It just doesn’t arrive inside the window the business is paying for.
So the tie-breaker isn’t cost. It’s the other two columns. Lift-and-shift cuts over in 11 weeks; replatform takes 9 months, during which you carry both estates and absorb the risk of refactoring forty apps nobody fully documented. Same money, a quarter of the time, a fraction of the delivery risk. Lift-and-shift wins — not because modernizing is wrong, but because doing it during the migration double-counts the disruption.
Where replatform actually earns its keep
Extend the window and the picture flips. The €480k/year run-rate gap compounds: by year five the replatform is ~€900k ahead, net of its heavier start. So replatform pays when all three of these hold:
- The estate will run five years or more on this platform — no acquisition, no desktop strategy pivot on the roadmap.
- The app layer is stable. Refactoring forty moving targets is how a nine-month plan becomes eighteen.
- You can fund the migration separately from run — often via MAP mobilize credits, which change the build-up enough to deserve their own post.
Miss any one of those and you’re paying a premium for a saving you’ll never collect.
What I hand the deal team
Not a recommendation — a fork. Lift-and-shift if the horizon is three years or the apps are in flux; replatform only if you’re committing to this platform past year five and you’ll fund the move out of mobilize credits. One sentence, both branches priced, the break-even named. That’s a decision a sponsor can actually make, instead of a slide that says “it depends.”
The arithmetic above is deliberately public. If a number looks wrong for your estate, change it — that’s the point of showing the build-up rather than the conclusion.