A step-by-step cloud migration roadmap for Melbourne businesses - covering discovery, planning, lift-and-shift vs rearchitecting, testing, and cutover without the disruption.
Cloud migration is one of those projects that sounds straightforward until you’re in the middle of it. The businesses that get it right spend more time planning and less time firefighting during cutover. The businesses that get it wrong spend months cleaning up a rushed migration that created more problems than it solved.
This roadmap is for Melbourne businesses that are serious about getting cloud migration done properly - whether you’re moving from on-premises infrastructure to Azure, migrating to Microsoft 365, or shifting a line-of-business application to a hosted environment.
Phase 1: Discovery and Assessment (Weeks 1–3)
You cannot plan a migration without a clear picture of what you currently have. This phase is often underestimated, but it’s what every other decision depends on.
Inventory your current environment:
- Physical servers: age, roles, operating systems, storage, performance utilisation
- Virtual machines and their dependencies
- Applications: what they are, who uses them, what they depend on, when they were last updated
- Data volumes: total storage, growth rate, data classification (sensitive, regulated, public)
- Network: internet bandwidth, current VPN or remote access setup, firewall configuration
- Third-party integrations: what connects to what
Identify dependencies: The trickiest part of cloud migration is uncovering hidden dependencies. Application A might depend on a database on Server B, which has a scheduled task that calls a legacy API on Server C. Document these chains before you start moving anything.
Assess compliance requirements: If your business handles health records, payment card data, or other regulated information, identify which compliance frameworks apply (Australian Privacy Act, PCI-DSS, IRAP for government) and how your target cloud environment needs to be configured.
Outcome of Phase 1: A complete asset inventory, dependency map, and a shortlist of what to migrate, what to retire, and what needs rearchitecting before it can move.
Phase 2: Define Your Migration Strategy
Not everything should be migrated the same way. The two main approaches:
Lift and shift (Rehost): Take the workload as-is and move it to a cloud virtual machine. Fastest and lowest risk, but you don’t benefit from cloud-native features and you’re still running and patching an OS.
Best for: Legacy applications you can’t easily change, workloads you plan to modernise later, or anything with tight timelines.
Rearchitect (Refactor or Rebuild): Redesign the application to leverage cloud-native services - managed databases, serverless functions, containerisation. More work upfront, but lower ongoing operational overhead and better scalability.
Best for: Applications with significant ongoing usage, where cloud-native features (auto-scaling, managed patching, built-in redundancy) will deliver meaningful value.
Retire and replace: The migration is also an opportunity to assess whether every application still needs to exist. Legacy systems that could be replaced by a modern SaaS tool are often better retired than migrated.
Phase 3: Design and Planning (Weeks 3–6)
With your inventory and strategy defined, design the target environment:
Cloud provider and services selection: For most Melbourne SMBs, Microsoft Azure is the natural choice if you’re already on Microsoft 365, given the native integration and consistent identity layer. AWS and Google Cloud are strong alternatives depending on your existing stack.
Network architecture: How will users connect to cloud workloads? Direct internet access, Azure Virtual Network, site-to-site VPN, or Azure ExpressRoute for businesses requiring dedicated connectivity.
Identity and access: Azure Active Directory (Entra ID) is the foundation. Define your user groups, access policies, and multi-factor authentication requirements before you migrate anything.
Backup and DR in the cloud: Define your RTO and RPO for cloud workloads and design backup accordingly. Azure Backup, Azure Site Recovery, and third-party tools like Veeam are the common options.
Cost modelling: Use the Azure Pricing Calculator to estimate monthly running costs. Understand the difference between Reserved Instances (committed 1–3 year pricing, up to 72% cheaper) and pay-as-you-go. Budget for egress costs if you’re moving large data volumes.
Phase 4: Migration Execution
Migrate in waves, starting with the lowest-risk workloads:
Wave 1 - Non-critical systems: File servers, development environments, test systems. This builds team confidence and surfaces surprises before you touch production.
Wave 2 - Business applications: Line-of-business applications, CRM, ERP, internal tools.
Wave 3 - Critical systems: Financial systems, email (if not already on Microsoft 365), production databases.
For each workload:
- Prepare the target environment and test connectivity
- Perform a test migration in non-production
- Validate application functionality and performance
- Schedule the production migration during a maintenance window
- Run parallel environments briefly if the risk warrants it
- Cut over, monitor closely, and keep rollback option available for 48–72 hours
Phase 5: Testing and Validation
Before each cutover, validate:
- Application functionality - does it do what it’s supposed to do?
- Performance - is it as fast as or faster than on-premises?
- Integration - do all dependent systems connect correctly?
- Security - are firewall rules, network security groups, and access policies correct?
- Backup - have you taken a backup in the new environment and verified it restores?
Don’t rush this phase under deadline pressure. A failed cutover costs significantly more time and credibility than a delayed one.
Phase 6: Cutover and Stabilisation
Cutover communications matter. Your team should know:
- When the migration window is
- What will be unavailable and for how long
- Who to contact if something isn’t working after cutover
- What the rollback plan is if critical issues emerge
After cutover, allow a 2–4 week stabilisation period with close monitoring before decommissioning on-premises systems. Don’t pull the plug on your old environment until you’re confident the new one is solid.
Common Melbourne Business Mistakes to Avoid
- Migrating without cleaning up first: Moving years of accumulated mess to the cloud just moves the problem and may increase costs
- Underestimating the network: Cloud workloads depend on reliable, fast internet. If your office internet is marginal, upgrade it before you migrate
- Skipping the cost review: Cloud costs need monthly attention. Unmonitored, they grow quietly
- Ignoring SaaS backup: Microsoft 365 data doesn’t back itself up to a recoverable standard - this is a separate workstream
Ready to plan your cloud migration? Contact CX IT Services and we’ll help you build a migration plan that reflects your Melbourne business’s actual requirements.
