Application and Workload Migration
Domain scope
This domain tests execution choices for applications and workloads: suitability, rehost versus replatform versus refactor, state handling, testing, and licensing. The exam focuses on whether a workload can run acceptably in the target platform, not whether it can be copied.
Core rules
- Rehost when speed and compatibility dominate and the operating model will not change. Replatform when a managed service removes undifferentiated operations with limited change. Refactor only with a funded product outcome.
- Identify state: local session state, local disk, scheduled tasks, hard-coded IPs, hostnames, registry dependencies, and OS-level agents. Statelessness is a design goal, not an assumption.
- Test functional equivalence, performance, integration, security, and operability. Include peak load, batch windows, and failure modes.
- Check licensing and support: per-core, per-socket, bring-your-own-license, and OS support constraints can change the business case.
- Use containers or autoscaling only after validating startup time, health checks, persistent storage, and network identity.
Worked example
A Java monolith stores sessions on local disk and writes invoices to a mounted file share. A lift-and-shift to virtual machines would work but keeps patch burden and single-instance risk. The team chooses replatform: sessions move to a managed cache, invoices to object storage, and the database to a managed service. Code changes are limited to session and file APIs. Because the invoice workflow must be exactly-once, the team adds idempotency keys and reconciliation before cutover. A full refactor is deferred until the product roadmap justifies it.
Traps
Calling every virtual machine move cloud-native; ignoring session or file-share state; leaving hard-coded IPs and hostnames; testing only happy-path function; and discovering license restrictions after design approval.