Publish Date
17/09/2026
Categories
Blogs
A cloud strategy explains why the organisation should move. An Azure migration checklist tests whether the organisation and each workload are actually ready to move. A workload can be technically compatible with Azure and still create avoidable risk if dependencies, recovery objectives, costs, security controls, owners or rollback steps are unclear.
Before using the checklist – confirm strategy and readiness
Our checklist is for businesses that have already made the strategic decision to move to Azure.
Before focusing on migration waves, landing zones and cutovers, make sure your organisation understands why it’s moving to Azure and what success looks like once the migration is complete.
That means having a clear business case, understanding your current environment and agreeing how Azure fits into your wider technology strategy.
If you’re still answering those questions, it’s worth completing a Cloud Readiness Assessment and developing a formal cloud migration strategy before moving into detailed planning.
Phase 1 – Confirm the Business Case, Owners and Success Criteria
Before anyone starts discussing migration tools or timelines, it’s important to know who owns the project and who can make decisions when issues arise.
One of the most common causes of migration delays isn’t technology – it’s unclear ownership.
At a minimum, there should be an a business owner, a technical lead and someone responsible for managing the migration itself. Each role should understand its responsibilities and how decisions will be escalated if needed.
This is also the point to agree what success actually looks like. Are you trying to reduce infrastructure costs? Improve resilience? Retire ageing hardware? Increase flexibility for future growth?
It’s important to define operational expectations too. For example, how quickly should services recover following an outage? How much data loss would be acceptable in a worst-case scenario? These are often referred to as Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
Finally, document known risks, dependencies, assumptions and constraints. It sounds simple, but it makes planning much easier later on.
Phase 2 – Discover Workloads and Dependencies
You can’t build a reliable migration plan if you don’t fully understand what you’re migrating.
A server inventory is a good starting point, but effective discovery goes much further. You need visibility into applications, databases, storage platforms, user groups and the relationships between them.
A system that looks low priority on paper may support a critical business process or provide data to multiple applications. Missing these dependencies is one of the biggest causes of migration issues.
This stage should also identify unsupported operating systems, in-house support limitations, and workloads with varying levels of business criticality. This assessment helps determine which applications and services can be retired, replaced, retained, or migrated, while ensuring that business-critical workloads remain fully supported, secure, and aligned with operational requirements throughout the transformation.
Microsoft’s Azure Migrate tool can help discover workloads and map dependencies, but findings should always be checked with system owners to make sure the picture is accurate.
Phase 3 – Assess Readiness, Sizing and Migration Approach
Once discovery is complete, it’s time to assess what each workload needs in Azure.
Look at application compatibility, performance requirements, storage needs, networking requirements and expected data transfer volumes. These all influence the target architecture and migration approach.
Avoid simply copying existing hardware specifications into Azure. Many on-premises environments have grown over time and may be oversized. Using actual utilisation data often produces a more cost-effective result.
This is also where you decide whether a workload should be rehosted, replatformed, refactored, replaced, retired or retained.
Phase 4 – Build and Validate the Azure Landing Zone
Think of an Azure landing zone as the foundation your workloads will move into.
Before migrating anything, the Azure environment should be structured, governed and secured. That includes subscriptions, management groups, resource groups, naming standards and tagging policies.
Identity should be managed through Microsoft Entra ID, with role-based access controls in place from the start. Networking, DNS, connectivity and segmentation should also be tested before production workloads arrive.
Just as importantly, monitoring, alerting, backup and governance controls should be established early rather than added later.
Phase 5 – Validate Security, Identity, Compliance and Resilience
Security should be embedded in the migration from the beginning.
Review multi-factor authentication (MFA), Conditional Access policies and least-privilege access controls. Confirm that monitoring, vulnerability management and Microsoft Defender protections are configured appropriately for your environment.
If your organisation operates in a regulated industry, check compliance, contractual obligations and data residency requirements before migration begins.
Recovery capabilities also need testing. Backup jobs completing successfully is one thing. Successfully restoring systems and meeting agreed RTOs and RPOs is another.
Phase 6 – Check Cost, Licensing and Commercial Assumptions
A common mistake is focusing solely on virtual machine pricing when calculating cloud costs.
A realistic cost model should include storage, networking, backup, monitoring, security services and data transfer alongside compute resources.
It’s also worth reviewing Microsoft licensing options and eligibility for Azure Hybrid Benefit, which may reduce ongoing costs for some organisations.
Before migration begins, establish budgets, alerts and tagging standards so spending can be monitored and optimised from day one.
Phase 7 – Group Workloads into Migration Waves
Not everything needs to move at once.
Migration waves should be planned around dependencies, business priorities and operational capacity rather than arbitrary deadlines. Closely connected applications and data sets are often easier to migrate together.
Most organisations begin with a pilot wave. The goal is to select something representative enough to provide useful lessons without introducing unnecessary risk.
For every wave, define owners, test plans, communications and rollback procedures before migration work starts.
Phase 8 – Pilot, Test and Remediate
A pilot helps prove that the migration approach works in practice.
Testing should cover more than whether a workload starts successfully in Azure. Performance, integrations, user access, monitoring and security controls should all be validated.
Business users should also be involved. Technical success doesn’t always mean operational success.
Use what you learn from the pilot to refine future migration waves and revisit assumptions around cost, sizing and timelines.
Phase 9 – Prepare Cutover, Communications and Rollback
Successful cutovers are built on preparation.
For critical workloads, create a detailed runbook outlining each step, responsibility and escalation route. Confirm final synchronisation activities, change freezes and go/no-go approvals before migration begins.
Equally important is having a documented rollback plan. Everyone involved should understand what triggers a rollback, who makes the decision and what actions will be taken.
Communicate expected disruption and support routes clearly to users before the migration window.
Phase 10 – Validate, Optimise and Transition to Operations
Going live isn’t the end of the project.
The weeks after migration are often where organisations gain the clearest picture of performance, costs and operational readiness.
Review service health, optimise resource sizing, verify monitoring and confirm backup and recovery arrangements are working as expected. Temporary migration resources should be removed once they’re no longer needed.
Only after validation should legacy infrastructure be decommissioned and ownership formally transition into ongoing operations.
Your Azure migration checklist
If you would like to download the checklist, please click here.
Phase 1: Governance & Success
□ Owners identified (including Project Lead)
□ Budget agreed
□ Success criteria defined
□ RTO/RPO documented
Phase 2: Discovery
□ Asset inventory complete
□ Dependencies mapped
□ Review of in-house support
□ Retired systems identified
Phase 3: Assessment
□ Compatibility checked
□ Azure region selected
□ Right-sizing completed
□ Migration strategy assigned
Phase 4: Landing Zone
□ Governance structure built
□ Identity controls configured
□ Network validated
□ Monitoring enabled
Phase 5: Security
□ MFA enabled
□ Compliance assessed
□ Defender configured
□ Recovery tested
Phase 6: Commercial Review
□ TCO model completed
□ Licensing reviewed
□ Budgets configured
□ Cost assumptions recorded
Phase 7: Migration Waves
□ Wave plan created
□ Pilot selected
□ Rollback plans documented
Phase 8: Testing
□ Functional tests complete
□ UAT signed off
□ Pilot findings reviewed
Phase 9: Cutover
□ Runbook approved
□ Communications completed
□ Go/no-go process agreed
Phase 10: Optimisation
□ Service validated
□ Costs reviewed
□ Documentation updated
□ Operations transitioned
Common Azure Migration Mistakes
Even well-planned projects can run into problems. The most common issues include:
- Treating discovery as a simple server inventory and missing application dependencies.
- Lifting and shifting workloads without reviewing actual resource usage.
- Building governance and security controls after workloads arrive in Azure.
- Testing technical functionality while skipping business acceptance testing.
- Starting cutover without agreed rollback criteria.
- Treating go-live as the finish line and overlooking optimisation opportunities.
When Should an SME Use an Azure Migration Partner?
Not every migration requires external support, but specialist expertise is often valuable when:
- The environment is business-critical or poorly documented.
- Applications have complex integrations or dependencies.
- Internal teams lack Azure architecture or migration experience.
- Security, compliance or availability requirements are demanding.
- Independent support is needed for landing zone design, migration planning or operational handover.
A migration partner can help reduce risk, fill skills gaps and provide additional delivery capacity throughout the project.
Planning an Azure Migration?
A successful Azure migration requires more than moving workloads from one environment to another. It takes planning, governance, testing and ongoing optimisation.
Cobweb can assess your environment, build the migration plan, deliver the move and provide ongoing Azure support once the migration is complete. Get in touch to discuss your Azure migration requirements with one of our Azure specialists.