Cloud migration for legacy apps: lift, shift or re-platform

Legacy cloud migration is not one decision. It is a set of decisions, one per module, made after you have looked at what each module actually does, how it is deployed, what it talks to and how much it costs to keep running. Lift-and-shift buys speed: the application moves to virtual machines in the cloud largely unchanged. Re-platforming buys lower running cost and manageability: the database becomes a managed service, the file share becomes object storage, the cron jobs become scheduled functions. The wrong move is to pick one strategy for the whole estate before the assessment has told you which modules deserve which.

This article sets out how we run that assessment, what the honest trade-offs are, and how a migration fits alongside the wider legacy-to-AI modernisation work that many clients want to follow it with.

What legacy cloud migration is and why it matters now

Most systems we are asked to migrate are ten to twenty years old: a monolith on a couple of on-premise servers, a relational database that has grown without a schema owner, a file share with a decade of attachments, and integrations held together by FTP drops and nightly jobs. They work. The reason to move them is rarely the cloud itself; it is that the hardware is out of support, the single person who knows the server is retiring, or the business wants to put AI, a mobile app or a partner API on top of data that is currently locked in a data centre.

Migration is therefore a means to an end. If you keep that in view, the lift-versus-re-platform question becomes simpler: lift what only needs to keep running, re-platform what needs to change.

Lift and shift vs replatform: the honest comparison

How the assessment decides per module

The assessment has to produce a table with one row per deployable unit, not a slide about the cloud. For each unit we record what it does, who depends on it, how it is deployed, what its data looks like, how often it changes, and what it costs to run and support. Then each row gets one of five dispositions.

• Retire: nobody uses it, or a report can replace it. Surprisingly common once the dependency map is drawn.
• Rehost: stable, rarely touched, no roadmap. Lift it, monitor it, leave it alone.
• Re-platform: the database, storage or scheduler is the pain point. Swap the platform underneath, keep the code.
• Refactor: the module is on the roadmap for AI or new features, and its structure blocks that. Change the code where it matters, usually behind an API layer.
• Replace: a commodity product does the job better. Email, file sharing and basic HR usually land here.

The dependency map is the part clients underestimate. Legacy modules share databases, read each other's tables directly and rely on files appearing in folders at a certain time. Every one of those links is a migration constraint. We use the same approach described in the strangler pattern: find the seams, put an interface at each one, and only then move things.

The database is the real migration

Application servers are easy to move. The database is where migrations succeed or fail. Three questions drive the plan. First, is the engine supported as a managed service? Modern versions of PostgreSQL, MySQL and SQL Server are; older or proprietary engines may not be. Second, how big is it and how fast does it change? That sets the cut-over method: a dump-and-restore weekend, or continuous replication with a short final switch. Third, who else reads it directly? Reporting tools, spreadsheets with live links and sister applications all break the moment the connection string changes.

For most mid-sized estates we recommend re-platforming the database even when the application is lifted as-is. Managed backups, point-in-time recovery and patching remove the highest-risk operational tasks from a team that no longer has a full-time database administrator.

Storage and batch jobs

File shares move to object storage, which changes how the application reads and writes files. That is a small code change with a large operational payoff. Batch jobs move to a scheduler with logging and retries. Both are cheap wins that make the lifted application easier to run and, later, easier to expose to new services.

Cloud modernisation: what to change and what to leave

Cloud modernisation is the phrase vendors use when they mean re-platform plus a little refactoring. The discipline is to change only what the roadmap needs. If the business wants an AI assistant over customer records, the customer module needs an API and its data needs to be reachable; the payroll module does not. If a mobile app is planned, the modules it will call need to move to services that scale; the rest can stay on a modest VM.

We write this down as a sequence, not a big-bang plan. Each phase moves a small group of modules, proves them in production, and only then starts the next. The application modernisation versus rewrite comparison covers why we almost never recommend a full rewrite as part of a migration.

Cost: why lift-and-shift often costs more at first

Teams are surprised when the first cloud bill exceeds the old hosting cost. The cause is almost always that VMs were sized to match the old servers, which were sized for a peak years ago, and that they run around the clock. Right-sizing after the first month, scheduling non-production environments to stop overnight, and moving the database and storage to managed services usually bring the bill down. Reserved capacity helps further, once you know which VMs are staying.

Budget for this: the migration project, then a right-sizing pass at thirty and ninety days. The pricing page shows the fixed-price programs we use for both.

A worked example

A university ran a student and finance ERP on two ageing servers, with reporting done from spreadsheets linked directly to the production database. The board wanted online admissions and a student mobile app; the IT team wanted to stop worrying about the hardware. The assessment found five deployable units and a nightly job that copied files between them. Admissions and student records were re-platformed onto a managed database with an API in front, because the mobile app needed them. Finance was lifted as-is, with its database moved to a managed service. Two legacy reporting tools were retired in favour of a read replica and a reporting layer. The nightly file copy was replaced with a scheduled job that logged its results. The mobile app and online admissions were built against the new API while the lifted modules kept running unchanged. The detail is in the university ERP modernisation case study.

Team and timeline

A migration of this kind needs a lead engineer who owns the dependency map and cut-over plan, one or two engineers for the re-platformed modules, a database specialist for the replication and cut-over, and a named person on the client side who can answer "who uses this?" quickly. The client's IT team stays involved throughout, because they will run the result.

The assessment is a Sprint Zero: ten working days, fixed price, producing the per-module disposition table, the dependency map and a phased plan. The migration itself is delivered as ReCore, our legacy-to-AI modernisation program, in eight to sixteen weeks depending on the number of modules re-platformed. Care Plans cover the right-sizing passes and ongoing operations afterwards.

Before you start: a checklist

• List every deployable unit, its owner and its last change date
• Draw the dependency map, including direct database reads from other tools
• Confirm the database engine and version, and whether a managed equivalent exists
• Identify which modules sit on the roadmap for AI, mobile or partner APIs
• Agree a cut-over window and a rollback plan per phase
• Decide who runs the platform afterwards and what they need to learn
• Baseline current hosting and support cost so the cloud bill can be compared honestly
• Check data residency and security requirements before choosing a region

Glossary

• Rehost (lift and shift): moving an application to cloud virtual machines without changing it
• Re-platform: keeping the application code but replacing the platform underneath with managed services
• Refactor: changing the application's structure so it can use cloud services or expose APIs
• Managed database: a database service where the provider handles patching, backups and failover
• Cut-over: the moment traffic moves from the old environment to the new one
• Right-sizing: adjusting compute and storage to actual usage after migration

Related reading

See the strangler pattern for how to move modules without stopping the business, embedding AI into legacy systems without a rewrite for what the migration makes possible, and our modernisation services page. Microsoft's Cloud Adoption Framework is a useful vendor-neutral read on migration dispositions, despite the name.

Assess per module, lift what only needs to survive, re-platform what needs to change, and let the roadmap rather than the cloud decide.