A cloud migration can look straightforward on a project plan: move servers, switch users over, retire old infrastructure. In practice, the difficult work happens before anything moves. This Azure migration planning checklist helps Australian organisations identify dependencies, security risks, cost drivers and operational responsibilities before a migration affects daily business.
The aim is not simply to get workloads running in Azure. It is to create an environment that is secure, supportable and cost-controlled after go-live. A rushed migration may replace ageing servers, but it can also carry across poor access controls, unclear ownership and unnecessary costs.
Every workload should have a reason to move. For one organisation, the driver may be reducing the risk of an ageing on-premises server. For another, it may be supporting mobile staff, improving disaster recovery, meeting data residency expectations or retiring an expensive hardware refresh.
Write down the business outcome for each migration group and agree how success will be measured. Useful measures include acceptable downtime, recovery targets, application response time, user impact and expected monthly Azure spend. This gives decision-makers a practical basis for prioritising work rather than treating every server as equally urgent.
It also exposes workloads that should not be migrated unchanged. Some legacy applications are cheaper to retire, replace with SaaS, or keep temporarily on existing infrastructure while a replacement is planned. Azure is not automatically the right destination for every workload.
A reliable plan begins with a complete and current inventory. Do not rely on an old asset register or assumptions from a previous IT provider. Identify physical and virtual servers, applications, databases, file shares, integrations, licences, service accounts, network equipment and user groups.
For each workload, document its owner, business purpose, operating system, data classification, peak usage periods and technical dependencies. An accounting application may depend on a database server, a file share, a scheduled task and a third-party payment integration. Migrating only one part can cause an outage that is difficult to diagnose under pressure.
Your assessment should also establish whether each workload is suitable for one of four paths:
Rehosting is often the fastest route out of a data centre, but it can retain legacy complexity and create higher ongoing compute costs. Replatforming takes more preparation, yet may reduce maintenance and improve resilience. The right choice depends on application value, risk, budget and the organisation’s appetite for change.
For healthcare, professional services and organisations working with government or regulated customers, data handling requirements must shape the architecture. Identify where sensitive data sits, who can access it, how long it must be retained and whether Australian data residency is required by contract, policy or customer expectation.
This is also the point to identify shadow data. A server may be formally classified as low risk while containing exports, backups or scanned documents that are not. Migration is an opportunity to correct those gaps, not replicate them in a new location.
Security should be designed into the landing environment before workloads arrive. Start with identity because it controls how administrators, staff and services access Azure resources. Review Microsoft Entra ID roles, privileged accounts, multi-factor authentication, conditional access, break-glass accounts and the use of separate administrator identities.
Apply least-privilege access from the outset. Avoid assigning broad subscription-level permissions simply because it is convenient during a project. Temporary access tends to become permanent, particularly once operational teams are focused on the next priority.
The environment should also include clear standards for network segmentation, firewall rules, encryption, logging, vulnerability management and endpoint protection. Essential Eight-aligned controls provide a useful practical benchmark, especially for organisations seeking a measurable improvement in security posture rather than a one-off compliance exercise.
Backups need separate attention. Confirm what is being backed up, how frequently, where backup data is retained, how long recovery takes and who has authority to initiate a restore. A backup job showing green is not proof of recoverability. Test restores for critical systems before and after migration.
Azure subscriptions, resource groups, naming standards and tags may sound administrative, but they determine whether the environment remains manageable. Without them, support teams struggle to identify workload owners, allocate costs or investigate incidents quickly.
Establish a landing zone that defines how subscriptions are separated, how networks connect, which regions are approved and how policies are applied. Smaller organisations do not always need a highly complex enterprise design, but they still need consistent guardrails. A simple structure that staff can operate confidently is better than an elaborate design no one maintains.
Tag resources with meaningful fields such as business unit, application owner, environment and cost centre. This enables readable reporting and gives finance leaders a clear view of what Azure is costing the business. It also makes orphaned resources easier to spot when projects finish or staff change roles.
Cloud spend is variable by design. Virtual machine size, storage type, data egress, backup retention, security tooling and resources left running after hours can all affect the bill. A migration business case based only on server replacement costs is incomplete.
Create an expected monthly run-rate for each workload, then include monitoring, backup, support and contingency. Set budgets and alerts at subscription and cost-centre level. Where workloads have predictable demand, committed-use options may reduce costs, but only after capacity is understood. Flexibility is valuable when a system is new or usage is uncertain.
Do not move every workload in one weekend unless the environment is unusually simple and the business can tolerate the risk. Group systems into migration waves based on dependency, criticality and business impact. Start with a lower-risk workload to validate the process, tools, access model and monitoring.
Each wave should have a documented runbook covering the migration method, change window, responsible people, communications, testing steps, acceptance criteria and rollback decision. Staff need plain-English advice about what will change, when it will happen and where to get help. Vague notices create unnecessary support calls and reduce confidence.
A sound cutover plan answers practical questions: Who confirms data synchronisation is complete? Who tests the application from a user perspective? What happens if a supplier integration fails? How long can the business operate without the system? At what point do you stop troubleshooting and roll back?
Schedule migrations around business reality. Month-end processing, payroll, project deadlines and field operations should carry more weight than a technically convenient weekend. The lowest-risk window is the one that gives the business time to verify outcomes and recover if required.
A workload that starts successfully in Azure is not necessarily ready for production. Test user access, application performance, printing, integrations, scheduled jobs, backups, monitoring alerts and recovery procedures. Ask the people who use the application every day to validate the functions that matter most.
Then test the support model. Confirm that alerts reach the right team, escalation paths are known, documentation is current and ownership is clear. If an issue occurs at 7 pm on a Sunday, the business needs to know who is accountable for responding, not merely which portal contains the logs.
This is where proactive managed cloud operations earn their place. Continuous monitoring, patching, security reviews and cost optimisation should be part of the operational handover, not optional extras added after an incident.
After each migration wave, compare results with the success measures set at the beginning. Review performance, incidents, user feedback, security findings and actual costs. Decommission old servers, licences, backup jobs and network rules only after the agreed validation period has passed. Keeping redundant systems “just in case” can create both security exposure and avoidable expense.
Update disaster recovery documentation, asset records, support runbooks and ownership registers. A migration is complete when the service is stable and governed, not when the data-copy tool reaches 100 per cent.
The best migration plans make space for decisions, testing and accountability. Move at a pace that protects the business, keep costs visible from day one, and make sure the Azure environment is ready to operate long after the project team has stepped away.