Lift And Shift Default — Azure DevOps Engineer (AZ-400)
You defaulted to migrating as-is when the scenario called for modernization or re-architecture.
Rehosting Preserves the Problem, Not Just the Architecture
The scenario says the team wants to reduce operational overhead after migration. The candidate selects IaaS VMs because the application has third-party dependencies that appear incompatible with PaaS. The exam, however, expects you to recognize that managed services—App Service, Azure SQL—address the stated constraint directly. Rehosting moves the workload; it does not remove the OS patching, scaling management, and infrastructure monitoring the team is trying to escape.
The Scenario
A team is migrating their on-premises Jenkins-based CI/CD pipeline to Azure. You recommend Azure VMs with the same Jenkins configuration, plugins, and manual deployment scripts. The scenario says "improve deployment velocity, reduce pipeline maintenance, and enable self-service releases." The correct answer is Azure Pipelines with YAML pipeline definitions, Azure Artifacts for package management, and deployment slots on App Service for zero-downtime releases. Moving Jenkins to a VM preserves plugin maintenance, security patching, credential management, and manual pipeline configuration. Azure Pipelines eliminates all of that — Microsoft manages the build agents, and YAML pipelines are version-controlled alongside the code. The exam tests whether you recognize that the migration goal is modernization, not relocation.
How to Spot It
- •Azure migration strategy follows the same spectrum as AWS. Rehost (VMs) preserves operational burden. Replatform (App Service, Azure SQL) reduces it. Refactor (Azure Functions, Container Apps) eliminates it. Match the migration target to the stated goal, not the source architecture.
- •Azure Migrate assesses and replicates on-premises workloads to Azure VMs, but the result is still VMs you manage. If the scenario says "reduce management effort," Azure Migrate is the migration tool but not the target architecture — the target should be a PaaS service.
- •DevOps-specific migration: Jenkins on VMs is a lift-and-shift trap. Azure Pipelines or GitHub Actions with Azure-native integrations provide managed build agents, secret management via Key Vault, and native deployment to App Service, AKS, and Functions without maintaining build infrastructure.
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 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
Related Patterns