Insights / Perspective / Cloud migration and infrastructure evaluation
PerspectiveLift and shift is not a strategy
Moving applications to the cloud unchanged is quick, but it often leaves cost and complexity exactly where they were. Treat the move as a first step, not the destination.
Lift and shift, moving applications from an on-premises data centre to cloud infrastructure with little or no change, has a lot going for it. It is quick. It carries relatively low technical risk. It gets you out of an ageing data centre or off hardware that is due for replacement. For many organisations, it is a sensible first move.
The problem comes when it is treated as the whole plan. Moving applications unchanged is quick, but often leaves cost and complexity untouched. The same tangled integrations, the same oversized servers, the same manual operations now run in someone else’s data centre, frequently at a higher monthly cost than before. Leaders who expected the cloud to make IT cheaper and more agile are left wondering what they paid for.
Why unchanged applications disappoint
Applications built for a data centre were designed around its economics. Servers were bought for peak demand and run continuously, because the hardware was already paid for. Capacity was generous, because adding more took months. Integrations were built point to point, because everything sat on the same network.
Cloud economics are different. You pay for capacity by the hour, so idle servers cost money. Scaling is quick, so permanent over-provisioning is waste. Managed services can replace much of the routine work of running databases, backups and patching. An application moved unchanged captures none of these benefits. It carries data-centre habits into a pay-as-you-go environment, and the bill reflects that.
Not an argument against lift and shift
For many workloads, a straight move is the right choice, especially when hardware is failing, a data centre contract is ending or an application is due for retirement in a year or two. The point is to choose it deliberately, for a reason, rather than by default.
Know why you are moving
The most important question in any cloud migration is also the one most often skipped: what are we trying to achieve? State the goal: cost, resilience, speed or retirement of hardware. Each leads to a different plan.
- If the goal is retiring hardware or exiting a data centre by a fixed date, a fast lift and shift for most systems may be exactly right.
- If the goal is lower running cost, right-sizing, scheduling and some re-platforming will be needed, because an unchanged move rarely saves money on its own.
- If the goal is resilience, the design must use multiple zones, automated recovery and tested failover, which unchanged applications may not support.
- If the goal is speed of change, the investment shifts towards automation, modern deployment practices and breaking up tightly coupled systems.
Most organisations have a mix of these goals, and that is fine. What matters is that they are explicit, agreed by leadership and used to judge success. Without them, a migration can be technically complete and still be seen as a failure.
Fix the worst first
Full modernisation of every application is rarely affordable or necessary. Modernise the few applications that cause the most pain. In most portfolios, a small number of systems account for a disproportionate share of cost, incidents and delay.
Identify them with simple questions. Which applications generate the most support tickets? Which are hardest to change? Which cost the most to run? Which hold up other projects? The answers usually point to the same handful of systems. For those, it is worth considering re-platforming onto managed services, restructuring the application or replacing it with a SaaS product.
For the rest, a lift and shift followed by right-sizing may be perfectly adequate. Some may be candidates for retirement, which is the cheapest migration of all.
A typical portfolio review sorts applications into a few groups: move as is, move and right-size, re-platform onto managed services, replace with SaaS, or retire. Making that choice application by application, against the goals agreed at the start, is what turns a migration into a strategy. It also gives the steering group a clear view of where the money is going and what each piece of work is expected to return.
Plan the second step
The most common failure pattern is not lift and shift itself. It is lift and shift with no follow-up. The migration programme ends, the team is disbanded or reassigned and the applications settle into their new home exactly as they were. Treat the move as the start of improvement, not the end.
- Before the migration finishes, agree a modernisation roadmap for the applications that matter most.
- Ring-fence budget and people for the second phase, rather than hoping to find them later.
- Set a review point a few months after migration to right-size resources based on real usage.
- Track the goals agreed at the start, and report progress against them.
The months after migration are a good time for this work. The team understands the applications in detail, having just moved them. Usage data from the cloud environment shows exactly where resources are wasted. Momentum is still high.
What leaders should ask
If you sponsor a cloud programme, a few questions will tell you whether it is set up to deliver more than a change of address. What is the goal, and how will we measure it? Which applications are we modernising, and why those? What happens the month after the last system moves? Who owns the second phase, and is it funded?
If the answers are clear, lift and shift is a sound tactic within a real strategy. If not, take a few weeks now to set the goals and identify the systems worth fixing. It is far cheaper than discovering, a year later, that the organisation has moved its problems to the cloud and is paying monthly for the privilege.
Source: Intelliversal analysis.
