Cloud migration projects rarely fail because of the cloud provider. They fail because of sequencing — moving the wrong thing first, underestimating a dependency, or cutting over without a tested rollback plan. After running a fair number of these for clients, here's the checklist we actually use, in the order we use it.
1. Inventory what you actually have
This step gets skipped constantly, and it's the most important one. Before touching infrastructure, document every system, its dependencies, who owns it internally, and how critical it is to daily operations. It's common to discover a "small internal tool" that half the finance team quietly depends on every month-end — the kind of thing that causes a painful surprise if it's not accounted for before migration day.
2. Classify by risk and priority, not by ease
It's tempting to migrate the easiest systems first. Instead, sort by a combination of business criticality and complexity. Start with something meaningful but not mission-critical — a good candidate is a system where downtime would be inconvenient but not catastrophic. This gives your team real experience with the new environment before your most important systems are on the line.
3. Decide: lift-and-shift, or re-architect?
There are two honest paths, and mixing them up without deciding is where budgets balloon:
- Lift-and-shift — move applications largely as-is onto cloud infrastructure (virtual machines, managed databases). Faster and cheaper upfront, but you don't get the full benefit of elastic scaling or managed services, and some legacy assumptions (fixed IPs, local file storage) may need small adjustments regardless.
- Re-architect — redesign parts of the system to use cloud-native services (managed databases, containerized deployments, serverless functions where appropriate). More upfront engineering, but better long-term cost efficiency and scalability. This is where our cloud and DevOps work usually adds the most value for businesses planning to grow significantly over the next few years.
Most of our clients land somewhere in between: lift-and-shift the systems that are stable and rarely change, and re-architect the ones expected to scale or that are currently the biggest operational headache.
4. Plan for security and access control from day one
Cloud environments default to being reachable from anywhere, which is exactly why misconfigured access controls are one of the most common sources of real-world security incidents. Before migration, define who needs access to what, set up proper role-based permissions, and enable logging and monitoring from the very first day resources go live — not after something goes wrong.
5. Test the rollback plan before you need it
Every migration plan should have an answer to "what do we do if this goes badly at 2 PM on a Tuesday?" That answer needs to be tested in advance, not improvised during an incident. For critical systems, this usually means running the old and new systems in parallel for a defined window before fully decommissioning the legacy setup.
6. Right-size before you scale, not after
Cloud billing is usage-based, and it's very easy to over-provision "just in case" and end up with a bill that erases the cost savings you migrated for in the first place. Start with monitored, realistic resource sizing, and let actual usage data — not guesses — guide when to scale up.
7. Migrate in phases, and communicate every phase internally
The businesses that go through migrations smoothly are the ones where staff know what's changing and when — not just the IT team. A short internal notice before each phase (what's moving, expected downtime if any, who to contact if something breaks) prevents the flood of "is this broken or is it just me?" messages that otherwise land on your team's most stressed day.
What we tell clients before they start
Cloud migration is one of those projects where the unglamorous planning work — the inventory, the risk classification, the rollback test — matters more than the technology choice itself. If you're planning a migration and want a second set of eyes on the plan before you start moving anything, that's a conversation worth having early, not after the first system is already halfway moved.