Migrating a Stateful Monolith with a Hard Cutover Window
A logistics company runs a Java monolith on 6 physical servers with an Oracle database (4 TB) and 40 TB of file shares holding scanned shipping documents. The app writes files to local disk paths and stores metadata in Oracle. The business allows a 6-hour outage for cutover, once. There is a 200 Mbps Direct Connect. The team wants to rehost first and modernize later, and has 9 months. A previous attempt to lift-and-shift the database with native export/import was abandoned after the export ran 30 hours.
1. Choose the migration approach for compute, database, and file shares, and justify each against the 6-hour window and 200 Mbps link.
Read the worked answer
Compute: rehost the 6 servers with AWS Application Migration Service - continuous block-level replication means the cutover is a short reboot into EC2, which fits the 6-hour window. Do not rebuild from scratch; rehost-first is the stated goal.
Database (4 TB Oracle): the export/import failure shows logical migration is too slow. Use AWS DMS with Oracle as source and a target (RDS for Oracle or Oracle on EC2, depending on licensing), with full load plus change data capture running continuously ahead of cutover. CDC keeps the target current, so at cutover you only stop writes, let replication drain, and repoint the app - minutes, not hours. Alternatively, if the target is Oracle on EC2, use Oracle Data Guard or native physical standby. The 200 Mbps link matters for the initial load: 4 TB at a realistic 150 Mbps is roughly 60+ hours, so start the DMS full load weeks early; CDC absorbs the delta.
File shares (40 TB): 40 TB at 200 Mbps is ~18+ days of pure transfer, so use AWS DataSync with an agent, which does parallel transfer, integrity checks, and incremental syncs. Run a full sync early, then repeated incremental syncs; the final delta before cutover should be small enough to finish inside the window. Do not use plain rsync over the link - it will not finish and gives no verification.
2. What is the cutover runbook, and how do you validate before declaring success?
Read the worked answer
Runbook: (1) T-14 days: DataSync full sync done, DMS CDC lag under a minute, MGN replication lag near zero, all three rehearsed once in a test cutover. (2) T-0: put the app in maintenance mode, stop writes. (3) Drain DMS CDC until lag is zero; run a final DataSync incremental; verify row counts and file checksums. (4) Repoint DNS (lower TTL a day earlier) to the AWS load balancer; start EC2 instances from MGN. (5) Smoke test: log in, place a test shipment, confirm the document lands in S3/EFS and metadata in the database. (6) Keep the source running read-only as rollback for 72 hours.
Validation: compare record counts per table and a sampled checksum of files between source and target; run the app's own integration test suite; confirm p95 response time against baseline; check that no code path still writes to a local path (grep the config and test the document-upload flow). Declare success only after a full business-day of production traffic with no data-integrity alerts. The single-outage constraint means the rehearsal is non-negotiable - the first real cutover must not be the first time the runbook runs.
3. Leadership asks whether to modernize the file handling during this migration instead of after. What is your recommendation?
Read the worked answer
Recommend deferring file-handling modernization but making one cheap structural change now: land the documents in S3 rather than EFS/local disk during the rehost, even if the app still uses file-path semantics via an S3-mounted or gateway layer. Rationale: the 6-hour window and 9-month timeline leave no room to refactor the app's file I/O and re-test it; a failed refactor risks the whole cutover. But choosing S3 as the storage target now avoids a second 40 TB migration later, and S3 gives durability and lifecycle tiering immediately. Keep the metadata in the database as-is; do not attempt to move document metadata to DynamoDB in this phase. Schedule the real modernization (presigned URLs, event-driven processing, metadata service) as a follow-on project with its own budget, once the rehosted system is stable and you have baseline metrics. The judgement call: rehost-first is only cheap if you don't smuggle a rewrite into it.