A practical cloud migration checklist

When a cloud migration goes wrong, it's usually because something was moved before anyone properly understood it. Copying a server across is the easy bit. What catches people out is not knowing exactly what they run, which systems lean on each other, or how they'll tell that the move actually worked. A good cloud migration checklist turns each of those questions into a task with a name and a date next to it.

You can use the steps below as your cloud migration plan for AWS (Amazon Web Services), Microsoft Azure or Google Cloud. The tools have different names on each, but the work is the same. The checklist is general advice for any of them. Our own cloud migration work is on AWS and Azure.

The cloud migration plan at a glance

Five stages and eight steps

1. UnderstandInventory, links.Steps 1, 2
2. PrepareData, security.Steps 3, 4
3. TestAgainst a baseline.Step 5
4. Key stepCut overWith a way back.Steps 6, 7
5. OptimiseTrim the costs.Step 8

Which migration approach suits each system?

Don't pick one approach for everything. Decide system by system, and you'll probably end up using a mix of the four below.

Four ways to move a system

Rehost

Move it as it is. This is the fastest route.

• EffortLow
• Cloud benefitLow

Replatform

Move it with a few managed parts.

• EffortMedium
• Cloud benefitMedium

Refactor

Rebuild parts to use the cloud fully.

• EffortHigh
• Cloud benefitHigh

Retire

Switch off what nobody needs.

• EffortVery low
• Cost savingHigh

Treat this as a rough guide. The right choice depends on how much each system matters to your business.

Rehost, often called lift and shift, copies the server as a virtual machine (a software version of a physical computer) with tools such as AWS Application Migration Service or Azure Migrate. It's the right call when you have a hard deadline to leave a data centre. The system will still work exactly as it always did.

Replatform means swapping a few parts for managed services on the way. You might move a PostgreSQL or SQL Server database onto Amazon RDS or Azure SQL Database, where the provider handles patching, backups and failover, or packaging the application in Docker containers (a standard way to bundle software with everything it needs).

Refactor changes the code or architecture, for example splitting a large application into smaller services on Kubernetes (a system that starts, scales and restarts containers automatically). It takes the most work, so save it for the systems where growth, reliability or how quickly you can ship changes really matter.

Retire is the cheapest move of all. When you do a proper inventory, you'll almost always find something nobody uses any more. You may also hear about retain (leave it where it is for now) and repurchase (replace it with a subscription product). Both are perfectly good choices, as long as you make them on purpose rather than by default.

Step 1: build a complete inventory

You can't plan a move for something you don't know you have. So start by listing every system, including the quiet ones.

• Every server, database and application, with its operating system, versions and where it runs.
• Size and load, including your busy periods, such as month end.
• An owner for each system who can answer questions and give the move a yes or no.
• Licences. Some won't transfer to the cloud, and others cost more once they're there.
• A baseline of today's response times, error rates and monthly running costs.
• The approach you've chosen for each system.

Step 2: map the dependencies

A billing application might read from a customer database, send files to finance every night and rely on a shared login service. Move the billing application on its own and something will break, and it's often days before anyone notices.

• Draw the connections, including scheduled jobs and file transfers that only run overnight.
• Use discovery tools such as Azure Migrate or AWS Transform to catch the connections everyone forgot about.
• Find hardcoded IP addresses in code and configuration, because they stop working as soon as servers move.
• Group systems into move waves, keep closely connected systems in the same wave, and start with the waves where little can go wrong.

Step 3: plan the data transfer

Moving the data is usually the slowest part, and the one most likely to hurt. Work out how it will travel, how long that will take, and how you'll prove afterwards that nothing went missing.

• Measure the volume. Hundreds of gigabytes can go over the network. Many terabytes may need a physical transfer, such as Azure Data Box or AWS Data Transfer Terminal.
• Keep downtime short. Tools such as AWS Database Migration Service copy the data across, then keep that copy up to date with live changes until you switch.
• Clean before you move, so you aren't paying to store records nobody needs.
• Check the result with record counts and checksums (a fingerprint of the data).
• Restore a backup in the new environment. It's the only way to know your backups really work.

Step 4: set up security before any data arrives

