Application Modernization and Migration
Application Modernization and Migration
This domain covers portfolio assessment, the migration strategies (the R's), wave planning, modernization patterns, and the mechanics of cutover. Scenarios usually impose a deadline, a legacy dependency, and a zero-downtime constraint, then check whether your plan is incremental and reversible.
Assess before you move
- Inventory applications, owners, dependencies, and data flows. Dependency mapping catches the scheduled batch job or SFTP drop that everything silently depends on.
- Classify with the R's: rehost, replatform, refactor, repurchase, retain, retire. Retire is the cheapest migration available - find the applications nobody uses.
- Group into waves by dependency and risk, not by org chart. Each wave must be independently shippable and reversible.
Modernization patterns
- Strangler fig: put a routing facade in front of the monolith and migrate one capability at a time, keeping the facade until the last capability moves. It enables incremental rollout and one-switch rollback.
- Externalize state - sessions, file uploads, caches - before scaling horizontally, because containers and functions assume ephemeral compute.
- Decompose by business capability within a bounded context. A distributed monolith is worse than the monolith you started with.
- Data migration: dual-write or change data capture during transition, plus a reconciliation job comparing row counts and checksums daily.
Worked example
A legacy order monolith, forty eventual services, zero downtime, six months. Rehosting would hit the deadline but lock in the problem, so use strangler. First externalize sessions and uploads to managed services. Then place an API gateway with path-based routing in front and move order history first - read-only and low risk. Next run CDC from the monolith database into the new service store and reconcile daily for two weeks. Finally cut over writes behind a feature flag with one-click rollback. The result is incremental risk, measurable value at every step, and no big-bang weekend.
Traps that cost marks
- Refactoring everything at once, leaving no shippable intermediate state.
- Ignoring the integration layer: scheduled jobs, file drops, and mainframe calls are the classic cutover surprises.
- Migrating without a rollback plan or a data reconciliation metric.
- Assuming lift-and-shift is free - you inherit the operational debt and often invalidate the licensing model.