Moving applications, data, infrastructure, and related operations from an existing environment into Microsoft Azure requires a planned Azure migration.
The work is rarely a single transfer of servers from one place to another. A well-run migration starts with governance, identity, networking, cost controls, and operating responsibilities, then moves workloads in waves using the right tool for each scenario. That sequence matters because a workload moved into an unfinished platform often has to be reworked later, usually under more pressure and with less tolerance for downtime.
Cloud migration can involve several service models. Some workloads remain close to their existing design on Infrastructure as a Service, where virtual machines, storage, and networks are managed in Azure. Others move to Platform as a Service, such as managed databases or application hosting, to reduce operating overhead. In some cases, a business capability is better served by Software as a Service rather than by moving the existing system at all.
Start with the landing zone, not the server list
The first practical decision is where migrated workloads will land. An Azure landing zone defines the subscriptions, management groups, identity model, network topology, policy assignments, logging approach, and role-based access control that workloads will inherit. Without this foundation, discovery may still produce a migration inventory, but the team has no stable target environment for testing, security review, or operational handover.
This is where Azure migration planning often goes wrong. Teams begin by scanning servers, then discover later that connectivity, naming standards, firewall rules, private DNS, key management, or privileged access decisions are unresolved. The result is migration rework rather than migration progress. A better pattern is to align the migration plan with Azure Cloud Adoption Framework and Well-Architected guidance, then use the landing zone as the control point for every workload wave.
A practical landing zone does not need to settle every future architecture question before the first pilot. It should, however, provide enough structure for identity federation, subscription design, hub-and-spoke or equivalent networking, policy enforcement, logging, backup boundaries, and ownership. It should also define how exceptions are approved, because migrations regularly expose legacy systems that cannot immediately conform to preferred standards.
Discover workloads and dependencies with migration decisions in mind
Azure Migrate provides discovery, assessment, and migration capabilities for supported on-premises servers, applications, databases, and virtual desktop scenarios. Its value is highest when discovery is treated as decision support rather than inventory collection. CPU, memory, disk, and network utilisation matter, but so do application dependencies, maintenance windows, licensing constraints, support status, and the people who understand each system.
Dependency discovery should look beyond obvious application-to-database traffic. Service accounts, scheduled tasks, SMTP relays, file shares, hard-coded IP addresses, certificate bindings, license servers, third-party agents, and legacy authentication paths can all interrupt a migration if they are discovered during cutover rather than during assessment. Engineers should also identify batch jobs and reporting workloads, because they often have peak usage patterns that do not appear during short observation windows.
The migration strategy should then be chosen workload by workload. A 7Rs lens is useful: rehost, replatform, refactor, rearchitect, rebuild, retire, or retain. Rehosting is typically aligned with virtual machines and replication-based movement, often using Azure Migrate and Azure Site Recovery for supported scenarios. Replatforming may move web applications to App Service, containers, Azure Kubernetes Service, or databases to managed services. Refactoring usually means changing code or architecture so the application can use PaaS services more directly. Retire and retain decisions are just as important because they prevent teams from spending effort on systems that should not move yet, or should not move at all.
Choose the right migration tool for each workload
Tool selection should follow the workload and cutover requirement. Virtual machines and physical servers commonly start with Azure Migrate assessment and replication-based migration, while disaster-recovery-style replication may involve Azure Site Recovery where supported. Web applications may require app assessment, containerisation, or an App Service migration path depending on runtime, dependencies, and deployment model.
Databases need a separate decision because application availability, schema compatibility, and data validation are tightly connected. Azure Database Migration Service supports online and offline migration patterns for supported database engines and targets. An offline migration may be acceptable for a small internal application with a defined outage window. A business-critical system may need continuous synchronisation, a rehearsed final cutover, and application-level validation before traffic is switched.
Target choice matters as much as tooling. A SQL Server workload that requires broad instance-level compatibility may fit Azure SQL Managed Instance, while a more modernised application may fit Azure SQL Database. File servers may move towards Azure Files using copy and synchronisation tooling, while virtual desktop estates need a path designed around Azure Virtual Desktop, user profiles, identity, and application delivery. The important point is that no single migration tool covers every workload equally well.
Build the migration runbook around waves
A migration runbook should be written for execution, not governance theatre. It should identify the workload owner, technical owner, business approver, source environment, target Azure resources, dependency list, test plan, cutover window, rollback condition, monitoring checks, and handover owner. Each wave should be small enough that the team can understand what changed and large enough to produce meaningful progress.
Pilot waves are especially useful because they test the landing zone as well as the migration process. A low-risk workload can reveal routing issues, DNS assumptions, image hardening gaps, access model problems, monitoring noise, and backup failures before a critical application is involved. The pilot should also verify whether performance baselines from the source environment are good enough to compare against Azure after migration.
- Confirm the application owner, business impact, and approved migration strategy.
- Validate discovery data, dependency maps, performance baselines, and licensing constraints.
- Provision or confirm the target Azure resources, network paths, secrets, certificates, and access roles.
- Run replication, data synchronisation, or deployment according to the selected migration method.
- Test application functions, integrations, monitoring, backup, security controls, and performance.
- Execute cutover during the agreed window and verify service-level objectives before release.
- Keep rollback available until the agreed stability period has passed.
The runbook should be updated after each wave. If a firewall rule, certificate renewal process, deployment script, or database validation query changes during the pilot, that change should be reflected before the next migration. This is how migration becomes repeatable rather than dependent on informal knowledge.
Plan cutover and rollback before production is touched
Cutover is where technical migration becomes business change. A practical cutover model starts with performance baselines and pilot migrations, then defines freeze windows, data pre-staging, final synchronisation, DNS changes, SSL or TLS certificate updates, application smoke tests, monitoring checks, and user validation. Online cutovers can reduce downtime for supported applications, but they do not remove the need for a rollback plan.
Rollback should be specific to each application. A generic instruction to “restore the old service” is not enough. The team needs to know whether data written after cutover can be replayed, whether DNS time-to-live values have been lowered in advance, whether source systems remain read-only or writable, and who has authority to call rollback. Some database migrations also require checksum validation, row counts, query-level performance testing, and application transaction checks before the business can accept the new platform.
One anonymised example illustrates the pattern. A regional services company needed to move a customer portal and its SQL Server back end from ageing virtualisation hosts. The team first built a landing zone with private connectivity, Azure Policy, central logging, and role separation, then migrated a non-critical reporting service as a pilot. The production portal used continuous database synchronisation, a freeze window for final writes, pre-tested DNS changes, and a rollback plan that kept the source environment intact until post-cutover checks were complete. The useful outcome was not simply that the application moved; it was that later waves reused the same evidence, approval model, and validation steps.
Control migration cost from day zero
Cost control should begin during assessment because migration sizing is often based on over-provisioned on-premises resources. Right-sizing recommendations, utilisation history, storage performance requirements, and operating hours should be reviewed before target resources are created. Tagging standards, budgets, and cost alerts should be active before workload teams begin building in Azure, otherwise the finance view of the migration will lag behind the technical reality.
The obvious costs are compute, storage, and managed services. The less obvious costs often come from data egress, Log Analytics ingestion, backup storage, replication storage during migration, Key Vault operations, firewall throughput, load balancing, private endpoints, and network connectivity changes such as ExpressRoute routing adjustments. These items are rarely the largest line items in isolation, but they can surprise teams when many workloads arrive at once.
After migration, predictable workloads may be candidates for Reservations or Savings Plans, and eligible Windows Server or SQL Server licences may benefit from Azure Hybrid Benefit where licensing terms are met. Those decisions should follow observed usage, not assumptions made before cutover. A common mistake is to commit too early, before the team has rightsized virtual machines, removed temporary migration resources, and confirmed which workloads will remain on IaaS rather than moving later to PaaS.
Make day-two operations part of the migration scope
A workload is not fully migrated when users can log in. It is migrated when it can be monitored, backed up, patched, secured, restored, and owned in its new environment. Day-two operations should therefore be part of the runbook, not a separate programme that begins after the migration team has moved on.
Operational handover should cover alert rules, dashboards, log retention, backup policies, disaster recovery design, vulnerability management, patching, certificate renewal, identity reviews, and incident response. Azure Policy can help enforce baseline requirements, but it does not replace ownership. Platform teams and application teams need a clear agreement on who manages shared services, who responds to application alerts, who approves network changes, and who pays for shared infrastructure.
Security also needs post-migration attention. Secrets and certificates should be reviewed and rotated where appropriate, privileged access should be checked against the intended RBAC model, and legacy administrative paths should be removed once they are no longer needed. In practice, many of the highest-risk issues after a migration are not caused by Azure services themselves; they come from old trust relationships, unmanaged service accounts, and temporary exceptions that become permanent.
Where training fits into the migration plan
Azure migration changes the daily work of infrastructure engineers, database administrators, security teams, and operations staff. Teams that understand only the source environment may be able to move workloads, but they may struggle to operate them safely afterwards. This is why migration planning should include skills for Azure networking, identity, governance, monitoring, cost management, backup, and workload-specific services.
Structured Azure training can help teams build shared vocabulary before decisions are made under cutover pressure. Readynez covers Microsoft Azure training across role-based skills and certifications, which can be useful when a migration team needs to align platform, operations, and workload owners around the same operating model. The training need should be driven by the migration design rather than by a generic course list.
Applying the runbook to real Azure migrations
A reliable Azure migration is built through sequencing. The landing zone comes before workload movement, discovery informs migration strategy, tool choice follows workload requirements, and cutover planning includes rollback rather than assuming everything will proceed cleanly. Post-migration optimisation then turns a successful cutover into a stable operating model.
The most effective next step is to select one representative workload and use it to test the full path: landing zone controls, Azure Migrate assessment, tool selection, migration execution, validation, cost monitoring, backup, and operational handover. Teams that need to strengthen Azure skills before or during that process can use Readynez Microsoft Azure training as part of a broader migration readiness plan.