• Identity and access. Use IAM (identity and access management) to give each person and service only what it needs, with multi factor sign in for every administrator.
• Private networks for your databases, with security groups or firewalls deciding what traffic gets in.
• Encryption at rest and in transit, with one named person who owns the keys.
• Secrets such as passwords and API keys belong in a secrets manager. Never leave them in the code.
• Audit logs such as AWS CloudTrail or the Azure Activity Log, plus a cloud region that matches where your data is legally allowed to live.

If you'd like a second pair of eyes, our application security services include cloud setup reviews and penetration testing before go live.

Step 5: how should you test a migrated system?

A system that starts up hasn't passed anything yet. Compare each one against the baseline you recorded in step 1.

• Functional tests of the main tasks your users actually do each day.
• Integration tests for every connection on your dependency map.
• Load tests with tools such as k6 or JMeter, to check the system stays fast and scales under pressure.
• Failure tests. Stop a server on purpose and make sure the system recovers on its own.
• User acceptance, approved in writing by the system owner.

Step 6: plan the cutover

The cutover is the moment your traffic switches to the new system. Write it down as a timed runbook, a step list with a clock time and a named person against every task.

• Pick a quiet window and tell your users in plain words what will change for them.
• Lower DNS TTL values a few days early. The TTL (time to live) controls how long your web address lookup is cached, so a short one makes the switch quick.
• Freeze changes to the old system, then run a final data sync and check the record counts match.
• Switch traffic and run quick smoke tests (a fast check that the basics work) while you watch error rates. Agree beforehand the points where you'll decide to carry on or stop.

A calm cutover night is almost always the result of plans, tests and a way back that were written weeks earlier.

Step 7: write a rollback plan for every move

• Keep the old environment running, and don't touch it until the new one has proved itself.
• Decide the trigger in advance, for example errors above an agreed level for 30 minutes.
• Plan for new data. Anything written to the new system before a rollback has to go somewhere.
• Rehearse it in a test environment, so the team already knows the steps and how long they take.
• Set a retirement date for the old environment once you're confident you won't need it.

Step 8: how do you keep cloud costs under control?

• Tag every resource with its system, owner and environment.
• Set budgets and alerts in AWS Budgets or Azure Cost Management.
• Right size after a few weeks, once you can see real usage and shrink anything that's too big.
• Commit where usage is steady, using reserved capacity or savings plans.
• Switch off idle test environments at night and over weekends.
• Use infrastructure as code, describing servers and networks in files with a tool such as Terraform, so nothing is created by hand and forgotten.

The complete cloud migration checklist

1. Agree the goal and how you will measure success.
2. Build the inventory and record a baseline.
3. Choose an approach for each system.
4. Map dependencies and group systems into waves.
5. Build the target environment with security in place.
6. Plan, run and validate the data transfer.
7. Test function, integrations, load and recovery.
8. Write and rehearse the cutover runbook and rollback plan.
9. Switch over and keep the old system ready.
10. Set up cost monitoring, right size and retire the old environment.

How long does a cloud migration take? If you have a handful of simple systems, a few weeks can be enough. A large estate can take several months, moved in waves. To give you a feel for it, a mid sized estate moved in two waves might plan in weeks 1 to 3, build the secure target in weeks 3 to 5, move and test wave one in weeks 5 to 8 and wave two in weeks 8 to 11, then cut over and tune costs in weeks 11 to 12.

Example: a mid sized estate moved in two waves

PlanPlan: weeks 1 to 3

Secure targetBuild the secure target: weeks 3 to 5

Wave oneWave one, move and test: weeks 5 to 8

Wave twoWave two, move and test: weeks 8 to 11

Cutover and costsCutover and cost tuning: weeks 11 to 12

StartWeek 3Week 6Week 9Week 12

Planning and setupWave one and cutoverWave two

This is an illustration, not a quote. Your own inventory and dependency map will set the real timeline.

Getting help with your cloud migration plan

If you'd like help, our cloud migration services cover every step on it, from the first inventory to the cost reviews after the move. For an example of the live, data heavy systems we build, read how our shipment tracking software cut delivery delays by 40%. Planning to rebuild an older application while you're at it? Our guide on how much custom software costs explains how that work is scoped and priced. Moving very large data sets, such as meter readings or a video archive? See our pages on energy and utilities software and media and entertainment software.