"Migrate to cloud and you'll save money." It's the most repeated claim in our industry — and it's true about half the time. The other half, businesses end up with cloud bills 20–40% higher than the on-prem environment they replaced, with no clear plan to get them down.
Augusta has migrated dozens of East African SMEs over the last six years. This is the playbook we now run — including the patterns that consistently work and the cost traps that catch teams new to the cloud.
The cheaper-cloud myth
Cloud isn't automatically cheaper. It's automatically more elastic. Whether that elasticity translates into cost savings depends entirely on whether your workload actually benefits from elasticity.
If your workload is constant 24/7 — for example, a stable internal ERP with predictable usage — cloud will probably cost you more than well-run on-prem. If your workload is bursty — a customer-facing app with peaks, batch jobs that run for two hours a day — cloud will likely be dramatically cheaper. Honest assessment matters.
Start with workloads, not infrastructure
The biggest mistake we see SMEs make is approaching cloud migration as an infrastructure project. It's not. It's a workload portfolio decision.
Inventory every workload (each application or service that runs in your business). For each one, answer:
- Usage profile — constant? bursty? scheduled? batch?
- Dependencies — what does it need to talk to?
- Business criticality — what's the cost of downtime?
- Modernisation candidate? — could it be re-architected, or does it need a clean lift-and-shift?
That worksheet — completed honestly across the whole portfolio — drives every later decision.
Three migration patterns that work
Pattern 1 · Lift-and-shift, then optimise
Move the workload as-is into IaaS (EC2, Azure VMs). Quick wins on infrastructure-as-code, observability, and backup. Optimise architecture in a second wave once the team is comfortable. Best for legacy systems and time-pressured cutovers.
Pattern 2 · Replatform during migration
Move the workload but swap obvious infrastructure components for managed equivalents — your self-hosted MySQL becomes RDS, your VM-based queue becomes SQS, your Apache becomes managed load balancers. 30–50% operational toil reduction without rewriting the application.
Pattern 3 · Refactor for cloud-native
Decompose into containers and managed services, redesign for autoscaling and ephemerality. Highest investment, highest payoff. Reserved for the workloads where the modernisation business case actually closes.
The right answer for a portfolio of fifty workloads is rarely the same answer for all of them. The team that does the assessment well chooses pattern 1, 2, or 3 deliberately, application by application.— Madhu Gummadidari
Cost traps to avoid
The four traps that account for most surprise cloud bills we've seen in East Africa.
- Egress charges. Moving data out of the cloud is metered. Backups, replication to on-prem, customer downloads — all add up. Architect to keep data in the cloud once it's there.
- Right-sizing failures. Teams pick instance sizes by guessing rather than measuring. After three months of metrics, half the fleet can usually drop a tier.
- Forgotten resources. A dev environment spun up for a one-week pilot that's still running 18 months later. Use tagging, budgets, and automatic shutdown for non-prod.
- On-demand for stable workloads. Pay-as-you-go pricing for workloads that run 24/7 is the most expensive thing you can do. Reserved instances or savings plans cut 30–60% on that footprint.
Wins to actually expect
- 30–40% lower TCO over 3 years for SMEs that follow the playbook.
- Time-to-market on new features cut in half — environment provisioning that used to take weeks now takes minutes.
- Disaster recovery moves from "we have a tape" to "we have a tested multi-region failover."
- Security posture improves dramatically — the cloud-native controls available on AWS or Azure are better than what most SMEs ran on-prem.
Practical close
Most failed cloud migrations fail in the same way — overestimating the savings, underestimating the operational change, and skipping the workload assessment. None of those are technical problems; they're planning problems.
If you're considering a migration, do a 4-week paid assessment first. We do these for fixed cost, end with a clear go / no-go recommendation, and we'll tell you when on-prem is the right answer.