Cloud migration has become one of the most common technology projects for Australian businesses over the last five years — and one of the most frequently mismanaged. The promise is real: lower infrastructure costs, better resilience, remote work capability, and access to enterprise-grade tools. But the path to getting there matters enormously.
Azure vs AWS for Australian businesses
Both Microsoft Azure and Amazon Web Services (AWS) have Australian data centre regions, which is critical for data sovereignty. Azure tends to be the better fit for businesses already invested in the Microsoft ecosystem (Microsoft 365, Windows Server, Active Directory). AWS has a broader services catalogue and often wins on price for pure compute workloads. Most Australian enterprises use both.
What to migrate (and what not to)
Good candidates for cloud migration
- File storage and document management
- Email and collaboration (Microsoft 365, Google Workspace)
- Business applications with cloud versions (ERP, CRM, accounting)
- Development and test environments
- Disaster recovery and backup targets
- Web applications and APIs
Workloads that often stay on-premises
- Legacy applications that can't be containerised or modified
- Workloads with very high data egress costs
- Real-time manufacturing or operational technology systems
- Highly regulated data with sovereign hosting requirements
The data sovereignty question
Australian privacy law, the Privacy Act, and sector-specific regulations (APRA, My Health Records Act, the Security of Critical Infrastructure Act) all have implications for where data can be stored and processed. Government and regulated sector organisations must ensure cloud workloads stay in Australian-region data centres and in some cases must use IRAP-assessed services. This is a non-negotiable planning input — not an afterthought.
The five phases of a well-run cloud migration
1. Discovery and assessment
Catalogue every application, workload, and data store. Map dependencies. Understand what talks to what. Estimate cloud costs before committing. This phase typically takes 2–4 weeks and is the most important investment in the project.
2. Business case and architecture
Build a realistic cost model — not just compute costs but egress, licensing, support, and management overhead. Design the target architecture with security built in, not bolted on.
3. Pilot migration
Migrate one non-critical workload first. Learn the process, validate your tools and runbooks, identify surprises early when the stakes are low.
4. Wave migrations
Migrate in logical groupings — applications that depend on each other should move together. Plan cutovers for low-traffic windows with clear rollback procedures ready.
5. Optimisation
Cloud costs are dynamic. After migration, right-size your instances, implement reserved capacity for predictable workloads, and review spend monthly. Clients who skip this step routinely spend 30–50% more than necessary.
The most common cloud migration mistakes
- Lift-and-shift without optimisation — moving an inefficient on-prem setup to cloud at higher cost
- Underestimating egress costs — data transfer out of cloud can be significant
- Skipping the discovery phase — surprises discovered mid-migration are expensive
- No rollback plan — every cutover should have a tested way to reverse
- Treating cloud as a destination rather than an operating model — it requires ongoing management
Ready to take the next step?
Talk to a senior Logical Systems engineer — no sales deck, no pressure.
Talk to us about your cloud migration