A migration involves more than deploying a destination and copying data. You need to understand dependencies, rehearse the process, validate the result, decide when to move traffic, and keep a clear recovery path.

I’ve put together Azure Migration Lab to make those decisions part of a practical learning journey. The repository combines Terraform infrastructure, PowerShell orchestration, a sample Windows application, and a workbook for exploring the migration lifecycle.

You can find the complete project in the Azure Migration Lab repository.

Understand the source and target

The lab uses two isolated environments hosted in Azure. The source simulates a small existing Windows workload, making the exercise self-contained. The environments communicate through private network peering.

• Source: a Windows Server 2022 VM running IIS, SQL Server 2022 Express, and an SMB share.

• Target: a newly built IIS VM, Azure SQL Database, and Azure Files.

• Application: a small .NET catalog application with seeded records, dependency health checks, and a write fence.

The target application host is built fresh. Application content, configuration, database records, and files move through separate paths. Azure Migrate CSV import is available as an optional assessment exercise, while real on-premises discovery is covered in extension guidance.

Four Terraform stacks with separate responsibilities

The infrastructure is divided into four independently managed stacks, each with its own state:

• Foundation establishes the shared infrastructure.

• Source provides the existing sample workload.

• Target provisions the destination resources.

• Cutover manages the private DNS selection used to direct application traffic.

This structure makes resource ownership and lifecycle decisions visible. Provisioning a destination, switching traffic, and retiring a source are separate operations, with different consequences.

Follow the migration journey

The scenario workbook provides commands, checkpoints, and evidence requirements across six phases.

1. Prepare and provision

Choose an environment profile, confirm the subscription and region, and review the expected resource footprint. Run the prerequisite checks and inspect Terraform plans before provisioning. Seed the source application and record a baseline that you can compare with the target later.

2. Discover and assess

Inventory the application, database, host, and files. Identify dependencies and compatibility limits, then define the target approach. Establish acceptance criteria, migration-wave information, and the deadline for choosing rollback before starting the transfer.

3. Rehearse the move

Rehearsal transfers the workload while the logical application name remains directed at the source. Inspect application deployment, database comparisons, file manifests, and elapsed time. Record defects and resolve them before the final attempt. Reset the rehearsal target through the documented workflow before final migration.

4. Migrate and validate

During the final copy, the source application’s write fence prevents new application writes. The migration process then transfers the supported database and sample files.

The SQL exercise is deliberately limited to the sample dbo.Catalog schema. It uses a portable database export and BACPAC import. Other databases need their own compatibility assessment and migration design.

File validation checks expected paths, lengths, content hashes, and supported timestamps. General SMB permissions and NTFS ownership need separate testing.

5. Cut over and practise rollback

Cutover changes the private application name to the validated target. Check DNS resolution and the application’s returned site identity to establish where requests actually arrive.

The target remains write-fenced during the acceptance window. Practise rollback before acceptance, while the retained source provides the defined return path. After acceptance, new target writes can create divergence, so the baseline blocks simple rollback at that point. Recovery then needs a separate reconciliation or forward-fix plan.

6. Accept, retire, and clean up

Complete the acceptance record before enabling the final operating state. Retire the source only after the decision is explicit and documented. Finish by destroying the disposable lab and checking what remains. Keep local state and operation evidence until teardown is confirmed.

Make evidence part of the exercise

Review completed results and retain the evidence associated with each migration attempt. Useful records include database content signatures, file manifests, application readiness results, DNS observations, and timestamps.

A matching row count can miss changed values. An HTTP response can still hide a broken database connection. The lab encourages checks that examine the dependency behind the visible response.

Choose a profile deliberately

The repository provides cheap-lab, dev, lab, and prod profiles. Even the smallest profile creates two Windows VMs, Azure SQL, storage, and private endpoints. Broader profiles add controls such as backup, workbooks, NAT egress, and governance.

Review the cost worksheet and plan a bounded learning session. Destroy the environment when practice is complete.

Current project status

The validation record dated 29 October 2026 documents completed local infrastructure, script, application, and documentation checks. Azure provisioning and the live migration lifecycle had not been executed in that record. Cloud deployment, data transfer, cutover, rollback, and teardown still require dated live evidence.

Start with the workbook

This lab is intended for Azure administrators, cloud engineers, and infrastructure professionals who want to practise migration decisions alongside the implementation.

Start with the GitHub repository, review the prerequisites, and work through the migration workbook linked below.

Open the migration workbook to follow the commands, checkpoints, and acceptance steps.

Which part of the migration journey would you practise first: discovery, data validation, rehearsal, or cutover planning?