What is the right way to migrate to the cloud?
Decide per workload rather than for the whole estate. Replace what a SaaS product already does better, re-architect what genuinely benefits from platform services, and lift-and-shift only what you cannot change yet. "The cloud is just someone else's computer." You've probably heard this dismissive statement. It's true in a reductive sense, but it completely misses the point of why cloud exists and what it offers beyond raw computing power.
Many businesses treat the cloud (Azure, AWS, Google Cloud) as simply a data centre they don't own. They take their existing virtual machines and run them in the cloud exactly as they were running on-premise. This approach is called "Lift and Shift."
It's also the most expensive and least beneficial way to use the cloud.
What are the three cloud migration strategies?
There are fundamentally three approaches to cloud migration:
- Lift and Shift (IaaS): Take your existing servers and run them as virtual machines in Azure/AWS/GCP. Same operating systems, same software, same maintenance requirements, different location. Quick to implement, but you inherit all your existing problems and miss most cloud benefits.
- Modernise and Move (PaaS): Replace server-based solutions with platform services. Instead of managing a Windows Server running SQL, use Azure SQL Database. Instead of maintaining a file server, use SharePoint or Azure Files. The cloud provider handles patching, backups, and scaling. You focus on your business.
- Cloud-Native (SaaS where possible): Use fully managed services wherever possible. Why run your own email server when Microsoft 365 exists? Why run your own CRM when Salesforce or Dynamics 365 is available? You pay a subscription and the entire application just works.
| Strategy | What it means | Best for | Main risk |
|---|---|---|---|
| Lift and shift (rehost) | Move the server as-is onto a cloud virtual machine | Hard deadlines, applications you cannot change | You now rent, by the hour, the inefficiency you used to own |
| Re-platform | Keep the application, move its parts onto managed services such as a hosted database | Systems that work but are expensive to run | Needs real testing time |
| Replace (SaaS) | Retire the application and adopt a product that already does the job | Email, file shares, accounting, CRM | Data migration and retraining, paid once |
Why does lift and shift often cost more than expected?
Lift and shift costs more than expected because a virtual machine bills every hour it exists, whether or not anyone uses it. The on-premises server it replaced was a sunk cost that idled for free. We regularly see businesses running 6-year-old legacy applications on cloud VMs costing R20,000/month that could be replaced with R5,000/month SaaS solutions. The VM approach is familiar to the IT team, but it's paying cloud prices for on-premise thinking.
When you lift and shift:
- You still need to patch operating systems monthly
- You still need to manage antivirus and security agents
- You still need to configure and test backups
- You still need someone on call if the server crashes at 2am
- You're paying for allocated resources whether you use them or not
All you've done is move your maintenance burden to a more expensive hosting platform.
Why are platform services cheaper than virtual machines?
True cloud value comes from using platform services (PaaS) instead of infrastructure (IaaS):
- Database: Don't run a Windows Server VM with SQL installed and manage licensing, patching, backups, and disaster recovery manually. Use Azure SQL Database or Amazon RDS. The service auto-patches, auto-backs-up, has built-in high availability, and you pay per-use rather than always-on. Your DBA can focus on optimising queries, not babysitting servers.
- File Storage: Don't run a file server VM and then VPN into it from everywhere. Use SharePoint, OneDrive for Business, or Azure Files with cloud sync. Accessible from anywhere, no VPN required, automatic versioning, built-in sharing controls. Users can actually find things because search works.
- Identity: Don't replicate your domain controllers to the cloud and maintain complex AD Connect synchronisation. Use Entra ID (Azure AD) as your primary identity source. Modern authentication, conditional access, passwordless options, automatic threat detection. Security that improves rather than stagnates.
- Web Applications: Don't manage IIS servers. Deploy to Azure App Service or containerised solutions. Auto-scaling, deployment slots for zero-downtime releases, built-in CI/CD integration.
When is lift and shift still the right call?
Lift and shift is the right call when a deadline is fixed, the application cannot be changed, or the vendor no longer supports it. It buys time to re-architect later, rather than pretending the problem is solved. Some workloads genuinely need lift and shift. Legacy applications that can't be replaced, specialised software that only runs on specific configurations, systems so critical that any change is unacceptable risk. That's fine. Virtual machines in the cloud are still often better than on-premise hardware you need to maintain.
But if you just move your mess to the cloud, it's still a mess. It's just a more expensive monthly mess with a fancier dashboard.
Every migration should ask: "Can we replace this with a platform service before we move it?" The answer is often yes, and the long-term savings, both in cost and in staff time, are substantial. Our cloud and productivity team plans and runs these migrations, with backup and rollback built into every cutover.