Migrating a Monolith with a Hard Cutover Deadline
A retailer runs a 12-year-old Java monolith on physical servers in a colocation facility. The lease expires in 9 months and will not be renewed. The monolith has a 2 TB relational database, 40 TB of product images, and integrations with 6 third-party services. Downtime tolerance is tight: the business can accept at most a 4-hour maintenance window, and only on a Sunday night. The team has never run in the cloud and has two engineers who can dedicate part of their time. A previous attempt to "refactor to microservices first" stalled for a year with nothing shipped. Leadership now wants the fastest safe path to the cloud.
1. What migration strategy should leadership choose, and why is the earlier refactor-first approach a trap here?
Read the worked answer
Choose rehost (lift-and-shift) with minimal change, possibly with light re-platforming of the database, targeting the 9-month deadline. Reasons:
- The hard external constraint is the lease expiry, not an architectural aspiration. The binding requirement is "be out in 9 months with ≤4h downtime." A refactor-first plan has already proven it cannot ship under pressure - a year produced nothing. Repeating it risks missing the deadline entirely.
- Rehosting preserves the monolith's behavior, so the migration risk is operational, not functional. That is a far smaller surface to validate in 9 months with two part-time engineers.
- The 40 TB of images should move to object storage (a low-risk, high-value re-platform) while the app itself lifts and shifts. This removes bulk data from the server move.
- Microservices can be decomposed later, in the cloud, once the lease pressure is gone and the team has operational footing.
The judgement: sequence risk. When an immovable deadline dominates, optimize for a safe, reversible move first and refactor second.
2. How should the database cutover be executed to fit a 4-hour Sunday window?
Read the worked answer
Use a staged replication + short final-sync cutover, not a dump-and-restore on the night:
- Pre-stage: provision the target database and continuously replicate from on-prem (log shipping or native replication) for days/weeks ahead. The 2 TB bulk copy happens before the maintenance window.
- Validate continuously: run read-only checks comparing source and target; rehearse the cutover at least twice on a staging copy.
- Freeze writes at the start of the window, let replication catch up (should be minutes if lag is small), then flip the application's connection string to the target.
- Smoke test critical paths (login, checkout, order history) within the window.
- Keep the source read-only and intact for a rollback period; do not decommission until the business confirms stability.
The 4-hour window is only feasible because the heavy data movement is done in advance. The judgement: the maintenance window covers the cutover, not the copy.
3. What should the team do about the 6 third-party integrations and the two part-time engineers before cutover?
Read the worked answer
Treat both as schedule risks to be de-risked early, not discovered at cutover:
- Third-party integrations: inventory each one. The likely failure mode is IP allowlisting and egress changes - partners may only accept traffic from the colo's IPs. Collect the new cloud egress IPs (or a stable NAT gateway) and get partners to update allowlists weeks before cutover. Also check for latency-sensitive or VPN-based integrations that assume on-prem connectivity.
- Capacity of two part-time engineers: the plan must be narrow and rehearsed. Avoid parallel workstreams (no microservices, no re-architecture). Assign one owner for the data move and one for the application/integration cutover, with a written runbook and a rehearsed dry run. Use managed migration tooling to reduce hands-on effort.
- Build a rollback plan that the part-time team can actually execute under pressure - if it requires skills they don't have, it isn't a real rollback.
The judgement: integrations and people are the usual cause of a missed cutover, not the servers. De-risk them on a calendar, well before the Sunday window.