Skip to content

Migration and modernization

Move workloads to Azure through controlled migration waves.

We use Azure Migrate and workload-specific tooling to discover source environments, select treatment by component, prepare the destination, execute cutovers, and stabilize services.

Migration sequence

Migration and modernization technical model
  • VMware
  • Hyper-V
  • Physical
  • Database
  1. 00FoundationConnectivity · identityReady landing zone
  2. 01Wave 1Low couplingRehost · retire
  3. 02Wave 2Shared dependenciesReplatform
  4. 03Wave 3Complex data pathsModernize · retain
Illustrative workload grouping; actual waves follow discovered dependencies and readiness.
Sources
Hybrid and cloudVMware, Hyper-V, physical, and supported other-cloud sources.
Tracks
VM, app, database, dataEach track has its own replication and validation method.
Control unit
Migration waveDependencies, change windows, rollback, and acceptance stay aligned.

Migration tracks

Migration treatment is selected for each workload component.

A workload may use several tracks and does not need one uniform treatment.

01

Virtual machines

Discover, assess, replicate, test, and cut over VMware, Hyper-V, physical servers, and supported other-cloud VMs.

  • Azure Migrate
  • Azure Virtual Machines
02

Applications

Rehost or replatform application tiers after compatibility, session, integration, and deployment requirements are understood.

  • App Service
  • Container Apps
  • Azure Kubernetes Service
03

Databases

Assess engine compatibility, migration method, downtime tolerance, integrity checks, and rollback for the selected Azure data target.

  • Azure SQL
  • Azure Database Migration Service
04

Data

Plan transfer, synchronization, retention, validation, encryption, and cutover for files, objects, and analytical data.

  • AzCopy
  • Azure Data Box
  • Azure Storage

Wave lifecycle

Each wave is prepared, rehearsed, cut over, and stabilized.

Entry and exit criteria are tied to workload criticality and outage tolerance.

  1. 01

    Discover and group

    Confirm inventory, dependencies, owners, business windows, data flows, and service criticality.

  2. 02

    Prepare

    Complete target sizing, landing-zone prerequisites, remediation, replication, testing, and runbook drafting.

  3. 03

    Rehearse and cut over

    Test the sequence, confirm go or no-go authority, execute the approved change, and verify technical and business functions.

  4. 04

    Stabilize and close

    Monitor behavior, resolve defects, validate backup and cost allocation, remove source systems only after approval, and transfer support.

Wave gates

A wave advances only when its required checks are complete.

Gate content varies by criticality, but ownership and status remain explicit.

AreaReadiness checkTypical artifactApproval role
DestinationIdentity, network, policy, quota, monitoringLanding readiness recordPlatform owner
WorkloadCompatibility, performance, integration, dataTest results and exceptionsApplication owner
CutoverSequence, communications, freeze, rollbackCutover runbookChange authority
Service acceptanceTelemetry, backup, support, cost, defectsStabilization closureService owner

Migration artifacts

The migration record connects portfolio intent to each cutover.

Artifacts are updated as discovery improves and rehearsal exposes new constraints.

  1. 01

    Portfolio register

    Workload composition, source, target treatment, dependency group, wave, owner, and constraint.

  2. 02

    Wave plan

    Scope, entry criteria, sequence, environments, test windows, communications, and release controls.

  3. 03

    Cutover runbook

    Timed steps, command ownership, validation, go or no-go points, rollback triggers, and contacts.

  4. 04

    Stabilization record

    Observed behavior, defects, performance, cost, backup result, open work, and support transfer.

Migration fit

Migration begins when source access and destination ownership are available.

A discovery assignment can precede migration when the portfolio is incomplete.

Questions to answer before scoping

  1. Which outage and rollback tolerances apply?
  2. Is the Azure destination ready for the first wave?
  3. Who validates each business service?
Bring us the current estate

Best suited to

  • Datacenter exits
  • VMware or Hyper-V moves
  • Selected workload modernization during migration

Needed to begin

  • Approved source discovery access
  • Azure tenant and landing-zone owner identified
  • Business validation contacts available

Customer responsibilities

  • Approve outage windows and change controls
  • Confirm data retention and source decommissioning
  • Run business acceptance

Not included by default

  • Unsupported source platforms or undocumented dependencies
  • Application rewrites not included in the workload scope
  • Source shutdown before customer approval