Lifting and shifting a monolithic thirty-year-old application into the public cloud without refactoring the code
Lifting and shifting a monolithic thirty-year-old application into the public cloud without refactoring the code

The Cloud Is Not a Skip

A consultancy has told a large organisation that the way to modernise a thirty-year-old application is to pick it up exactly as it is and put it in a public cloud environment without touching a single line of code. The pitch is called "lift and shift," it came with very compelling slides, and it will be funded by people who will have moved on before the invoice becomes uncomfortable.

Here is what lift and shift actually is. You have lived in the same house for thirty years. The boiler is held together by institutional memory and a particular kind of prayer. There is a drawer in the kitchen that has not been opened since 2007 because something in it rattles in a way that makes everyone nervous. The electrics were signed off by a man who is now retired and, on reflection, may not have been a qualified electrician. You know where the cold spots are. You know not to use the downstairs bathroom between 2am and 4am on the last Tuesday of the month. You understand this house.

And then someone suggests a fresh start. A new place. More modern. Better infrastructure. Excellent broadband. The proposal — delivered with genuine enthusiasm — is to move every single item you own into the new house without throwing anything away, without checking whether it still works, and without asking why the box labelled "IMPORTANT — DO NOT OPEN" has been in the loft since 1997. Just move it. Put it all in the new place. Call it transformation.

The new house is excellent. You are getting nothing from it.

What Actually Migrates

The technical debt does not migrate. The hardcoded IP addresses do not care that they are now running in an environment designed around ephemerality. The business logic written by someone who was, based on the evidence, working through something emotionally difficult that afternoon in March 1994 — that logic comes too. The scheduled jobs that must not be disturbed, the latency assumptions baked in when the application and the server lived in the same room, the complete absence of any capacity to scale horizontally: all of it arrives in the cloud, intact, unexamined, now billing you for compute, storage, data transfer, and approximately eleven other cost categories that your on-premises model never surfaced with this level of specificity.

On-premises infrastructure is largely predictable. You bought the server. You know what it costs. Cloud infrastructure is built around applications designed to exploit its elasticity. A monolith that cannot distribute its load, cannot tolerate an interrupted instance, and was last meaningfully refactored when Britpop was still a going concern does not become a cloud-native application because you moved it to a different data centre. It becomes an expensive monolith.

Running the same inefficient code on faster, more expensive, more flexible infrastructure does not make the code less inefficient. It makes it expensively inefficient.

The cost savings that justified the migration to the board — the ones from the slide near the front, before the Gartner quadrant nobody read — are real. They are real for applications designed to take advantage of cloud. They are approximately as real for an unreformed monolith as a premium gym membership is useful if you exclusively use it to sit in the car park.

The Human Cost That Doesn't Appear on the Architecture Diagram

There is a team. There is almost certainly a team that has spent years developing a relationship with this application and its infrastructure that is intuitive, hard-won, and partially inexplicable even to themselves. They know the temperamental server. They know which workaround was implemented after an incident in 2011 that nobody documented properly but everyone remembers. They have built expertise in an environment they understand.

Lift and shift changes the operational environment significantly enough that this expertise partially depreciates overnight. The team is now managing infrastructure through consoles they were not trained on, debugging network issues in an environment they do not fully own, and doing all of this while the application they are responsible for remains as internally opaque as it ever was. This is not a failure of the team. It is a structural unfairness that organisations impose on their people when they change the environment without changing the support, the training, or the honest acknowledgement that they have just made a difficult job considerably harder.

The consultancy, at this point, has generally moved on to the next engagement.

The Staging Post That Becomes the Destination

None of this means lift and shift is always indefensible. Done with clear eyes, as a deliberate bridge between an expiring data centre contract and a genuine modernisation programme with real funding, real timelines, and real accountability — it is pragmatic. A staging post. A way of buying time to do the harder, more expensive, more necessary work of actually addressing thirty years of accumulated technical decisions made by people who could not have anticipated what the infrastructure landscape would look like today.

Done as a substitute for strategy, it is a very expensive way of not solving the problem. The monolith moves postcode. The monolith remains a monolith. What the organisation gets, in exchange for the migration cost, the operational disruption, and the cloud bill that will require its own meeting in approximately eighteen months, is the ability to say at the next all-hands that the business is now in the cloud.

Which is true. Technically.

The application that runs payroll, processes orders, and is in a very real sense the business — that application is still running on logic written by someone who has been retired in Portugal since 2009. The cloud is just where it lives now. Portugal remains lovely, apparently.

The hard question — the one the slide deck does not linger on — is whether anyone in the room has the appetite to fund what actually needs to happen next, or whether the cloud migration will be quietly declared a success and the next set of slides will be about something else entirely.