Cloud Migration for SMEs: When the Move Pays Off

Cloud migration for SMEs pays when your load moves and someone owns the bill. If neither is true, you are renting the same waste by the hour.

An e-commerce client of mine ran a Magento 2 shop on a dedicated server. For most of the year that server sat underused. During peak season it ran short. They were paying too much and still ran out of capacity when it mattered, which takes some doing.

Below is what we did, what a move really looks like, when not to do it, and how I’d order the work.

What Cloud Migration Isn’t

It isn’t a cost-saving measure by default. Moving a fixed server to a fixed cloud instance gets you the same server at a monthly price with a nicer dashboard. The savings come from the things the cloud lets you do afterwards: scale down, shut down, stop owning what you don’t need.

It also isn’t only an IT project. Finance will see the spending shift from equipment to a monthly bill that changes every month, and that change needs an owner.

What We Did and What It Delivered

I proposed adopting Kubernetes and moving to the cloud. The company’s in-house developers containerized the application. My team prepared the new infrastructure with Terraform and Ansible, set up the CI/CD pipeline, deployed the application and migrated the database. The full account is in Kubernetes for SMEs.

The results: zero downtime during Black Friday and 30% lower overall infrastructure costs. A technology partner I brought in also helped the client secure funding that covered 10% of the expected annual cost of the new infrastructure. So ask about funding before you sign.

What a Move Really Looks Like: Twenty Domains and a Redirect Loop

A later project shows the shape of a migration better than any estimate. An e-commerce group wanted to move more than 20 shop domains, running Magento behind LiteSpeed, off Cloudflare and onto AWS: CloudFront, Route 53 and AWS WAF. We quoted 25 to 35 hours and insisted on a two-domain pilot first.

The work ran for about three months and then had a long tail. Several domains waited for the client to decide which addresses they should point to. The technology was finished long before the decisions were.

What nearly went wrong was one country domain stuck in a redirect loop. CloudFront was forwarding the Host header to the origin. Switching the origin request policy to AllViewerExceptHostHeader, which passes on everything except the visitor’s Host header, fixed it. That’s what the pilot is for. Meet the problem on domain two, not domain seventeen.

The Bill Nobody Forecasts

In my experience the estimate covers servers and storage, and the surprise comes from somewhere else.

I was once parachuted into a company to get its platform working. It had no technical leadership left and very little DevOps capacity. The surprise on the bill wasn’t servers or storage. It was the company’s own systems talking to each other across availability zones, all day, at a price nobody had planned for. No one had chosen that cost; the architecture had chosen it for them.

In my view, the question to ask before migrating isn’t “what will the cloud cost?” It’s “who will read the bill every month, and what can they change?”

When to Stay Where You Are

Many workloads don’t have the problem a migration solves.

The table tennis site I describe in Kubernetes for SMEs took a huge spike on a cheap rented rack in a small data centre. A light design did the work that a cloud bill would otherwise have done.

A steady workload, on hardware you’ve already paid for, with a team that knows it, may be cheapest exactly where it is. Some data may also have to stay on-premises. Even a programme built to be multi-cloud from day one didn’t move everything. On the multi-cloud AML and KYC platform, AWS ran the main cluster and GCP the failover, but every critical workload that couldn’t be shared with third-party vendors stayed on-premises. My rule of thumb is the same everywhere: put each workload where it is cheapest and safest to run, and that’s rarely one place.

Cloud Migration for SMEs: How I’d Order the Work

• Measure first. A year of real utilization tells you whether your load moves at all.
• Pilot on a small slice. Two domains or one service will surface the surprises cheaply.
• Decide per application. Some move as they are, some need rework, and some should stay or be retired.
• Name the owner of the bill before you move anything.
• Plan the cutover as a release, with a rollback. Zero-downtime deployments covers the techniques, and the database is the hard part.
• Choose the platform for a reason. In the Magento case Kubernetes came with the move, because peak load was the problem. Elsewhere serverless or plain virtual machines may do.

The same discipline applies to business systems: the legacy-to-ERP migration is a different technology and much the same risk.

Bottom Line

Cloud migration is worth doing when your load varies, when your hardware is forcing a decision anyway, or when speed of change is worth more than the premium. It isn’t worth doing because a competitor did. Measure first, pilot small, and give the move an end date.