A good cloud migration strategy for Australian organisations has four phases: assess your applications and data, plan the landing zone and compliance controls, migrate each workload using the right approach (rehost, replatform or refactor), then optimise cost, security and performance. Data sovereignty, IRAP or PCI DSS obligations and a named owner should be settled before anything moves.
Most cloud migrations that go wrong do so for dull reasons. Nobody classified the data. Nobody owned the bill. Nobody planned for the week after cutover. For Australian organisations, add data residency questions and regulator expectations, and the room for improvisation shrinks further.
This guide sets out a practical plan we would follow ourselves. It covers the four phases, the compliance questions that shape platform choice, how to compare Azure, AWS and Google Cloud, where hybrid cloud fits, and what happens after the move. Our view is simple: the move is the easy part, and the running is the work.
Key Takeaways
- Cloud migration is a business change with technical steps. Treat it as a programme with an owner, not an IT purchase.
- Assess first. A workload-by-workload decision (move, retire, retain or replace) prevents you migrating waste.
- Data sovereignty is about more than where data sits. It also covers who can access it, who holds the encryption keys and where backups and logs live.
- Match the platform to what you already run. Azure, AWS and Google Cloud can all be right, for different estates.
- Hybrid cloud is a legitimate destination, not a compromise, when latency, sovereignty or legacy systems justify it.
- Budget time and money for the period after cutover. Optimisation and management are where migrations succeed or quietly fail.
Free, 45 minutes
Start with the map, not the move.
Forty-five minutes with someone senior. We map what you run, what it costs and what the cloud should do for you, in plain English.
Summary Table: The Four Phases at a Glance
| Phase | Core question | Main output | Who should own it |
|---|---|---|---|
| 1. Assess | What do we have, and what must it comply with? | Workload register with a move, retire, retain or replace decision | Business owner with IT lead |
| 2. Plan | Where will it land, and how do we sequence it? | Platform decision, landing zone design, wave plan, rollback plan | IT lead with migration partner |
| 3. Migrate | Which approach suits each workload? | Workloads running in the target environment, old systems retired | Named project lead |
| 4. Optimise | Is it secure, performing and under budget? | Regular review rhythm, cost controls, improvement backlog | Accountable managed service partner |
What is cloud migration?
Cloud migration is moving applications, data and infrastructure from on-premises servers or a legacy hosting arrangement into a public, private or hybrid cloud platform such as Microsoft Azure, AWS or Google Cloud. It is a business change with technical steps, not a one-off purchase, and it finishes only when the old environment is retired and the new one runs well.
In practice, cloud adoption in Australia arrives in three forms. Software as a service, such as Microsoft 365, replaces an application. Infrastructure as a service moves virtual servers into a provider's data centre. Platform services replace self-managed components, such as databases, with managed equivalents. Most organisations use all three over time, which is why one big-bang plan rarely fits.
We frame every move as three steps: Assess, Migrate, Manage. We call it How a move works, and its purpose is to avoid a disruptive, high-risk cutover. This guide expands those steps into four phases because optimisation deserves its own attention. If your estate is centred on Microsoft, our Microsoft cloud services page explains how we approach it.
Phase 1: Assess what you have before you choose where it goes
Assessment means building an honest inventory of applications, data, dependencies and obligations, then deciding what to move, retire or keep. Skip it and you migrate waste, miss hidden dependencies and find compliance gaps after the data has already moved. It is the cheapest phase to get right and the most expensive to skip.
A workable assessment covers seven things:
- Inventory: servers, applications, databases, integrations, owners and end-of-support dates.
- Dependencies: which systems talk to which. A file server that quietly feeds an accounting system is a classic surprise.
- Data classification: personal information, payment card data, government information and commercially sensitive material each carry different rules.
- Criticality and timing: how much downtime each system tolerates, and which calendar dates are off limits, such as end of financial year, school terms or retail peaks.
- Licensing and contracts: existing licences, renewal dates and hardware warranties. A software licensing review early on avoids paying twice. Our software licensing team can help here.
- Skills and support: who runs this after the move, and whether that person is available after hours.
- Success measures: stated in business terms, not technical ones.
That last point matters. Our work supporting an independent school end to end, covering network, cyber security and daily support, taught us what we call the teacher test: if technology steals a minute of the lesson, it failed. Every organisation has its own version. For a distribution business it is a missed dispatch. For an accounting firm it is a locked file during lodgement week. Define yours first, and let it shape the cutover calendar.
The output of this phase should be a one-page decision per workload: move, retire, retain or replace, with an owner and a reason. Retire is the most underused option. Systems nobody can name an owner for are usually the best candidates.
Data sovereignty and compliance: settle these before you design
Data sovereignty means your data is subject to the laws of the country where it is stored or controlled. For Australian organisations the practical questions are where data resides, who can access it, and which obligations follow it. Answer these before choosing a platform, because they can rule options in or out.
Source: OAIC, Australian Privacy Principles; ASD, Infosec Registered Assessors Program; PCI Security Standards Council; APRA.
| Obligation | Applies to | What it means for your migration |
|---|---|---|
| Privacy Act and Australian Privacy Principle 8 | Most organisations covered by the Privacy Act | Know when personal information is disclosed or accessible overseas, and remain accountable for how your provider handles it |
| IRAP assessment | Government agencies and suppliers handling government data | Choose services assessed at the classification you need, and check the assessed scope covers the exact services you plan to use |
| PCI DSS | Anyone storing, processing or transmitting card data | Map who is responsible for each control, and reduce scope by keeping card data out of systems that do not need it |
| APRA prudential standards, including CPS 230 | APRA-regulated entities | Manage material service providers, concentration risk and exit planning as part of the design |
Two cautions apply. First, this is general guidance, not legal advice. Confirm obligations with your legal or compliance adviser. Second, an IRAP assessment describes a cloud service, not your workload. According to the Australian Signals Directorate (https://www.cyber.gov.au/irap), IRAP assessors evaluate services against Australian government security requirements. The provider secures the platform. You still have to configure and operate your side correctly.
Sovereignty goes beyond the region you pick. Ask where backups and replicas are stored, where logs and telemetry go, which provider staff can administer your environment and from where, and who holds the encryption keys. Selecting an Australian region is the start of the conversation, not the end.
We have seen what good looks like from the other side of the table. When a government team needed a data centre and continuity environment designed for uptime, the measure of success was whether its auditors could sign it off. Plan for the auditor from day one, and keep evidence as you go. Retrofitting it is painful.
Phase 2: Plan the landing zone and choose a platform
Planning means designing the landing zone (identity, network, governance, logging and cost controls) and choosing the platform that fits your applications, skills and compliance needs. For most Australian organisations the choice is between Azure, AWS and Google Cloud. The right answer is usually driven by what you already run, not by feature lists.
Azure, AWS or Google Cloud?
All three operate Australian regions. At the time of writing, AWS and Google Cloud have regions in Sydney and Melbourne, and Azure has regions across Sydney, Melbourne and Canberra. Confirm current availability and the IRAP-assessed service scope on each provider's site before you commit.
| Platform | Often the best fit when | Watch for |
|---|---|---|
| Microsoft Azure | Microsoft's cloud productivity suite, Windows Server, SQL Server and Entra ID are already central to the business | Licensing rules are detailed, so check what your existing licences already entitle you to |
| AWS | You want a broad service catalogue, cloud-native builds or a mature partner ecosystem | Breadth means more design decisions, and cost governance needs discipline from the start |
| Google Cloud | Data analytics, machine learning or container-heavy workloads lead the roadmap | Confirm local partner depth, support arrangements and assessed scope for the services you need |
For an Azure migration in Australia, identity is usually the anchor, because most organisations already run Microsoft identity. For an AWS migration in Australia, the deciding factor is often an application team that wants managed services and is comfortable designing for them. Avoid multi-cloud as a default. It doubles skills, tooling and governance, so adopt it only for a specific reason.
Build the landing zone first
The landing zone is the governed foundation your workloads land on. Microsoft's Cloud Adoption Framework (https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/) describes it well, and the principles apply on any platform. At minimum, settle:
- Identity and access, with multi-factor authentication and least privilege.
- Network design, including connectivity back to your sites.
- Naming, tagging and subscription or account structure, so costs are traceable.
- Logging and monitoring, switched on from day one.
- Backup and recovery targets, agreed with the business.
- Budgets and alerts, so the first surprise is not on an invoice.
Sequence the move in waves
Start with a low-risk pilot workload to prove the landing zone and the team's process. Then group workloads into waves by dependency and business risk, not by server count. Write a rollback plan for every wave and rehearse it. A cutover without a tested way back is a gamble, and gambles are not a plan.
Phase 3: Migrate using rehost, replatform or refactor
Rehost moves a workload as it is, replatform makes targeted changes to use managed services, and refactor redesigns the application for the cloud. Choose per workload, not per project. Most estates need a mix, because each approach trades speed against long-term benefit and risk.
| Approach | What happens | Effort and risk | Suits |
|---|---|---|---|
| Rehost (lift and shift) | Virtual machines move with minimal change | Lowest effort, but you carry existing inefficiencies with you | Time-bound moves, such as a data centre exit or hardware end of life |
| Replatform | Small changes, such as moving a database to a managed service | Moderate effort, with clear operational gains | Stable applications that would benefit from less maintenance |
| Refactor | The application is redesigned to use cloud-native services | Highest effort and risk, with the largest long-term benefit | Strategic applications with a clear business case for redesign |
AWS Prescriptive Guidance (https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migrations/migration-strategies.html) lists seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. Repurchase, replacing an application with software as a service, is often the smartest move for commodity systems such as email, file sharing and basic HR.
A few practical rules hold across all of them:
- Rehost first when a deadline is real. You can improve once the workload is stable in the new environment.
- Refactor only with a reason. Redesign for its own sake is an expensive hobby.
- Synchronise data ahead of cutover. Keep the old system live, run both in parallel where possible, then switch over in a planned window.
- Cut over in the quiet period. Use your calendar from Phase 1, and tell users what will change and when.
- Test the way back. Keep the source environment intact until the new one has proven itself through a full business cycle.
Retire the old environment properly
A migration is not finished until the old hardware is gone, and gone safely. Devices and servers reaching end of life carry data, and they become electronic waste. We retire client technology through PonyUp for Good: data is destroyed, devices are refurbished and resold, and half the profits are converted into meals. By our own count, the partnership has funded more than 150,000 meals and diverted more than 40 tonnes of technology from landfill. Whoever you use, insist on certified data destruction and a documented chain of custody.
Cloud security in Australia: build it in, do not bolt it on
Cloud security is a shared responsibility. The provider secures the underlying platform, and you secure identity, data, configuration and access. Most cloud incidents trace back to the customer side: weak identity controls, exposed storage or unmanaged accounts. Security should be designed into the landing zone and checked regularly.
We organise security as four disciplines in a deliberate order, which we call The whole job, in order: Assess, Protect, Detect, Recover.
- Assess: rank risks in business terms. Know which data matters most and where it lives.
- Protect: enforce multi-factor authentication, conditional access, least privilege, patching and encryption. The Australian Signals Directorate's Essential Eight is a sensible baseline for the controls that apply.
- Detect: switch on logging and alerting across identity, network and workloads, and make sure a person looks at the alerts.
- Recover: keep backups separate from the production environment, protect them from deletion, and test restores. A backup nobody has restored is a hope, not a control.
This is where we part company with fear-based selling. Our approach is for organisations that want to be safe, not scared. Risks are ranked and explained so a board or council understands what it is buying and why. If something is fine, we say it is fine. Also confirm your obligations under the Notifiable Data Breaches scheme, administered by the OAIC, and make sure your provider arrangements let you meet reporting timelines.
Hybrid cloud strategy for Australian organisations
Hybrid cloud keeps some workloads on-premises or in a private data centre and others in public cloud, connected under shared identity, security and management. It suits organisations with latency-sensitive systems, sovereignty constraints, specialist equipment or hardware that still has useful life. Treat it as a design choice, not a halfway house.
A hybrid cloud strategy in Australia often makes sense in practice for reasons like these:
- Legacy and specialist systems. Some applications depend on hardware or software that does not move cleanly.
- Sovereignty and assurance. Certain data may need to stay in a controlled facility to satisfy auditors or regulators.
- Latency and site connectivity. Operations at regional or remote sites may need local processing, because connectivity is not equal everywhere.
- Sunk investment. Moving hardware early that still has years of life can destroy value without improving outcomes.
Hybrid fails when the two halves are managed as separate worlds. The design must give you one identity system, consistent security policy, unified monitoring and a single backup approach across both. Connectivity between sites and cloud needs redundancy, because it becomes a critical dependency. Microsoft-centred organisations can often extend identity and management across both sides, and our Microsoft cloud services team designs hybrid environments this way.
Review the split every year. Workloads that were right to keep on-premises last year may be ready to move, and the reverse is occasionally true.
Phase 4: Optimise and manage after cutover
Optimisation starts the day workloads land. Right-size resources, tag everything, set budgets and alerts, review committed spend, and run a regular review of security and performance. Cloud bills drift when nobody owns them, so name an accountable person and give them a monthly rhythm.
The FinOps Foundation (https://www.finops.org) offers a useful discipline here: make cloud cost visible, allocate it to the teams that cause it, and optimise continuously. In practice, that means:
- Right-sizing: many migrated servers are oversized because they were specified for peak load years ago. Measure real usage, then adjust.
- Scheduling: switch off development and test environments outside working hours.
- Commitments: consider committed-use or reserved options only for workloads that are stable, and only once you have real usage data.
- Storage hygiene: archive or delete data that has no business or legal reason to stay.
- Architecture review: revisit replatform and refactor candidates once the estate is stable.
This is the Manage step in our model, and it is the boring stuff, done brilliantly, forever. We measure ourselves on your quiet weeks: few incidents, no surprises on the invoice, and people getting on with their work. Patching, backup testing, access reviews and cost reviews should be scheduled, reported in plain language and owned by someone you can phone.
What most migration plans miss: the move is the easy part
Our contrarian position is that most cloud migration plans are written as if the project ends at cutover. They budget for the move and treat the running as an afterthought. We think this is backwards, and it mirrors how we think about device fleets: devices are the easy part, and the lifecycle is the work.
Three beliefs follow from that.
Not everything should move. A strategy that ends with a confident retain decision for a system that works well is a better strategy than one that moves everything to hit a slide. Moving is a means. Quiet, secure, productive operations are the end.
Project contractors leave. Partners answer the phone. The people who design and build the environment should be the people who support it, with a named project lead and documented knowledge that never changes hands. When we handled device deployment and managed support across a national brand's whole estate, the outcome was one partner across everything. The same logic applies to cloud. When something breaks at 7am, you want a person who knows your environment, not a ticket queue. Real people, not a ticket queue, is not a slogan to us. It is how we want to be held accountable.
Judge a migration at the first quarter-end, not at go-live. Go-live shows the project was delivered. The first quarter shows whether the design was right: whether costs behaved, whether backups restored, whether users stopped noticing the technology. Put those checks in the plan, with dates, before you start. A partner who owns the outcome, not just the ticket, will welcome that test.
Plan your cloud migration with SCCS
Ready to move without the drama? SCCS plans and delivers cloud migrations the human way: an honest assessment, a clear plan in business language, a staged move without a high-risk cutover, and the same people on the phone afterwards.
Technology that just works is the goal. We would like to help you get there.
References
- Australian Signals Directorate, Infosec Registered Assessors Program (IRAP)
- Office of the Australian Information Commissioner, Australian Privacy Principles
- PCI Security Standards Council, PCI Data Security Standard
- APRA, Prudential Standard CPS 230 Operational Risk Management
- AWS Prescriptive Guidance, Migration strategies for large migrations
- Microsoft, Cloud Adoption Framework for Azure
Free guide
Mac in a Microsoft World
What changes when Macs join a Microsoft 365 environment, the parity table, and the three mistakes to avoid in year one.
Frequently asked questions
What are the most common cloud migration pitfalls?
The most common pitfalls are skipping the assessment, ignoring dependencies, leaving compliance questions until late, migrating everything instead of retiring what is unused, and having no owner for cost and security afterwards. Each is avoidable with a workload register, a tested rollback plan and a named accountable person.
Is hybrid cloud the right choice for our organisation?
Hybrid cloud suits you if you have legacy systems that do not move cleanly, sovereignty or assurance requirements for specific data, latency-sensitive operations, or hardware with remaining useful life. It works only when identity, security, monitoring and backup are consistent across both environments. If none of those reasons apply, a cloud-first approach is usually simpler.
What should happen after the migration is complete?
After migration, retire the old environment securely, right-size resources, set budgets and alerts, test backups and restores, review access, and schedule monthly cost and security reviews. Assign one accountable owner. The first quarter after go-live is where hidden design problems surface, so plan for it.
Does our data have to stay in Australia?
Not always. It depends on your obligations. Government and some regulated entities have strict requirements, while others must manage accountability for overseas access under the Privacy Act. Even where data may leave, many organisations choose Australian regions for simplicity. Check backups, logs, support access and encryption keys, and confirm with your legal adviser.
Should we choose Azure or AWS?
Choose based on what you already run and who will operate it. Azure is often the natural fit when Microsoft 365, Windows Server and Microsoft identity are central. AWS suits cloud-native builds and teams who want a broad catalogue of managed services. Both have Australian regions, so test your actual workloads and compliance needs rather than comparing feature lists.
Ian Pearce
General Manager, Sales and Services at Southern Cross Computer Systems
Keep reading
