Cloud migration for SMEs: where to start

Why cloud migration projects go wrong

Three causes account for the majority of failed or stalled migrations. The first is starting without a complete application inventory. You can't plan a migration if you don't know what you're moving – and most SMEs discover mid-project that they have more applications, more interdependencies and more undocumented configurations than anyone had counted. The audit that should happen before kick-off ends up happening in the middle of it, when it's far more disruptive.

The second is treating migration as a like-for-like move. The temptation is to take what exists on-premise and replicate it in the cloud without questioning whether the architecture still makes sense. That approach carries legacy complexity into a new environment and misses the point of moving. Cloud infrastructure can be different in useful ways – managed services that eliminate maintenance overhead, elasticity that removes the need for peak-capacity provisioning – but only if the migration asks those questions rather than avoiding them.

The third is compressing the timeline. Cloud migration done well takes longer than expected and costs more than the infrastructure savings initially suggest. The economics are real, but they take time to materialise. Businesses that try to complete a migration in weeks typically spend months fixing what the rush broke. Budget more time than feels necessary, and use that buffer.

Lift-and-shift vs re-platforming: which approach is right

Lift-and-shift means moving what you have, as-is, to cloud infrastructure. The application runs on a cloud VM in roughly the same way it ran on a physical server. It's faster, it's lower risk and it doesn't require deep cloud expertise to execute. The trade-off is that you carry legacy costs and complexity with you. A poorly architected on-premise application doesn't become a well-architected one just because it's running in Azure or AWS.

Re-platforming means rebuilding for cloud-native patterns: managed databases instead of self-managed instances, containerised applications, serverless functions for appropriate workloads. The long-term economics are better – lower operational overhead, automatic scaling, reduced licensing costs on infrastructure you no longer manage. The requirement is more expertise, more time and a clearer picture of what you're building toward.

For most SMEs, the right answer is both – sequenced deliberately. Lift-and-shift for the core infrastructure to get workloads into the cloud and eliminate on-premise hardware dependencies. Re-platform selectively for specific applications where the benefit is clear and the team has the capacity to do it properly. Don't try to re-platform everything at once. The businesses that attempt it tend to take on too much complexity simultaneously and end up with neither a completed migration nor a properly cloud-native architecture.

What to migrate first

Start with what you'll regret least if something goes wrong. That means development and test environments first – they're not business-critical, they're often provisioned and deprovisioned frequently anyway, and they give the team real migration experience in a low-stakes context. Archival data is another good early candidate: it moves once, it sits in storage, and the impact of a problem is limited. Collaboration tools – email, document sharing – are often already cloud if the business is on Microsoft 365, so there's little to do there.

Leave business-critical, high-complexity systems until the team has confidence. ERP systems, customer databases, financial applications – these carry real operational risk if the migration is mishandled. The internal capability to migrate them safely is built on the lower-risk workloads that went before. Trying to start with the most complex systems is how migrations go expensively wrong.

The sequencing principle is simple: build the team's migration capability on workloads where the blast radius of a mistake is small. By the time you're moving the systems the business depends on, you want the process to feel routine.

Security in migration: what gets missed

Most security gaps in cloud migration aren't about the destination – cloud platforms are well-secured environments. They're about the transition period, where systems are partially moved, configurations haven't been finalised and access controls are in a temporary state that nobody goes back and reviews.

Data in transit is the first area to get right: all data moving from on-premise to cloud should be encrypted, and that should be confirmed rather than assumed. Identity and access is where the complexity sits – reconciling cloud identity management with on-premise Active Directory, ensuring that access grants made during migration don't persist beyond it, and confirming that the principle of least privilege applies to cloud resources as it should on-premise.

Network exposure needs deliberate attention. Cloud services default to accessibility that would never be acceptable for on-premise systems – public endpoints enabled by default, firewall rules that are permissive until someone tightens them. Logging and monitoring also need configuration: the assumption that cloud systems are being monitored is often wrong until someone explicitly sets it up. And for any business handling personal data, GDPR requires knowing where that data is stored – data residency requirements need to be confirmed before migration, not investigated after.

The most common security gap we see in post-migration reviews: systems left with overly permissive access during the transition period and never tightened up afterwards. Set a specific date to review and close temporary access, and treat it as a hard commitment.

Managing costs during and after migration

Cloud costs are usage-based and they can surprise SMEs that are used to fixed infrastructure spend. The invoice for an on-premise server is predictable month to month. Cloud costs vary with usage, and the relationship between usage and cost isn't always intuitive until you've been through a billing cycle.

Right-sizing matters from the start. Don't migrate workloads to the largest instance available "just in case" – start with a reasonable estimate, monitor actual utilisation in the first weeks, and resize based on data. Over-provisioned cloud infrastructure costs real money every month.

Pricing model matters too. On-demand pricing is the cloud default – you pay a premium for the flexibility to stop at any time. Reserved pricing commits you to one or three years in exchange for a significant discount, typically 40–60% depending on the platform and commitment term. For stable workloads that you know will run continuously, reserved pricing is almost always the right choice. Use on-demand for variable or uncertain workloads while you establish baseline usage.

Budget for the migration period itself. Running cloud infrastructure and on-premise infrastructure simultaneously doubles costs temporarily – you're paying for both until the old environment is decommissioned. That parallel-running period is often longer than planned. Budget for 3–6 months of parallel running and treat it as part of the migration cost, not a surprise.

What success looks like: how to know when you're done

Define exit criteria before the migration starts. Which systems will be migrated? What will the on-premise footprint be when the project is complete? What are the performance and cost targets that confirm the migration delivered what it was supposed to? Without these defined upfront, migrations tend to drift – technically complete but never formally closed, with on-premise infrastructure lingering and costing money.

The migration is done when the old environment is decommissioned and its costs are eliminated – not when the last workload is copied to cloud. Copying workloads to cloud while the on-premise infrastructure keeps running doesn't deliver the cost savings that justified the project. The costs only go away when the hardware is switched off and the data centre contracts are terminated.

The step most organisations skip is actually turning off the old infrastructure. There's always a reason to wait – "we'll keep it for another month in case we need to roll back" – and that month becomes three and then twelve. Build decommissioning into the project plan as a specific milestone with a date, assign someone to own it, and treat it as a deliverable on the same level as the migration itself.