A cloud migration roadmap is a plan that moves systems from your current hosting to a cloud provider in small, reversible steps. It starts with an inventory, assigns a strategy to each workload and ends each wave with a tested cutover. Most failures come from hidden dependencies and cost surprises, not from the technology itself.
What should you do first
Make an inventory of applications, databases, scheduled jobs, integrations and who owns each one. Map the dependencies between them, including the undocumented ones such as a script on a server that someone set up years ago. Interview the people who run the systems, since the documentation is usually incomplete.
Then write down why you are migrating. Cost, resilience, speed of delivery and compliance lead to different choices.
Which migration strategy fits each workload
Each workload gets one of a few strategies.
| Strategy | What it means | Effort | Fits |
|---|---|---|---|
| Retire | Switch it off | Low | Unused systems |
| Rehost | Move as is to virtual machines | Low to medium | Quick moves, tight deadlines |
| Replatform | Move with small changes, such as a managed database | Medium | Most standard applications |
| Refactor | Redesign for cloud services | High | Core products with long futures |
Do not refactor everything. Pick the few systems where the redesign pays back, and rehost or replatform the rest.
How do you order the migration
Move in waves. Start with a low-risk system to prove the landing zone, the network setup, access control and the deployment process. Then move groups of related systems together, so that dependencies do not span the old and new environments for long. Keep the most critical systems for when the team has practice.
How do you move the data
Data usually decides the timeline. Estimate the volume and the transfer time, and decide whether you can accept a short outage or need continuous replication. Test the migration on a copy and measure how long it takes. Validate the result with row counts and checks on key records before the cutover.
How do you keep costs under control
Cloud bills surprise teams that copy their old sizing. Set budgets and alerts from the first day, tag resources by owner and review the bill every week during the migration. Right-size instances after you see real usage, and switch off test environments outside working hours.
How do you cut over safely
Write a cutover plan with exact steps, owners and a time for each, and rehearse it. Decide in advance the conditions that trigger a rollback, and test the rollback itself. Keep the old environment running for an agreed period after cutover. Monitor errors and latency closely for the first days.
How do AI coding agents help
Agents speed up the repetitive parts: infrastructure code, scripts, config conversion and tests. A senior engineer still needs to review the result, particularly for security groups, permissions and data handling. See human-in-the-loop engineering for how that review works. Our overview of hosting options helps with the target choice.
What skills does the team need
A migration team needs someone who has done it before. Look for experience with your target provider, infrastructure as code, networking, identity and access management, and observability. Security knowledge matters from the first wave, because misconfigured permissions are a common source of incidents. If your team has not migrated before, adding one or two senior engineers for the duration is usually cheaper than learning through mistakes.
What this means when you hire through Miyagami
Every engineer is tested by an AI-native tech lead who works with AI every day. Senior DevOps engineers and AWS engineers join your team full-time from €5,600 a month, with a shortlist within 3 working days and no recruitment fee. We replace at our cost if the fit is wrong. See how we vet.
Short answers
How long does a cloud migration take?
It depends on the number of systems and the data volume. Small estates take weeks, larger ones several months in waves.
What are the 4 migration strategies?
Retire, rehost, replatform and refactor. Most estates use a mix.
Is lift and shift a good idea?
It is quick and low risk, and it often leaves savings on the table. Use it when speed matters, then optimise afterwards.
How do you avoid downtime?
Use replication, rehearse the cutover and keep a tested rollback plan.
