Cloud Migration Strategy: Choose Per Application

"Move everything to the cloud" is a goal, not a plan. Businesses that treat migration as one big project often end up either moving applications unchanged and paying more than expected, or getting stuck rewriting systems that never needed rewriting. A sound cloud migration strategy works application by application: it decides for each system whether to move it as it is, adjust it, replace it, rebuild it, keep it where it is or switch it off. It then sequences those moves by risk and value, with testing and cutover planned for each. This guide explains how to build that strategy, using a widely used set of migration approaches, so the move delivers business benefits rather than simply relocating problems.

Base your cloud migration strategy on clear reasons

Be clear about the reasons before choosing approaches. Common drivers include:

• Ending a data centre lease or replacing ageing hardware
• Improving resilience and recovery options
• Scaling capacity up and down with demand
• Reducing time spent maintaining infrastructure
• Enabling new capabilities, such as managed databases or analytics services

Different reasons lead to different priorities. A data centre exit favours speed; a modernisation programme favours deeper change for selected systems.

Build an application inventory

List every application and supporting system, including:

• What it does and who uses it
• Its business importance and acceptable downtime
• Technology stack, databases and dependencies
• Integrations with other systems
• Data volumes and any data residency requirements
• Licensing terms that may restrict where it can run
• Current costs and known problems

Dependencies matter most. Moving one application without the database or service it relies on can cause performance problems or outages.

The 7 Rs of migration

AWS Prescriptive Guidance describes seven migration strategies, known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect (AWS Prescriptive Guidance: migration strategies). In that guidance:

• Retire: decommission or archive applications that are no longer needed
• Retain: keep applications in the source environment, or ones you are not ready to migrate
• Rehost: also known as lift and shift, move applications without changing them
• Relocate: transfer a large number of servers at once from an on-premises platform to a cloud version of that platform
• Repurchase: also known as drop and shop, replace an application with a different version or product
• Replatform: also known as lift and reshape, move the application and introduce some optimisation
• Refactor or re-architect: modify the architecture to take full advantage of cloud-native features

The strategy for each application should be a deliberate choice, not a default.

Choose an approach per application

Questions that help decide:

• Is the application still needed? If not, retire it
• Is there a good software-as-a-service replacement? Consider repurchasing
• Does it work well and need to move quickly? Rehosting may suit
• Would modest changes, such as a managed database, bring clear benefits? Consider replatforming
• Does the business need major improvements in scalability or release speed? Refactoring may be justified
• Are there licensing, latency or compliance reasons to keep it where it is? Retain it for now

Retiring unused systems early reduces the amount of work and cost for everything else.

Worked example: a migration plan by application

The table below is a hypothetical plan for a mid-sized business. It shows how decisions might be recorded, not a recommendation for any specific system.

ApplicationBusiness importanceChosen approachReasonWaveOld intranetLowRetireReplaced by collaboration tools1Company websiteMediumRehost, then improveSimple, low risk, good first move1Reporting databaseMediumReplatform to managed databaseReduce maintenance work2Custom order systemHighReplatform first, refactor laterNeeds stability before deeper change3On-premises email serverMediumRepurchase hosted serviceMature alternatives exist2Specialist manufacturing systemHighRetain for nowVendor support tied to current setupReview later

Sequence the moves in waves

Group applications into waves. Start with low-risk systems to build skills, processes and confidence, then move more critical systems once the team has experience. Keep tightly connected applications in the same wave, or plan carefully how they will communicate across environments during the transition.

Prepare the landing zone

Before moving applications, set up the foundations in the cloud: account structure, identity and access, networking, security controls, logging, monitoring and cost tracking. Doing this once, properly, avoids each team building its own inconsistent setup. Infrastructure as code helps keep the foundations repeatable and reviewable.

Plan data migration

Data often determines how long a migration takes and how much downtime is needed. Decide whether to copy data in bulk and then sync changes, or migrate during a planned outage. Validate data after moving it by comparing counts, totals and samples of individual records. Keep the source available until you are confident in the target, and agree in writing when it can finally be switched off.

Test and plan cutover

For each application, test functionality, performance, integrations and security in the cloud before switching users over. Write a cutover plan covering timing, steps, communication, checks and a rollback route. Agree in advance who decides whether to proceed or roll back.

Prepare people, not just systems

Migration changes how teams work. Operations staff need new skills for cloud monitoring, access management and cost control. Developers may need to learn managed services and new deployment pipelines. Support teams need updated runbooks. Plan training early, involve the people who run each application in its migration and agree who owns each system after the move. A technically successful migration can still disappoint if nobody feels confident running the new setup.

Control costs from the start

Moving applications unchanged can cost more than expected if resources are oversized or left running unnecessarily. Tag resources by application and owner, set budgets and alerts, and review usage after each wave. Right-size resources once you see real usage.

Modernise after you move

For many applications, the best path is to move first with minimal change, then improve once they are stable in the cloud. Our guide to moving from a monolith to microservices covers when deeper re-architecture makes sense and how to approach it gradually.

Get the right expertise

Migration needs skills in cloud platforms, networking, security, data and the applications themselves. Our guide to cloud architecture consulting explains how outside expertise can help with planning and design.

Frequently Asked Questions

What is a cloud migration strategy?

It is a plan that decides, for each application, whether to retire, retain, rehost, relocate, repurchase, replatform or refactor it, and in what order to move systems.

What are the 7 Rs of cloud migration?

AWS Prescriptive Guidance lists retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect.

Should every application be refactored for the cloud?

No. Refactoring is costly and suits applications that need major improvements; many systems are better rehosted, replatformed, replaced or retired.

How should migrations be sequenced?

In waves, starting with lower-risk applications to build experience, keeping tightly connected systems together and moving critical ones once processes are proven.

Plan a migration that delivers value

We assess applications, choose migration approaches and plan waves, testing and cutover. See our custom app development services, or talk to us about your cloud migration strategy.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.