Cloud Published March 2026 · 7 min read
By 2026, the question for most Australian businesses isn’t whether to move to the cloud — it’s how to do it without disruption, blown budgets, or compliance breaches. The cloud has won decisively in productivity, collaboration, and email. The harder questions are around line-of-business applications, finance and ERP systems, regulated workloads, and legacy infrastructure that’s been on a server cupboard UPS for the past decade.
This checklist walks through every stage of an Australian cloud migration: how to assess readiness, navigate Privacy Act and Essential Eight obligations, choose the right cloud and migration strategy, control cost, plan the cutover, and optimise after go-live. It’s the same framework we use with our Melbourne clients on real projects.
Stage 1: Pre-Migration Readiness Assessment
The number one cause of failed cloud migrations isn’t technical — it’s skipping discovery. Before any architecture diagrams are drawn, complete this readiness audit.
Workload Inventory
Document every server, application, database, and integration in your environment. For each workload capture: business owner, criticality, current performance baseline (CPU, RAM, disk, network), licensing model, and dependencies on other systems. This isn’t glamorous work, but missing dependencies are the single biggest source of migration weekend incidents.
Data Classification
Classify the data each workload handles into four buckets: public, internal, confidential, and regulated. Regulated data — personal information under the Privacy Act, health records under the My Health Records Act, financial data covered by APRA CPS 234 — carries specific obligations on storage location, encryption, and breach notification. Get this classification right early; it shapes every architectural decision that follows.
Network and Bandwidth
Cloud workloads consume network differently to on-premise ones. Map your current internet connectivity, latency to the major cloud regions (ap-southeast-2 / Sydney is closest for most), and any sites that will need new connectivity options like ExpressRoute, Direct Connect, or SD-WAN. A migration that works perfectly in the lab can fall over on Monday morning if the office uplink can’t handle the new traffic patterns.
Skills Audit
Honestly assess your team’s cloud skills. AWS, Azure, and GCP are different enough that experience in one transfers only partially to another. If your operations team is strong in on-prem Windows and weak in IaC and Linux, that needs to be addressed before you cut over — either through training, hiring, or a managed services partner.
Stage 2: Australian Compliance Considerations
Australian businesses face a distinct compliance landscape that often surprises clients used to the US-centric cloud marketing.
The Privacy Act and APPs
The Australian Privacy Principles (APPs) under the Privacy Act govern how personal information is collected, stored, used, and disclosed. APP 8 specifically addresses cross-border data flows: if your data leaves Australia, you remain accountable for ensuring overseas recipients handle it consistently with the APPs. The 2024–2026 amendments tightened obligations significantly, increased penalties, and introduced new requirements around automated decision-making transparency.
Data Residency
For most regulated workloads, you’ll want data stored in an Australian region. AWS Sydney (ap-southeast-2), Microsoft Azure Australia East/Southeast, and Google Cloud australia-southeast1/2 all offer Australian data sovereignty. Understand the difference between data residency (where data is stored), data sovereignty (which laws apply), and operational sovereignty (who can access the underlying infrastructure). Some sectors — defence, certain government, critical infrastructure — require IRAP-assessed services or sovereign-cloud offerings like Vault or AUCloud.
Notifiable Data Breaches Scheme
Under the Notifiable Data Breaches scheme, eligible breaches must be reported to the OAIC and affected individuals as soon as practicable. Your cloud architecture must include detection, logging, and incident-response capability sufficient to meet that obligation. Centralised log aggregation, alerting on anomalous access, and a documented incident response runbook are not optional.
The Essential Eight
The ACSC’s Essential Eight maturity model is the de facto baseline for Australian cyber security. A cloud migration is a natural opportunity to lift maturity — particularly on application control, patching, MFA, and admin privilege management. Build Essential Eight controls into your target architecture from day one rather than retrofitting later.
Industry-Specific Obligations
Financial services (APRA CPS 230 and 234), health (My Health Records Act, AHIA standards), legal (Legal Profession Uniform Law confidentiality obligations), and education (FERPA-equivalent state requirements) all impose additional constraints. If you’re in a regulated sector, get sector-specific advice early.
Stage 3: Choose the Right Cloud and Strategy
AWS, Azure, GCP, or Hybrid?
For most Australian SMBs and mid-market businesses, the practical choice is between AWS and Azure, with Google Cloud a strong third in data and AI workloads. The honest answer is that all three can do the job. Choose based on:
Existing Microsoft estate. If you’re heavily invested in Microsoft 365, Active Directory, and Windows Server, Azure offers a smoother integration path and licensing benefits.
Workload pattern. AWS has the broadest service catalogue and is often preferred for greenfield, cloud-native workloads. Azure’s Windows-centric heritage shines for lift-and-shift of Windows servers and SQL Server.
Skills. Migrate to the platform your team can operate. The cheapest cloud is the one your people can run.
Hybrid scenarios. Many Australian businesses end up hybrid by design — some workloads in cloud, some in colo, some on-prem. That’s fine, provided the integration is deliberate.
The 6 Rs of Migration Strategy
For each workload, choose one of six strategies. Most migrations are a portfolio — not a single approach.
Rehost (lift-and-shift). Move VMs as-is. Fastest, lowest risk, but you don’t capture cloud-native benefits. Good for workloads with a near-term retirement date or strict timelines.
Replatform (lift-and-reshape). Minor optimisations during the move — switching to managed databases, containerising stateless services, replacing scheduled tasks with serverless. Best balance of effort and benefit for most workloads.
Refactor (re-architect). Rewrite for cloud-native patterns. High effort, but unlocks scalability, resilience, and cost benefits. Reserve for workloads with strong long-term strategic value.
Repurchase. Replace your application with a SaaS equivalent. If you’re running on-prem Exchange, accounting, CRM, or HR, the SaaS version is almost certainly the better answer.
Retire. Migration is a great forcing function for spring-cleaning. Typically 10–20% of inventoried workloads can be switched off entirely.
Retain. Some workloads aren’t cloud candidates today — latency-sensitive industrial systems, recently-refreshed hardware, regulatory blockers. Document the decision and review annually.
Stage 4: Cost Planning and FinOps
Cloud cost overruns are the second-most-common post-migration regret (after under-investing in skills). Build cost discipline in from the start.
Total Cost of Ownership Modelling
Compare cloud cost against your full on-prem TCO — not just hardware, but power, cooling, facilities, licensing, refresh cycles, and operations time. The headline cloud price often looks higher because on-prem costs are scattered across multiple budget lines and largely invisible.
Reserved Capacity and Savings Plans
For predictable workloads, AWS Savings Plans, Azure Reserved Instances, and committed-use discounts can cut compute costs by 30–60%. Don’t commit on day one when usage patterns aren’t known — but plan to convert steady-state workloads to reservations within the first 6 months.
Tagging and Cost Allocation
Define a tagging policy before any resources are deployed: business unit, project, environment, owner. Without tags, you cannot allocate cost, shut down orphaned resources, or identify optimisation targets. Enforce tagging through policy, not goodwill.
Egress Costs
Data leaving the cloud is charged. If your architecture moves large volumes of data between regions, between clouds, or out to on-prem systems, model egress costs explicitly. We’ve seen quotes that doubled once realistic egress was included.
Stage 5: Migration Execution
Foundation First
Before migrating any workload, build the cloud foundation: identity (Entra ID or AWS IAM Identity Centre), networking (landing zone, VPCs/VNets, hub-and-spoke), security baselines (logging, GuardDuty/Defender, MFA), and IaC pipeline (Terraform, Bicep, or CloudFormation). Skipping foundation work leads to inconsistent, ungovernable deployments that have to be rebuilt later.
Pilot Wave
Migrate a small, lower-risk workload first — ideally one with clear stakeholders and tolerance for minor disruption. The pilot validates your tooling, processes, and runbooks before you take on critical systems.
Wave Planning
Group remaining workloads into waves of related applications. Migrate dependent systems together to avoid awkward periods of split-stack operation. Each wave should have a defined cutover window, rollback plan, and acceptance criteria.
Cutover and Hypercare
For each wave, plan: pre-cutover tasks (final data sync, DNS TTL reduction, comms), cutover (sequence, owners, decision points), validation (smoke tests, business sign-off), and hypercare (extended on-call coverage, daily standups for 1–2 weeks).
Stage 6: Post-Migration Optimisation
The migration weekend isn’t the finish line — it’s the start of optimisation.
Right-sizing. On-prem capacity is sized for peaks; cloud lets you size for actuals. Run for 30–60 days, then right-size every workload based on real telemetry. Typical savings: 20–40%.
Storage tiering. Move infrequently accessed data to cool/archive tiers. Many backup retention policies become significantly cheaper with tiered storage.
Auto-scaling. Workloads with variable demand benefit from auto-scaling groups, serverless functions, and managed-database autoscaling. Tune scaling policies once you have real load data.
Continuous improvement. Schedule a quarterly architecture and cost review. Cloud services evolve fast — today’s optimal architecture is tomorrow’s legacy. Stay current.
Common Pitfalls We See
Treating it as an IT project, not a business one. Migrations succeed when business owners are engaged in priority and acceptance. They fail when IT goes alone.
Migrating before fixing. Cloud doesn’t fix bad architecture; it scales it. Address known performance, security, or design issues during replatforming, not after.
Underestimating change management. New tools, new processes, new ways of working. Budget for training and communications, not just compute and storage.
Single-vendor lock-in panic. Pure multi-cloud sounds prudent but adds enormous complexity. For most organisations, a primary cloud with a documented exit plan is a better posture than a half-built multi-cloud architecture.
Where Computers Unleashed Fits
We design and run cloud migrations for Melbourne businesses across professional services, manufacturing, retail, and not-for-profit sectors. Our typical engagement starts with a fixed-fee Cloud Readiness Assessment, produces a phased migration roadmap with realistic costs and timelines, and either runs the migration with you or hands the plan to your internal team. Whatever the path, you’ll get straight talk — not a sales deck dressed up as a strategy.