Planning a legacy application migration to the cloud

Most organizations have at least one application that everyone depends on and nobody wants to touch: an order system on an aging server, a database only one person understands, a vendor product past its support date. Moving it to the cloud can reduce risk and cost, or it can move the same problems to a more expensive place. The difference is almost entirely in the planning.

What counts as a legacy application, and why migrate it now?

A legacy application is software that still does important work but runs on technology that is hard to support, secure or change. Age alone does not make an application legacy. An old system that is stable, patched and well understood may be fine where it is.

Good reasons to migrate include hardware or operating systems reaching end of support, a data center lease ending, security findings you cannot fix in place, and key knowledge held by people who are leaving. "Everyone else is moving to the cloud" is not a reason. Write down the business driver for each application, because it determines the strategy.

Which migration strategy fits each application?

AWS describes seven migration strategies, known as the 7 Rs. Microsoft's Cloud Adoption Framework uses a similar list and splits the heavier options into refactor, rearchitect and rebuild, and calls repurchase "replace".

Two pieces of vendor guidance are worth taking seriously. AWS calls refactoring the most complex and costly strategy and, for large migrations, recommends rehosting, relocating or replatforming first, then modernizing after the move. Microsoft warns that rehosting does not fix existing performance, reliability or architectural problems, and suggests rehosting only when you are confident a workload will not need modernizing for at least two years.

How do you assess the portfolio and its dependencies?

Build the inventory

Before choosing strategies, build an inventory. For each application, record:

• The business owner and the number and type of users.
• What breaks, and for whom, if it is unavailable for an hour or a day.
• Operating system, database, language and framework versions.
• Data volume and growth.
• Every inbound and outbound integration.
• Licensing terms, including whether licenses can move to the cloud.
• Compliance or data residency requirements.
• Known problems, workarounds and the people who understand it.

Tools help with the technical half. Azure Migrate is a free Microsoft service for discovering servers, assessing Azure readiness, estimating cost and analyzing network dependencies between servers. On AWS, Application Discovery Service is no longer open to new customers; AWS points them to AWS Transform instead. Neither tool can tell you who owns a system or what the business would accept as downtime. That comes from interviews.

Map dependencies and plan the data migration

Dependencies cause more failed cutovers than anything else. Discovery tools show network connections, but look for the ones they miss: scheduled jobs that drop files on a share, reports in Excel or Access with a direct database connection, hardcoded IP addresses, an email relay only the old server can use, and batch processes that run once a quarter.

Group applications that must move together into migration waves. An application and the database three other systems read from usually belong in the same wave, or you need a plan for cross-environment latency in between.

For data, choose between a one-time copy during a downtime window and continuous replication. AWS Database Migration Service, for example, supports one-time migrations or ongoing replication to keep source and target in sync until cutover. Plan data cleanup explicitly. Migration is when duplicate and orphaned records surface, and someone with business knowledge has to decide what to keep.

How do you plan cutover, testing and rollback?

Downtime and cutover

Agree with the business owner how much downtime is acceptable and when. A distribution business may tolerate a Sunday night outage; it will not tolerate one during month-end invoicing.

Microsoft's Cloud Adoption Framework sets out a sequence for a near-zero downtime cutover that is useful whichever cloud you choose:

1. Freeze changes to the source system, with a defined emergency change process.
2. Hold a readiness review with every support team, including agreed rollback criteria.
3. Replicate data and do not proceed until replication lag reaches zero.
4. Pause writes to the source, complete the final sync and validate data integrity with checksums or hashes rather than row counts alone.
5. Switch traffic by updating DNS and load balancers.
6. Monitor performance, errors and user access closely for the first 24 to 48 hours.
7. Keep the source environment available as a fallback until the new one is stable.

Testing and rollback

Test in layers: functional tests of core transactions, integration tests with every connected system, performance tests at realistic peak load, and user acceptance testing by the people who use the application daily. Test restoring from backup in the new environment before you need to.

Rollback criteria should be specific and agreed in advance, for example: "Roll back if order entry fails for more than 30 minutes or if invoice totals do not reconcile." Decide who makes the call. Announce success only after application owners and business users confirm the system works.

What should the cost baseline include?

You cannot judge a migration's cost without knowing today's full cost. Include hardware depreciation and replacement, data center or colocation fees, power, software licenses and support contracts, backup and disaster recovery, and staff time spent maintaining the system.

On the cloud side, estimate compute, storage, network egress (data leaving the cloud), managed service fees, licenses, monitoring, backup and the support plan. Budget for a period of running both environments in parallel.

The FinOps Foundation defines FinOps as an operational framework and cultural practice that creates financial accountability through collaboration between engineering, finance and business teams. Its lifecycle has three phases: Inform (visibility and allocation of costs), Optimize (improving rates and usage) and Operate (making those improvements continuous). In practice, the basics are tagging every resource with an owner and cost center, setting budgets with alerts, and reviewing spend monthly with the application owner. Azure Migrate's business case feature can compare on-premises and Azure costs as a starting point.

Security and identity during migration

Treat the migration as a chance to fix access, not copy it. Connect the application to your central identity provider, such as Microsoft Entra ID or Active Directory, so leavers lose access in one place. Apply least privilege to every account and network rule rather than reproducing broad firewall rules from the old data center.

Move passwords and connection strings out of configuration files into AWS Secrets Manager or Azure Key Vault. Turn on logging for administrative actions from day one, and confirm encryption for data at rest and in transit. Service accounts with passwords that have not changed in years are common in legacy systems; rotate them as part of cutover.

Illustrative example: Consider a logistics company running its dispatch application on an on-premises Windows server with a SQL Server database. The assessment finds a nightly job that exports delivery confirmations to a file share read by the finance system, which nobody had documented. The team rehosts the application server, replatforms the database to a managed SQL service, and replaces the file share job with an API call the finance system can consume. Automated exception routing for failed deliveries is scoped as a second phase, once the migrated system has run cleanly through a full month-end.

What gets underestimated

These items are commonly underplanned:

• Dependencies nobody documented, especially scheduled jobs and reporting connections.
• Data cleanup and the business decisions it requires.
• Licensing rules for moving database and operating system licenses.
• Latency for applications that make many small calls to a database now in a different location.
• The cost and effort of running two environments in parallel.
• Training and communication for users whose screens or logins change.
• Decommissioning the old environment, which often slips and keeps costs running.

When should you add AI or automation, and when should you wait?

Add AI or automation during the migration when you are already changing that part of the system. If you are refactoring the order module, designing it with a clean API and structured event data costs little extra and makes later automation far easier. The same applies if the migration forces you to replace a manual file transfer anyway.

Wait when the migration is a rehost with a tight deadline, when the process owner is unclear, or when the data is not yet trustworthy. Adding a new AI workflow to an application while it moves makes it hard to tell which change caused a problem. Microsoft's guidance makes a similar point about modernization: do it during migration when the team has the skills and time, and defer it otherwise.

A practical middle path is to build the foundations during migration (APIs, event logs, cleaner master data) and add AI once the application is stable. Our pillar guide on running AI in production on AWS and Azure covers what that second phase needs.

How Kastling approaches legacy application migration

We start with the business driver and the people who depend on the application, then assess systems, data and dependencies before recommending a strategy for each application. AWS and Azure specialists join the engagement as the work requires. Proposals state who owns the cloud accounts, access and running costs, and whether monitoring, backups and incident response are included, because hosting does not include them automatically.

This work sits within our AI & Cloud Infrastructure service. If the application is also carrying years of shortcuts, read technical debt in business systems before you decide how much to change during the move.