Migration And Modernization Sequencing — Azure DevOps Engineer (AZ-400)
Modernization Sequencing Fails When Dependencies Move Out of Order
The candidate designs a parallel cutover: lift the application tier and migrate the database simultaneously to minimize downtime. The scenario specifies a legacy application with hard-coded connection strings and no retry logic. Moving the database first orphans the application; moving the application first breaks it against an on-premises database unreachable from Azure VNet without additional networking configuration. Dependency order is not an implementation detail—it is the answer.
What This Pattern Tests
Azure migration sequencing questions test dependency-aware ordering for DevOps toolchain and application modernization. For AZ-400, migrating a CI/CD toolchain means moving source control (Azure Repos or GitHub) and package feeds (Azure Artifacts) before the build/release pipelines that consume them. For application migration, Azure Migrate assesses on-premises workloads, Azure Database Migration Service handles database replication with continuous sync, and Azure Site Recovery handles VM replication. The sequence follows data gravity: databases first (Azure SQL, Cosmos DB), application tier second (App Service, Container Apps), and presentation tier last (Static Web Apps, Front Door). The trap is migrating pipelines before their artifact sources are available in Azure, or migrating the web tier before the API it depends on.
Decision Axis
Dependency graph determines migration order: data stores and artifact repositories first, consumers and pipelines last.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether to directly translate the classic release definition topology into a YAML pipeline by mirroring existing stages and adding inline manual-approval tasks (lift-and-shift), or to decompose the classic pipeline into YAML-native equivalents — Azure Pipelines Environments with approval and branch-protection checks, reusable stage templates, and conditional deployment expressions — before shifting live traffic to the new definition.
Whether YAML environment protection rules and Artifacts retention policies must be fully provisioned before any YAML-driven deployment stage is activated, rather than after, to eliminate the unprotected deployment and artifact-publishing window that opens during the classic-to-YAML cutover.
Whether to translate existing Azure Monitor query gates from classic release definitions directly into YAML deployment-job condition expressions (lift-and-shift) or to configure YAML-native Azure DevOps Environment protection rules backed by the same Azure Monitor queries—where only the latter preserves environment-scoped gate semantics, generates deployment-history records required by the pipeline-reliability-sla constraint, and unblocks PR-triggered deployments at the environment boundary.
Whether to replicate the classic six-lane parallel job topology as six independent inline YAML deployment jobs (lift-and-shift, exhausting the concurrency quota and duplicating gate logic) or restructure using a parameterized deployment job template invoked via a matrix or each-environment loop with Azure DevOps Environment protection rules hosting the Azure Monitor gate, satisfying the concurrency cap and centralizing gate logic in a single maintainable definition.
Domain Coverage
Difficulty Breakdown