The shape of success: what real cloud migrations have taught us
Cloud migration is usually pitched as a technical exercise: discover the estate, replicate the workloads, switch everything over. In practice, that's rarely how it goes.
We've supported organisations through migrations of every shape, from a handful of workloads to large, business-critical estates. The pattern we keep seeing has nothing to do with tooling. Success comes down to which assumptions get challenged before the project starts, not which platform gets chosen.
Here are six lessons that consistently separate the smooth migrations from the difficult ones.
Prefer to see the big picture first? We've summarised these six lessons in a simple visual that shows how they fit together before diving into the detail.
1. Dependencies are known, until they’re not
Automated discovery is a good starting point, not a complete picture.
This is where Subject Matter Experts earn their keep. They know how the important integrations actually behave under load, how they'll need to be rebuilt, and the occasional ad-hoc or infrequent one that a scan won't fully characterise on its own.
Pair discovery data with the knowledge that lives in people's heads and you get a genuinely accurate map, not just a technically complete one. Port and protocol issues have a habit of surfacing at cutover, so have the tools and the know-how in place before you start, not while the clock is running. The teams who succeed aren't the ones who avoid surprises; they're the ones who expected some.
2. You're migrating services, not servers
A spreadsheet of virtual machines is an inventory, not a plan.
Move one VM at a time and you create risk that didn't need to exist. Group by workload instead, i.e. all the assets that together make up the service you’re actually trying to move - servers, databases, integrations, authentication and business processes working together.
Categorise these workloads based on complexity and you can plan effort and order accordingly. Migrate in this way and sequencing, resourcing and timelines start to make sense. T-shirt sizing is fine as a starting point, but one server isn't always simple, and thirty servers aren't necessarily complex. Integrations, shared platforms, customisations and data drive complexity as much as size does, sometimes more.
And once you've identified your Subject Matter Experts (SMEs), lock their time in early. They're always in demand, and expecting their goodwill mid-migration is not a plan, it’s a hope.
3. It's always DNS
Ask any experienced migration consultant what caused the longest cutover call, and the answer is nearly universal: DNS.
Networking is complicated, and private zones, forwarding rules, split-brain resolution and firewall rules catch people out again and again - they have a habit of hiding until systems try to talk to each other in production. Networking isn't a background task to tick off: it deserves its own validation and rehearsal, well before go-live.
4. Governance is far harder to add after the fact
Naming conventions, tagging, RBAC and landing-zone design aren't exciting, and it shows in how often they get deprioritised.
But skip them before workloads start landing, and you're not saving time. You're simply taking on technical debt that the organisation will be paying down for years. Governance isn't paperwork; it's the structure that keeps an environment manageable once it starts to grow.
5. IT and SMEs make surprisingly poor testers
Migration teams often run exhaustive technical testing. Applications start. Services respond. Monitoring is green. Everything looks successful - right up until real business users log in.
Unless it's a true lift-and-shift, only the people who use these systems daily will spot the workflow friction, the performance expectations, and the operational quirks a technical team simply won't think to check. Bring business users in before go-live. It's not just good practice for adoption; it heads off the intensive - and expensive - support calls that would otherwise land on day one. Frustrated users make for a miserable day one, and that's the experience that sticks.
6. Data will not behave as politely as your infrastructure
Infrastructure replicates fairly predictably. Data doesn’t.
Large databases, legacy applications, custom integrations and commercial software all bring their own complications, and even a project that looks like a straightforward lift-and-shift can uncover unsupported configurations or vendor restrictions once planning gets underway.
The classic trap: assuming a commercial application will move happily from SQL Server on a VM to a managed PaaS database. Many won't so do make it a point of order to check with the vendor early. It's far cheaper and less frustrating than discovering the restriction mid-project and having it badly derail things.
Final thoughts
The migrations people remember as successful are rarely the ones where nothing went wrong. They're the ones where the team had already anticipated what would.
That means understanding workloads rather than servers, testing assumptions instead of trusting them, and locking in SME time instead of hoping for it. Bringing real users into the process, and getting governance in place before it's needed.
None of this is complicated, it's just easy to skip. So don’t skip it!
Planning a migration to Azure?
Whether you're modernising a handful of workloads or transforming an entire estate, Shaping Cloud helps organisations reduce risk by combining proven migration methodology with the practical lessons only real-world delivery teaches you.