60% of cloud migration projects miss their initial deadlines. The root cause is almost never technical. It is the absence of structured preparation. We have guided dozens of SMBs through their migration to Azure. What we consistently observe: the teams that succeed do not outperform others technically. They prepare better. This checklist covers everything that must be done — and validated — before you migrate your first server.
Phase 1 — Inventory and assessment (before touching anything)
Every migration starts with a thorough inventory of your existing environment. No estimates, no approximations: a factual inventory, server by server.
For each on-premises machine, document:
- The role: domain controller, file server, database, ERP, line-of-business application
- The OS and version: Windows Server 2012 R2 has been out of support since October 2023 — that is a prioritization criterion, not a footnote
- Actual workload: average CPU and RAM over 30 days, not one-off peaks
- Application dependencies: which server communicates with which, on what port, using what protocol
Recommended tool: Azure Migrate. Free, it scans your on-premises environment, collects performance metrics over several weeks, and automatically generates right-sized Azure VM recommendations. That handles 80% of the assessment work automatically.
Once the inventory is complete, classify each server into one of these three categories:
- Lift & shift — move it as-is into Azure, without modifying the application. Applies to most infrastructure servers.
- Refactor — adapt the application to take advantage of Azure managed services (Azure SQL, Azure App Service). Takes longer, but cheaper to run over time.
- Retain — keep on-premises for now. Some highly specific line-of-business applications are not yet ready to move to the cloud.
Estimated duration: 2 to 5 days depending on the size of your environment. An SMB with 100 workstations and 15 servers: budget 3 days.
Phase 2 — Target architecture and sizing
The classic mistake: reproducing your on-premises infrastructure identically in Azure. That is not a cloud migration — it is a datacenter relocation. And it costs unnecessarily more.
Azure runs on pay-as-you-go. Overestimating resources costs you every month. Underestimating creates performance problems. Sizing must be based on real data collected by Azure Migrate, not rough estimates.
Before committing any budget, run the numbers through the Azure Pricing Calculator. This free tool lets you model your target architecture and get a precise monthly cost estimate.
Two structural decisions to make at this phase:
- The Azure region: for a French SMB, the choice is clear — France Central (Paris). Optimal latency, GDPR compliance with data that never leaves French territory.
- The network strategy: a Site-to-Site VPN (encrypted tunnel between your local network and Azure) is sufficient for most SMBs. ExpressRoute (a dedicated connection bypassing the public internet) is reserved for high-bandwidth requirements or strict compliance needs.
Phase 3 — Security and compliance (before migration, not after)
Security is not a post-migration step. It is a prerequisite. Configuring security rules after you have migrated production servers is like opening windows and then closing the shutters.
Four pillars to validate before you start:
1. Backup policy. Azure Backup — a managed service with no infrastructure to manage. Minimum recommendation: 30-day retention, with a successful restore test before going live. A backup you have never tested is not a backup.
2. Disk encryption. Azure Disk Encryption — verify this explicitly on VMs migrated from on-premises. All data at rest must be encrypted, without exception.
3. Identity management. Migration is the right moment to consolidate access management. Microsoft Entra ID centralizes authentication for all your users and applications. It is the foundation of your cloud security.
4. GDPR compliance. Entra ID Conditional Access lets you enforce context-aware access conditions: access only from managed devices, mandatory MFA outside the corporate network, blocking connections from high-risk countries. These policies are configured before migration.
Phase 4 — Migration in waves (never all at once)
Migrating your entire infrastructure over a single weekend is the scenario that generates the most severe production incidents. The wave approach — progressive migration, validated at each step — is not excessive caution. It is the method that lets you sleep on Monday morning.
Wave 1 — Dev and test environments. Zero production risk, maximum learning for the teams. This is where you validate procedures, catch dependency issues, and train administrators on Azure tooling. Recommended minimum before moving to the next wave: two weeks in production.
Wave 2 — File servers and non-critical applications. Network shares, print servers, low-criticality internal applications. This is the wave where you refine your migration process and validate real network performance.
Wave 3 — Critical servers. ERP, production databases, email, core business applications. This wave only begins after full validation of the first two. It is planned with business stakeholders — not just IT.
Absolute rule: each wave goes live and is validated for a minimum of two weeks before migrating the next wave.
The 5 most common mistakes (and how to avoid them)
1. Migrating without testing disaster recovery. Having Azure Backup configured is not enough. You must have run a full restore before going live. The restore must be documented, timed, and signed off by business stakeholders.
2. Underestimating outbound bandwidth costs. Azure charges for egress traffic — data leaving Microsoft datacenters to the internet or to your on-premises network. This cost (egress cost) can represent 10 to 20% of your monthly bill.
3. Overlooking Windows Server licenses. The Azure Hybrid Benefit lets you reuse your existing Windows Server and SQL Server on-premises licenses for Azure VMs at no additional cost. Across a fleet of 20 Windows Server VMs, the savings can reach 40% of your compute bill.
4. No post-migration monitoring. Azure Monitor collects performance metrics, application logs, and generates alerts. It must be configured before going live. Also set up a budget alert in Azure Cost Management so your bill never comes as a surprise.
5. Training teams after migration rather than before. An administrator discovering the Azure console on the day of cutover makes poor decisions under pressure. Training must begin during the assessment phase — in the dev/test environments of wave 1.
What an Azure migration actually costs for a 100-person SMB
The honest range for a complete migration — initial audit, wave-based migration, team training — falls between €15,000 and €50,000 in services. The spread is explained by:
- Number of servers: an SMB with 8 servers and few dependencies sits at the low end. 25 servers with interconnected line-of-business applications sits at the high end.
- Complexity of application dependencies: applications that communicate over undocumented protocols extend the assessment and testing phases.
- Refactoring requirements: if applications need to be adapted to run cloud-natively, development costs are added on top of migration costs.
The long-term savings are real: elimination of hardware refresh costs, closure or downsizing of the server room, removal of electricity and cooling costs, end of hardware maintenance contracts. Over 3 years, Azure migration becomes cost-positive for the majority of SMBs with 50 or more workstations.
To go deeper on cloud infrastructure security, read our dedicated page on Azure Cloud Security. For business continuity and recovery planning topics, see our Backup & Disaster Recovery page. And to get started with a free assessment, request a free assessment — we map your environment and produce a migration plan tailored to your situation.