Key takeaways
- Migrating a legacy application to the cloud usually follows six steps: assess, plan, choose a migration strategy, prepare data and infrastructure, migrate incrementally, then validate and optimise.
- Rehosting (lift-and-shift) is faster and lower risk short-term, while refactoring delivers better long-term scalability and cost efficiency; the right choice depends on the app's age, architecture, and business value.
- A good cloud migration checklist covers dependencies, data, security, downtime tolerance, licensing, and rollback plans before a single line of code moves.
- Incremental migration, moving one module or service at a time, reduces the risk of downtime and lets you validate each step before moving on.
- Post-migration support and monitoring matter as much as the move itself; without it, performance and cost issues often surface within the first few months.
Migrating a legacy application to the cloud means moving an existing on-premises or outdated system to a cloud platform (such as Azure or AWS) either by rehosting it largely unchanged, replatforming with minor adjustments, or refactoring its architecture to take advantage of cloud-native features. The right approach depends on the application's age, business criticality, and how much technical debt it carries. Done well, migration reduces infrastructure costs, improves reliability, and removes the risk of running software on hardware or platforms that are no longer supported.
This guide walks through the practical steps, a checklist you can use before you start, and how to decide between rehosting and refactoring.
Why Migrate a Legacy Application to the Cloud at All?
Most organisations aren't migrating for the sake of it. Common triggers include ageing on-premises servers reaching end of life, software vendors withdrawing support for old frameworks, rising hosting or licensing costs, or a simple inability to scale during busy periods. There's also a security angle: unsupported platforms stop receiving patches, which leaves known vulnerabilities exposed indefinitely.
Cloud platforms also make it far easier to modernise incrementally afterwards, adding monitoring, automated backups, and scaling without a full rebuild.
What Are the Legacy to Cloud Migration Steps?
While every system is different, most successful migrations follow the same broad sequence.
1. Assess the current application
Map out what the application actually does, its dependencies (databases, third-party integrations, file shares, scheduled jobs), and how business-critical it is. This is also the point to identify hidden risks: hardcoded server paths, unsupported libraries, or undocumented workarounds that only one person in the business understands.
2. Define the goal and constraints
Decide what "success" looks like: lower running costs, better uptime, faster performance, or the ability to add new features that the old architecture couldn't support. Set constraints too, such as an acceptable maintenance window, budget, and any regulatory requirements (data residency, for instance).
3. Choose a migration strategy
This is where you decide between rehosting, replatforming, or refactoring (more detail below). It's rarely all-or-nothing; many migrations mix approaches across different parts of the same application.
4. Prepare data and infrastructure
Set up the target cloud environment, including networking, security groups, and identity management, before touching production data. Plan how data will be migrated and validated, and whether it needs to be synchronised during a transition period so both old and new systems can run in parallel.
5. Migrate incrementally
Rather than a single high-risk cutover, move one module, service, or user group at a time. This keeps the blast radius small if something doesn't behave as expected, and it means the business can keep operating throughout.
6. Validate, monitor, and optimise
After each stage, check performance, data integrity, and user experience against the original system. Once fully migrated, keep monitoring for a few weeks; cloud environments often reveal cost or performance patterns that don't show up in the first few days.
If you're weighing up whether your organisation has the in-house capacity to run this process alongside day-to-day work, it's worth getting an outside view early. Get in touch and we can talk through where your application sits today and what a realistic migration path looks like.
Cloud Migration Checklist: What to Confirm Before You Start
Before any migration work begins, it's worth working through a checklist to avoid nasty surprises mid-project:
- Dependencies mapped: every database, API, scheduled task, and third-party integration the application relies on
- Data migration plan: how data will be moved, validated, and kept in sync if there's a transition period
- Downtime tolerance: how much (if any) downtime the business can accept, and when
- Security and compliance: data residency requirements, access controls, and any industry-specific regulations
- Licensing: whether existing software licences are transferable to the cloud or need renegotiating
- Rollback plan: a tested way to revert if something goes wrong during cutover
- Cost modelling: realistic cloud running costs, not just the migration project cost
- Support plan: who monitors and maintains the application once it's live in the cloud
Skipping the rollback plan is one of the most common (and costly) mistakes. Even a well-tested migration can hit an unexpected issue in production, and having a tested way back is far cheaper than firefighting under pressure.
App Rehosting vs Refactoring: Which Should You Choose?
This is usually the biggest decision in the whole process.
Rehosting (often called "lift-and-shift") means moving the application to the cloud with minimal changes to its code or architecture. It's the fastest and lowest-risk option, and it's a sensible first step for applications that work fine but are held back by ageing hardware. The downside is that you don't get cloud-native benefits like auto-scaling or pay-as-you-go efficiency; you're essentially running the same application on someone else's servers.
Replatforming sits in the middle: you make targeted changes, such as swapping a self-managed database for a managed cloud database service, without a full rewrite. This gets you some efficiency gains without the cost of a complete overhaul.
Refactoring means restructuring the application's architecture to be cloud-native, often breaking a monolithic system into smaller services, adopting modern frameworks, and rebuilding parts of the codebase. It takes longer and costs more upfront, but it pays off in scalability, maintainability, and long-term running costs, particularly for applications that are central to the business and expected to keep evolving.
A practical rule of thumb: rehost when the application is stable, not central to competitive advantage, and just needs to get off ageing infrastructure quickly. Refactor when the application is core to the business, is limiting growth, or when the existing codebase is so brittle that every change carries risk. For Microsoft's own guidance on migration strategies, this same rehost-replatform-refactor spectrum (sometimes extended to the "5 Rs") is the standard framework used across most enterprise cloud adoption projects.
How ABM Software Approaches Legacy Cloud Migrations
We treat migration as an engineering discipline, not a one-off event. That means starting with a proper assessment of the existing application (often one that's been running for a decade or more on .NET Framework or older technology stacks), agreeing a realistic strategy, and then migrating incrementally so the business never faces a single high-stakes cutover night.
Our services cover the full lifecycle: custom software application development for building new cloud-native components, application modernisation for refactoring legacy codebases (often to modern .NET and Azure), and ongoing application support and maintenance once the migration is complete, so performance, security patching, and cost optimisation don't fall through the cracks after go-live.
If your organisation is weighing up a migration and wants a straightforward, jargon-free assessment of the options, get in touch and we'll talk through what's realistic for your systems, timeline, and budget.
We only use your details to reply – nothing else.
Frequently asked questions
How long does it take to migrate a legacy application to the cloud?
It depends heavily on the application's complexity and the chosen strategy. A straightforward rehost of a simple application might take a few weeks, while a full refactor of a complex, business-critical system can take several months. Incremental migration usually spreads this out further but reduces risk at each stage.
Is rehosting or refactoring cheaper?
Rehosting is cheaper and faster upfront, but it doesn't reduce ongoing running costs as much because you're not taking advantage of cloud-native efficiencies. Refactoring costs more initially but often pays for itself over time through lower infrastructure costs, easier maintenance, and better scalability.
Can a legacy application be migrated without downtime?
In most cases, yes, particularly with an incremental migration approach where modules or user groups are moved gradually rather than all at once. This typically involves running old and new systems in parallel for a period and keeping data synchronised until cutover is complete.
Do we need to rewrite our entire application to move it to the cloud?
No. Rehosting and replatforming both allow you to move an application to the cloud with little or no code changes. A full rewrite (refactoring) is only necessary if you want cloud-native scalability, better performance, or the existing codebase is too brittle to maintain as-is.
Working on something like this?
We build and modernise business systems on .NET, Blazor and Azure. Tell us what you're working with and we'll come back to you within one working day.
Get in touch