Why downtime hits SMEs harder
For a small or medium-sized business, an outage during a migration is not a minor inconvenience. It is a direct hit to revenue, to supply chains and to customer trust. Unlike a large enterprise, most SMEs don't have a spare support team or a second warehouse to absorb the gap.
The failure mode is simple. An online retailer stops taking payments for a few hours during a migration window. Customers abandon their baskets. The support queue backs up. Overnight, a technical decision becomes a business problem. That is why the plan matters more than the platform: treat avoiding downtime as the first goal, and the benefits of the new infrastructure as the second.
Before you touch anything: inventory and dependencies
Good migrations start long before any data moves.
Write down what you actually run: applications, databases, integrations, scheduled jobs, and who or what depends on each one. Note the tolerances too - which systems need to be up around the clock, and which can survive a scheduled pause. This is also the point to flag anything held together by an older system talking to newer tools over brittle, custom integrations; if that sounds familiar, we've written separately about bridging legacy systems with modern APIs.
Once you have the map, decide what success looks like in practical terms: which applications must never go down, which can tolerate a maintenance window, and which services would genuinely save your team time if they moved first. Use that to build a prioritised backlog rather than migrating everything at once.
Pick the right model for each workload rather than one model for everything. Infrastructure as code gives you full control and repeatable environments when you need it; a managed SaaS tool is usually the better call for something like CRM, where running your own infrastructure buys you nothing. If your business handles regulated or sensitive data, check data residency and security requirements before you commit to a provider or region - the National Cyber Security Centre's guidance on cloud security is a sound starting point for UK businesses.
Bring the people who actually use the systems into this conversation early. Operations, support and sales staff will flag edge cases and dependencies that don't show up on an infrastructure diagram. Finally, write down a cutover plan and, just as importantly, a rollback plan - the steps you'll take if the migration doesn't go as expected, agreed before you need them rather than improvised under pressure.
Cutover techniques that keep you online
A handful of practical techniques account for most of the risk reduction in a migration. AWS sets out the general approach well in its cloud migration overview; here's how we apply the ideas in practice.
-
Lower your DNS TTLs ahead of time. If cutover depends on redirecting traffic, drop the time-to-live on the relevant DNS records days in advance. A long TTL set at the last minute means some users keep hitting the old environment for hours after you've switched.
-
Blue-green deployment. Run the new environment alongside the old one, fully built and tested, then switch traffic across once it's validated. If something misbehaves, you switch back immediately. Martin Fowler's write-up on blue-green deployment is a good reference if you want the pattern in more detail.
-
Canary releases for higher-risk changes. Rather than moving all traffic at once, route a small percentage to the new environment first and watch it closely before widening the rollout. See Fowler's note on canary release for the underlying idea.
-
Data sync and replication. For anything that must stay writable during the move, stream changes from the old database to the new one continuously rather than doing a single bulk copy. This keeps the two in step and avoids a long freeze window while you copy everything at once.
-
A rollback plan you've actually rehearsed. Know in advance what "going back" means for each system - reverting DNS, replaying the last few minutes of writes, or falling back to the old environment entirely - and make sure someone has practised it, not just documented it.
We rarely use all of these on a single project. A payments system might warrant data replication plus a canary cutover; an internal reporting tool might just need a scheduled blue-green switch out of hours. The point is to match the technique to what actually breaks if it goes wrong.
After cutover: testing, monitoring and cost control
The migration isn't finished when traffic starts flowing to the new environment. That's when the validation work begins.
Testing. Run end-to-end checks against real user journeys, not just individual endpoints, and verify that the data landed correctly. If your team doesn't have spare capacity to do this properly under time pressure, it's worth bringing in outside help for the test cycle - this is the kind of gap our QA and testing work exists to cover.
Monitoring. Set up observability from day one rather than adding it once something breaks. Provider tools such as AWS CloudWatch give you metrics, logs and traces out of the box. Track business-level signals too - order completion rate, payment success rate - alongside CPU and memory, since a healthy server can still be serving a broken checkout. Write down who gets paged and what "back to normal" looks like before you need to know.
Cost and performance. Once real traffic is flowing, look for over-provisioned resources and move to autoscaling or a smaller instance family where the data supports it. If application performance still isn't where you want it after the move, the bottleneck is often the database rather than the infrastructure around it - we've covered that separately in our piece on database optimisation.
Treat the weeks after cutover as part of the project, not the end of it. Review whatever went wrong, update the runbook, and keep the changes small from here on - the kind of steady, governed change process we outline in our guide to automation governance applies just as well to infrastructure changes as it does to automations.
If you're weighing up a migration and want a second opinion on where the risk actually sits, our cloud services team is happy to talk it through - or just get in touch.
Sources
- AWS - Cloud Migration
- Martin Fowler - BlueGreenDeployment
- Martin Fowler - CanaryRelease
- NCSC - Cloud security guidance