Cloud migration guidance is mostly written for enterprises with dedicated platform teams and multi-year budgets. The more common situation is a handful of engineers, an ageing data centre contract and a deadline.
This checklist is for that situation. It assumes you will move in stages, keep the lights on throughout, and cannot afford a rewrite.
Phase 1: Discovery, and be honest about it
You cannot migrate what you do not know exists. Two weeks here saves two months later.
- Inventory every running workload. Not what the documentation says — what is actually running. Scan the network, check the hypervisor, read the load balancer config.
- Map dependencies. Which services talk to which, and over what. The forgotten cron job that writes to a share is what breaks cutover weekend.
- Record data volumes and growth rates. Transfer time and egress cost both scale with this, and both are routinely underestimated.
- Note compliance constraints. Data residency, retention requirements, anything covered by a customer contract.
- Find the owner of each system. Several will have none. Those are the ones to look at hardest.
Expect discovery to surface at least one system nobody knew was load-bearing. This is normal and is the main reason the phase exists.
Phase 2: Decide the treatment for each workload
The standard framing is the six Rs. For a small team, four of them matter.
Rehost — lift and shift to equivalent virtual machines. Fast, low risk, captures none of the cloud’s cost benefits. The right default for anything you do not understand well.
Replatform — move with modest changes, typically swapping a self-managed database for a managed one. The best effort-to-benefit ratio for most teams, and where the majority of workloads should land.
Repurchase — replace with SaaS. Mail servers, CI runners, monitoring and log storage are usually cheaper and better bought than run.
Retire — switch it off. Every migration finds systems serving nobody. Retiring 15% of the estate is common and is the cheapest possible migration.
Refactoring to containers or serverless during the migration is tempting and almost always a mistake. Do it afterwards, once the thing is running in its new home.
Phase 3: Build the landing zone first
Before anything moves, set up the account structure, networking and guardrails. Retrofitting these is painful.
- Separate accounts or projects for production, staging and development. Not separate tags in one account.
- Network layout with private subnets for anything that does not need to be public.
- Identity and access from the start — roles not shared keys, SSO if you have it, no long-lived credentials in code.
- Logging and metrics collecting centrally before the first workload lands, so you can see what happens.
- Cost allocation tags enforced by policy. Without this you will not be able to answer “why is the bill $9,000” in three months.
- Infrastructure defined as code from the beginning, even if the first version is rough. See infrastructure as code for why this is worth the early cost.
Phase 4: Sequence the moves
Order matters more than speed. A workable sequence for a small team:
Start with something low-risk and self-contained — an internal tool, a staging environment, a batch job. The goal is to exercise the process and find the gaps while the consequences are small.
Move stateless services next. They are easy to run in parallel and easy to roll back.
Databases last, and one at a time. Data is the part that cannot be rolled back cleanly once writes have landed in the new system.
Resist the temptation to move the hardest thing first to “get it over with”. Teams that do this frequently stall and lose organisational support for the whole programme.
Phase 5: Data migration specifics
The database cutover is the part that goes wrong. Three things reduce the risk substantially.
Replicate before you cut over. Set up ongoing replication from old to new, let it run for days, and verify. The cutover then becomes a brief pause rather than a bulk transfer.
Measure the transfer honestly. Ten terabytes over a shared 1 Gbps link is roughly a day at theoretical maximum and considerably longer in reality. For large volumes, physical transfer appliances are frequently faster than the network.
Define the verification before cutover. Row counts, checksums on critical tables, a set of known queries whose results you compare. Agree in advance what constitutes success, because at 3am nobody makes good judgement calls about whether a 0.1% discrepancy matters.
Phase 6: Cutover
Write the runbook as a numbered list with owners and expected durations. Include the rollback steps with the same detail, and set a decision point — if step seven is not complete by a stated time, you roll back rather than pushing on.
Lower DNS TTLs a week in advance. Have everyone in one channel. Agree who makes the call. Do not schedule it the day before a holiday, and do not schedule it the same week as a release.
Phase 7: The first month afterwards
Migration is not finished at cutover. Three things need attention immediately.
Cost. The first bill will be higher than expected, usually because of over-provisioned instances chosen for safety and data transfer nobody modelled. Right-size after two weeks of real metrics, not before. Our notes on cloud cost optimization cover where the money typically goes.
Monitoring gaps. Alerts that worked on the old infrastructure often do not fire on the new one, and you find out when something breaks quietly.
Decommissioning. Switch off the old environment on a schedule. Teams that leave it running “just in case” pay for both for a year and never fully commit to the new one.
Security and access, done once
Migration is the cheapest opportunity you will get to fix identity and access, because everything is being rebuilt anyway. Four decisions worth making deliberately.
No long-lived access keys. Use role-based access for workloads and SSO for humans. Keys committed to a repository are the most common cloud breach, and they are entirely avoidable if keys do not exist.
Least privilege from the start. It is far easier to begin restrictive and open up than to tighten later, when everything depends on permissions nobody can safely remove.
Encryption on by default. At rest and in transit, with keys you control where the compliance regime requires it. Turning this on later means re-encrypting data in place.
Audit logging to a separate account. Logs an attacker can delete are not logs. This is a half-day of work during setup and a significant project afterwards. A zero trust posture is also far easier to build at this point than to retrofit.
What to tell the business
Migrations lose support when stakeholders cannot see progress. Three things keep that from happening.
Report workloads moved and old-environment cost remaining, not percentage complete. Percentages are unfalsifiable; counts are not.
Say plainly that costs will rise before they fall. A first bill 30% above expectation is normal and recoverable; a first bill 30% above expectation that nobody warned anyone about becomes a credibility problem.
Name the benefits you are actually buying and how they will be measured. “Elasticity” is not a benefit anyone can check. “We can run the quarter-end batch in two hours instead of fourteen” is.
What to decide about containers
Migrations frequently become container projects because the two conversations arrive together. They are separable, and separating them reduces risk. Containerising during a move adds a new runtime, a new build process and a new set of failure modes on top of a change that already has plenty.
The safer sequence is to move first, stabilise, and then containerise the workloads that benefit. When that conversation comes, container orchestration basics covers whether an orchestrator is warranted at all, which for many estates it is not.
Frequently asked questions
How long does a cloud migration take?
For a small estate — a few dozen workloads, one or two databases — three to six months is realistic with a part-time team. Estimates under two months usually omit discovery and the post-migration work.
Should we refactor during migration?
No. Move first, optimise after. Combining the two makes failures impossible to diagnose, because you cannot tell whether the new platform or the new architecture caused the problem.
Is lift and shift a waste of time?
It captures none of the cloud’s elasticity benefits, but it is fast, low-risk and reversible. For workloads you do not understand or do not plan to invest in, it is the correct choice.
What is the most commonly missed cost?
Data egress, followed by inter-availability-zone traffic. Both are invisible in planning and material in the bill. Model them explicitly from your dependency map.
