A cloud migration strategy is decided one application at a time, and each application can take one of seven routes. The explainers on the first page of search results define those routes and stop there. They leave out the inputs that pick the route: usage data, dependencies, and the downtime your users can accept. This post puts those inputs in order. The post also treats two of the seven routes (retire and retain) as decisions made before anything moves. A definition comes first, then the routes.
What is a cloud migration strategy?
A cloud migration strategy is the plan for moving each business application to the cloud, or deciding it should stay where it is. The plan names a route per application, a sequence, and a downtime window. Choosing between on-premises and cloud comes first, and this plan follows that choice.
That first choice has its own guide. The post on on-premises versus cloud compares the two on cost, data rules, and fit. Read it if you are still deciding whether to move at all.
The strategy is the layer after that decision. The strategy turns "we will move to the cloud" into a list of applications, each with a route, an order, and a date. Writers use the terms cloud computing migration strategy, cloud migration, and cloud migration process loosely, and the terms overlap. The test of a real strategy is that it names a route for each application.
Planning at the application level matters because applications differ. A reporting tool used by 3 people needs a different route from the order system that runs the business. A single route for everything fits neither. Keep the first audit light: a spreadsheet with one row per application is enough to start, and it grows into the dependency map later.
Burhani covers this work under cloud solutions, where architecture and migration are scoped with data location and recovery plans, plus the running costs afterwards.
What are the seven cloud migration routes and when does each fit?
AWS Prescriptive Guidance names seven strategies: retire and retain; rehost and relocate; repurchase and replatform; and refactor. Rehost moves an application unchanged, and replatform adds light optimization. A repurchase swaps it for a product, while a refactor redesigns it for the cloud. Retire and retain decide whether it moves at all.
Route
What it does
Choose when
Evidence to check
Route: Retire
What it does: Switches the application off
Choose when: Nobody uses it
Evidence to check: Usage and connection logs
Route: Retain
What it does: Leaves it where it is for now
Choose when: Residency, risk, or a dependency blocks a move
Evidence to check: Dependency map, data rules
Route: Rehost
What it does: Moves it unchanged
Choose when: Code is sound, platform is ageing
Evidence to check: Stable behaviour
Route: Relocate
What it does: Moves a platform as is
Choose when: A cloud version of the platform exists
Evidence to check: Platform compatibility
Route: Repurchase
What it does: Replaces it with a product
Choose when: A product covers the function
Evidence to check: Process fit, data extraction
Route: Replatform
What it does: Moves it with light changes
Choose when: A managed service cuts running costs
Evidence to check: Database or runtime can change alone
Route: Refactor
What it does: Redesigns it for the cloud
Choose when: The design blocks the roadmap
Evidence to check: Test coverage, unclear modules
The routes come from the AWS guidance, which a cloud provider wrote for its own platform. Read it as one provider's view. The catalogue of options is still clear, and the logic carries over to other clouds.
The guide calls refactor the most complex of the seven and the most costly, and it does not recommend refactor for large migrations. Its advice is to rehost, relocate, or replatform first and to modernize the application after the move.
Relocate is the least familiar route. Relocate moves a platform, such as a virtualization layer, to a cloud version of the same platform, with no new hardware, rewrites, or changes to operations. The application keeps serving users during the move.
Repurchase has its own use cases in the guide. A move from a traditional licence to a software-as-a-service product is one. Replacing a custom application with a vendor product, to avoid recoding it, is another. Assess the product against your requirements first, especially security and compliance.
Fill the table per application. A portfolio of 30 applications will not land on one route. Expect a mix.
Why decide to retire and retain before you move anything?
Retire and retain shrink the migration before it starts. AWS treats applications under 5% CPU and memory use, or with no inbound connections for 90 days, as candidates to retire. Data residency and dependencies, plus recent upgrades, are reasons to retain. Moving an application nobody uses is effort for nothing.
The retire list gives more reasons than usage. No business value in keeping the application is one. The cost of hosting and maintaining it is another, and so is the security risk of an operating system that is no longer supported. The page also describes idle applications, which average between 5% and 20% CPU and memory use over 90 days.
The retain list is just as practical. Residency requirements can keep an application where it is. So can a dependency on another application that must move first, a recent upgrade that you want to recover value from, or specialized hardware with no cloud equivalent.
Take an illustrative audit row. An archive viewer has 3 users and no inbound connection for 90 days; it holds no data that must stay, and nothing calls it. The row says retire. A payroll system with 400 users and a data residency rule says retain, at least for now.
Run a one-page audit before you plan any route. List each application, how many people use it, its last inbound connection, where its data must stay, and what depends on it. The thresholds come from AWS guidance, and your own policy may differ. Set yours and write them down.
Every application you switch off or leave alone is a migration you never pay for.
How does a dependency map set the order of migration?
A dependency map lists what each application calls and what calls it. Applications with no dependants move first. An application that others rely on waits until those others have moved, which AWS lists as a reason to retain it for now. The map also exposes shared databases that must move as one.
Build the map as a simple table with four columns: application, calls, called by, and data location. Fill it from the people who run each system, and check it against network logs where you have them. People forget the small integrations, such as a nightly file transfer that nobody owns.
The sequence follows in three steps. Move the applications with no dependents first, since a mistake there affects nobody else. Shared databases travel with the applications that use them. The central systems, the ones everything calls, come last.
Surprises appear in the map. A reporting tool that looked independent reads from the order database. A planned retirement turns out to feed a monthly invoice run. Finding these on paper is cheap, and finding them during a cutover is not. Group the sequence into waves. A first wave of two or three low-risk applications teaches the team how the process feels, before the central systems move. Each wave ends with a review of what went wrong.
A later post on cloud migration services shows how to turn the map and the routes into a scope that every provider can quote against.
How long should the downtime window be?
Set the window per application, based on the cutover method you choose. The AWS guidance notes that rehost keeps the application serving users during the move and that downtime depends on the cutover strategy. Agree on the window with the people who use the application, and write it into the plan.
Three inputs decide the window. The cutover method comes first. A method that keeps the old system running until the new one is ready needs less downtime than one that stops the old system and then copies the data. Data volume is second, because more data takes longer to copy. User hours are third, since the best window falls when few people are working.
We state no duration here, because it depends on the application and the method. Timelines are agreed per project after discovery. A plan that quotes one downtime figure for every application has not looked at them.
Write the window into the plan as an agreement with the people who use the application. Add a rollback point, which is the moment after which going back costs more than pushing forward. A window without a rollback point is a hope. Agree on both together.
Where does Burhani Technologies fit when you build a cloud migration strategy?
Burhani Technologies scopes cloud work around workload and migration, data location and recovery, plus operating costs. Engineers on our team work across Azure and AWS, plus Google Cloud, and recommend a route per application after discovery. We make no partnership or certification claim here.
→ Describe your application list and where the data must stay, and book a free consultation.
FAQs on cloud migration strategy
What is a cloud migration strategy?
A cloud migration strategy is a plan that gives each application a route to the cloud, or a decision to stay put, plus a sequence and a downtime window. The plan starts from evidence such as usage and dependencies, and it is made per application, because one route rarely fits a whole portfolio.
What are the 7 Rs of cloud migration?
The 7 Rs, in the wording of AWS Prescriptive Guidance, are retire and retain; rehost and relocate; repurchase and replatform; and refactor. The first two decide whether an application moves at all. The other five describe how it moves, from unchanged at the low end of effort to redesigned at the high end. Pick per application.
What is the difference between rehost and replatform?
Rehost moves an application unchanged, so it runs on rented infrastructure as it did before. The replatform route adds light optimization, for example, moving a database to a managed service. That takes more effort up front and can cut running costs later.
What is a dependency map?
A dependency map is a list of what each application calls and what calls it, with the location of its data. The map sets the order of migration, because applications that others rely on must wait. Shared databases show up on it too, and they have to move together with the applications that use them. Build it before you pick any route.
When should an application be retired before any migration?
Among the signs AWS lists are an average CPU and memory use below 5% and no inbound connections for the last 90 days. The guidance also names no business value and the risk of unsupported software. Check usage logs first, and confirm with the users before you switch anything off.
What is the cloud migration process?
The process runs in five steps: audit the applications, choose a route for each, sequence them with a dependency map, migrate in waves, and review. Each wave includes testing and a rollback point, and the downtime window is agreed per application. The plan changes as the waves teach you.
Which route will your first application take?
Decide to retire and retain first, then give each remaining application one route.
→ Send us your application list and get in touch.
