Cloud migration is one of the most consequential infrastructure decisions an Australian organisation can make, yet many teams approach it with a vendor-provided template rather than a genuine plan. The result is a migration that technically succeeds but leaves the business with higher bills, fragmented governance, and compliance gaps they discover after the fact. This checklist is designed to give Australian IT teams a clear, ordered view of what to address before, during, and after the move.
Before you migrate: discovery and planning
Most migration failures are planted in the planning phase. The single most useful thing a team can do early is build an accurate inventory of what it is actually running. Application dependencies, data flows, licensing entitlements, and network topology all need to be mapped before a single workload moves. Tools like AWS Migration Hub, Azure Migrate, and Google Cloud's Migrate to Virtual Machines can automate discovery, but the output needs human review before it is trusted.
Data residency is a non-negotiable planning input for Australian organisations. Under the Privacy Act and sector-specific rules such as the My Health Records Act and APRA's CPS 234, many workloads cannot leave Australian shores without explicit controls in place. Before selecting a cloud provider or region, your team needs a clear classification of which datasets are sovereignty-sensitive. Our detailed Australian data residency guide for 2026 covers the full regulatory landscape and what each classification means in practice.
Cost modelling is equally important at this stage. Right-sizing instances, estimating egress costs, and accounting for licensing changes (particularly Microsoft products moving to cloud) will prevent the most common shock: a cloud bill that exceeds on-premises spend in year one. Build a total cost of ownership model that extends at least three years and includes operational costs such as training and tooling, not just compute and storage.
Workload assessment: not everything belongs in the cloud
The 6 Rs framework (Retire, Retain, Rehost, Replatform, Repurchase, Refactor) remains the most useful mental model for categorising workloads before migration. Lift-and-shift (Rehost) is fast but often the most expensive long-term option. Refactoring delivers the greatest benefit but the greatest risk if timelines are underestimated.
For each application, ask:
- What are the latency requirements, and will a local cloud region satisfy them?
- Does the application have hard dependencies on on-premises hardware, mainframes, or legacy connectivity?
- How does it handle state, and is the underlying architecture compatible with cloud-native scaling?
- What are the licensing implications of moving to a cloud-hosted model?
- Does the workload handle personally identifiable information subject to the Privacy Act or sector regulation?
Workloads with predictable demand profiles are strong lift-and-shift candidates. Applications with high variability or burst requirements tend to realise more savings from cloud-native patterns. Anything mission-critical deserves its own risk assessment before it moves, and a tested rollback procedure before cutover.
Security and compliance: build controls before you migrate
Security architecture should be finalised before the first workload reaches the cloud, not retrofitted afterwards. This means establishing identity and access management policies, defining network segmentation, enabling logging and monitoring at the account or subscription level, and deciding how secrets management will work across environments.
For Australian organisations, alignment with the ACSC's Essential Eight is a baseline expectation rather than an optional hardening step. Teams subject to the Protective Security Policy Framework, APRA's prudential standards, or the Australian Government Information Security Manual will have additional controls to satisfy before cloud workloads go live. If your organisation is working through its Essential Eight maturity levels, the Essential Eight maturity model guide outlines what each level requires and where most organisations currently fall short.
Encryption at rest and in transit should be enforced by policy, not left as a configuration option. Key management decisions, particularly whether to use cloud-native key services or bring your own keys, have long-term implications for sovereignty and compliance. Work through these with your legal and risk teams before migration begins.
The migration itself: sequencing and testing
Migrate in waves, starting with the lowest-risk workloads. Development and test environments are good first candidates: they expose real integration issues without threatening production. Use each wave to validate your runbooks, refine your change management process, and calibrate the effort estimates for subsequent batches.
Testing is where many migrations cut corners under schedule pressure. At a minimum, each migrated workload needs:
- Functional testing confirming the application behaves correctly in the new environment
- Performance testing confirming latency and throughput meet SLA requirements
- Security testing confirming controls are in place and configured correctly
- Disaster recovery testing confirming backup and restore procedures work as expected
Disaster recovery planning for cloud workloads has its own set of considerations. Recovery time and recovery point objectives need to be re-evaluated against cloud-native replication and failover options. For a detailed treatment of what actually works in the Australian context, the cloud disaster recovery guide covers the real-world tradeoffs across major providers.
Post-migration: governance, cost, and continuous improvement
Getting workloads into the cloud is the beginning of the work, not the end. Without active governance, cloud environments tend toward sprawl: unused resources, over-provisioned instances, shadow IT deployments, and inconsistent tagging that makes cost attribution impossible.
Establish a cloud centre of excellence or at least a named owner for cloud governance from day one. Define a tagging policy and enforce it at provisioning time. Set up cost anomaly detection and budget alerts before workloads go live. Schedule a quarterly review of reserved instance coverage and savings plan utilisation.
Monitoring and observability need to be built into the environment rather than bolted on. Cloud-native tools such as AWS CloudWatch, Azure Monitor, and Google Cloud Operations Suite provide a solid baseline, but many Australian organisations supplement them with third-party observability platforms for unified visibility across hybrid and multicloud environments.
Finally, revisit your architecture decisions six months after migration. What made sense on paper may look different under real production load. Cloud migration is an iterative process, and the organisations that extract the most value are those that treat the post-migration period as an ongoing optimisation programme rather than a project close-out.