Cloud Migration for Australian Businesses: Planning, Risks and Best Practices
Cloud migration for Australian businesses: discovery, Australian regions, APP 8 and data location, shared responsibility, migration waves, testing and costs.
What does cloud migration involve for an Australian business?
Cloud migration means moving applications, data and infrastructure from your own servers, or another host, to a cloud provider, then running them well there. For Australian businesses it involves discovery, choosing what to migrate and how, deciding where data lives and who can access it, securing the environment under a shared responsibility model, migrating in tested waves and governing costs afterwards. The cloud does not improve security or cost by itself.
This guide is for owners, IT managers and finance leaders planning to move business systems to AWS, Microsoft Azure, Google Cloud or a managed provider. It covers whether to migrate at all, discovery, Australian regions and data location, privacy, shared responsibility, migration approaches, testing and rollback, cost governance and how to choose help.
If your systems need more than a move, read legacy software modernisation first. For security operations after migration, see website security for Australian small businesses. Nothing here is legal advice.
Key takeaways
- Start with why: hardware end of life, resilience, scale, remote access or modernisation. The reason shapes the approach.
- Inventory every application, database and dependency before choosing anything.
- AWS, Azure and Google Cloud all run Australian regions, but service availability differs by region.
- Hosting in Australia does not settle APP 8 on its own. Map support access, backups, logging and AI services too.
- You remain responsible for identity, configuration and data protection in the cloud.
- Migrate in waves, test in the target environment and keep a rollback path for each wave.
- Set budgets, alerts and tagging from day one. Unmanaged cloud costs grow quietly.
Should you migrate at all?
Cloud migration is a means, not a goal. Good reasons include ageing servers, an office server room that is a single point of failure, the need for remote and multi-site access, unpredictable demand, or a modernisation that will use managed cloud services.
If the system itself is the problem, moving it will not fix it; see legacy software modernisation for the options. Weaker reasons include 'everyone is moving' or an expectation of automatic savings. Some workloads, such as specialised on-site equipment control or applications with heavy local data transfer, may be better left where they are or moved to a SaaS product instead. Retaining a system on premises for now is a legitimate decision.
Discovery: application inventory and dependency mapping
Most migration problems are discovery problems: a forgotten scheduled job, a hard-coded IP address, a report that reads directly from a database, or a licence tied to a physical server.
- List every application, database, file share and scheduled job, with an owner for each.
- Record operating systems, versions, licences and support status.
- Map dependencies: which systems call which, and over which ports and protocols.
- Classify data: personal, health, financial, commercially sensitive or public.
- Note performance needs, peak periods and acceptable downtime.
- Record recovery objectives: how much data you can lose (RPO) and how long you can be down (RTO).
- Check software licences for cloud and virtualisation terms.
Australian regions and data location
All three major providers operate in Australia. AWS runs Asia Pacific (Sydney) and Asia Pacific (Melbourne), each with three Availability Zones; Melbourne must be enabled (opt-in) before use (AWS). Microsoft Azure runs Australia East (New South Wales, with availability zones) paired with Australia Southeast (Victoria), and Australia Central and Central 2 in Canberra, with access to Central 2 restricted (Microsoft). Google Cloud runs australia-southeast1 (Sydney) and australia-southeast2 (Melbourne) (Google Cloud).
Region choice affects latency, resilience and, for some customers, contractual requirements. If you are building a product for many customers, SaaS development in Australia covers tenancy and data location decisions. Not every service or instance type is available in every region, so check the services you plan to use, including any AI services.
Privacy. If your business is covered by the Privacy Act, APP 8 requires reasonable steps before personal information is disclosed to an overseas recipient, and you remain accountable for that recipient. The OAIC's guidelines also explain when storing personal information with an overseas cloud provider may be a 'use' rather than a 'disclosure', for example where a binding contract limits the provider's handling and you retain effective control (OAIC). Either way, choosing an Australian region is only one step: also map support access, backups, monitoring, email and AI services.
Government work. ASD's IRAP program endorses assessors who assess systems and cloud services against the Information Security Manual, and the Hosting Certification Framework applies to government hosting arrangements (Hosting Certification Framework). These matter mainly if you hold government data or sell to agencies.
Shared responsibility: what you still own
Cloud providers secure the physical facilities, hardware and core infrastructure. You secure what you build and configure on top. The split shifts depending on the service: you patch the operating system on a virtual machine, but not on a fully managed database (AWS; Microsoft). ASD's ACSC publishes cloud shared responsibility guidance written for small and medium businesses (ACSC).
| Area | Your responsibility in practice |
|---|---|
| Identity and access | MFA for all users, no shared admin accounts, least privilege, regular access reviews |
| Configuration | No public storage by default, network rules, secure baselines, configuration monitoring |
| Data | Encryption settings, key management, classification, retention |
| Patching | Operating systems and applications on anything that is not fully managed |
| Backups and recovery | Backups that are separate, immutable where possible, and restored in tests |
| Logging and monitoring | Audit logs on, retained and reviewed; alerts for risky changes |
Worth noting
If your business has annual turnover over A$3 million, the Cyber Security Act 2024 requires reporting a ransomware or cyber extortion payment to ASD within 72 hours (Home Affairs). Tested, separate backups are the best way to avoid ever facing that decision.
Choosing a migration approach per workload
Decide per application, not for the whole estate. The common approaches, drawn from the AWS migration strategies (AWS):
| Approach | What happens | When it fits | Trade-off |
|---|---|---|---|
| Rehost | Move servers largely as they are to cloud VMs | Hardware deadline; little time to change code | Quick, but carries old problems and can be costly to run |
| Replatform | Small changes, such as a managed database or containers | Code is sound; you want less operational work | Needs testing of changed components |
| Refactor | Redesign to use cloud-native services | High-value app that needs to scale or change often | Most effort; best long-term fit |
| Repurchase | Move to a SaaS product | A product covers the need, such as email or accounting | Process change and data migration |
| Retain or retire | Leave it, or switch it off | Not ready, not worth it, or not needed | Revisit later; archive data before retiring |
Migrating in waves, with testing and rollback
Group applications into waves by dependency and risk. Start with a low-risk system to prove the process, the network set-up and the tooling.
Prepare -> landing zone, network, identity,
backups, monitoring in place
Replicate-> copy data; keep it in sync
Test -> functional, performance, security,
integration and restore tests
Cutover -> freeze, final sync, switch DNS or
connections, verify
Hypercare-> watch closely; fix fast
Rollback -> source kept ready until sign-offData migration and verification
Move data with tools suited to its size and change rate, and verify it. The reconciliation approach in ecommerce data migration works for any business database. Compare record counts, checksums and key financial totals between source and target, and have business users check samples. For databases that keep changing, use replication so the final cutover only moves the last changes. Keep the source read-only and available until you are confident.
Cost drivers and cost governance
Cloud costs are usage-based, which is an advantage only if someone manages them.
- Compute: right-size instances using real usage; switch off non-production overnight.
- Storage: choose tiers by access pattern; set lifecycle rules for old data and backups.
- Data transfer: moving data out of a cloud or between regions usually costs money; design to minimise it.
- Managed services: often cheaper in staff time than self-managed equivalents, even when the line item is higher.
- Commitments: reserved or committed-use pricing suits steady workloads, once usage is understood.
- Currency: many cloud prices are set in USD, so AUD costs move with the exchange rate.
- Governance: tag resources by owner and system, set budgets and alerts, and review monthly.
Pro tip
Our recommendation: run the first three months with weekly cost reviews. Most waste appears early: oversized instances, forgotten test environments and backups kept forever.
Performance and ongoing governance
After migration, monitor what users experience, not just server metrics; observability explains logs, metrics and traces in practice, and disaster recovery planning covers RPO and RTO in more depth. Set up alerts for availability, error rates and slow responses. The AWS Well-Architected Framework's pillars are a useful checklist for ongoing reviews: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability (AWS).
Assign ownership. Someone must own identity, patching, backups, cost and incident response (the website security checklist has a monthly, quarterly and annual calendar), whether that is an internal person or a managed service provider with a clear contract.
Choosing help: questions for a migration partner
ASD's ACSC suggests asking managed service providers whether they implement better-practice security such as the Essential Eight, administer systems securely, monitor activity, assess systems regularly, and can respond to incidents (ACSC). Add these migration-specific questions:
- How will you run discovery, and what will it produce?
- Which approach do you recommend for each system, and why?
- How will you test, cut over and roll back each wave?
- Where will data, backups and logs be stored, and who can access them from where?
- Who owns the cloud accounts, billing and root credentials? (It should be us.)
- How will you set up cost monitoring, and what will running costs be?
- What documentation and training will we receive at handover?
Hypothetical example: an accounting practice
This example is hypothetical. A Canberra accounting practice runs a file server, a practice management database and remote desktop access from a server cupboard whose hardware is out of warranty. The practice is covered by the Privacy Act because of the client information it holds and its turnover.
Discovery shows the practice management product now offers a cloud-hosted version, so that system is repurchased rather than rehosted, and its integration with the practice's accounting software is rebuilt using the approach in API integration for Australian businesses. Files move to a managed document service in an Australian region, with MFA and access reviews. A legacy reporting tool with two users is retired after its data is exported. Remote desktop is decommissioned. Backups are configured separately and a restore is tested before the old server is switched off.
Common mistakes
- Migrating without a complete inventory and dependency map.
- Assuming the provider handles security and backups.
- Rehosting everything, then paying cloud prices for on-premises design.
- Choosing an Australian region and ignoring overseas support, logging and AI services.
- Letting a supplier own the cloud account or root credentials. The supplier selection checks apply here too.
- Switching off the source before data is verified.
- No budgets or alerts until the first surprising invoice.
Sources
Regions: AWS Regions; Microsoft Azure regions list; Google Cloud regions and zones.
Security and responsibility: AWS shared responsibility model; Microsoft, shared responsibility in the cloud; ACSC, cloud shared responsibility guidance; ACSC, questions to ask managed service providers; Home Affairs, ransomware payment reporting factsheet.
Privacy and government: OAIC, APP guidelines chapter 8; ASD, IRAP; Hosting Certification Framework.
Methods: AWS, migration strategies; AWS Well-Architected pillars.
The wave plan, checklists and example are ours. Regions and services change; check current availability. Nothing here is legal advice or ZSpace client data.
Conclusion
A successful cloud migration in Australia starts with a clear reason and a complete inventory (and, where AI services are involved, the controls in AI governance for Australian businesses), chooses an approach per workload, treats data location as a privacy question rather than a checkbox, and accepts that security and cost are your responsibility after the move. Migrate in tested waves, keep a way back, and govern costs from the first day. After the move, see cloud cost optimisation to keep spend under control. After migrating, see cloud security posture reviews.
Planning a move to the cloud?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications and cloud-hosted systems. If you are deciding what to move, rebuild or replace, we are happy to talk it through.
Common questions.
No. Major cloud providers secure their infrastructure, but under the shared responsibility model you remain responsible for identity, access, configuration, data protection and much of the patching. A well-configured cloud environment can be more secure than an office server; a poorly configured one can expose data publicly. Security improves only if you design and operate it well.