Lift-and-Shift of a Stateful Java Order Monolith
A logistics division runs a Java EE order-management monolith on 12 application servers behind a hardware load balancer, with Oracle 12c on physical servers and Ehcache session state stored on each server's local disk. The application has 40 configuration files with hardcoded IP addresses and hostnames, and a nightly batch job that runs four hours and must finish before 06:00. Peak load is 800 requests per second with a 99.9% availability SLA. The migration team proposes a lift-and-shift rehost of all 12 servers to cloud IaaS, keeping the same topology, then 'fixing things later.' The target platform offers managed load balancing, autoscaling, and a managed Oracle-compatible database. Application owners say no code changes are possible before the migration because the release window is full. A pilot showed sticky sessions fail when a node is replaced during autoscaling.
1. Identify the migration blockers in the lift-and-shift proposal and state what must be proven before production cutover.
Read the worked answer
The lift-and-shift proposal is not a plan; it is a topology copy that will fail at the first scaling event. Blockers: session state on local Ehcache means any node replacement loses carts and forces re-login; 40 hardcoded IP and hostname files break when the load balancer or database endpoint changes; the four-hour batch window must still finish by 06:00 on cloud storage and network; Oracle-to-managed-database compatibility must be proven; and the pilot already showed sticky sessions fail during autoscaling. With no code release window, do not pretend to refactor. Rehost into a VPC that preserves the private IP scheme, keep the hardware load balancer equivalent with cookie-based persistence, disable autoscaling for the migration window, and drain nodes explicitly. Treat the batch as a separate migration unit with its own performance test. The decision is rehost now, replatform session management and configuration in the next release. Document the debt and a dated remediation plan.
2. Choose between rehost and replatform for the first cut, and explain how to handle hardcoded IPs and session state given the code freeze.
Read the worked answer
Choose rehost for the first cut because the application owners have no code window, but make it a controlled rehost. Preserve the 12-server topology and private IPs inside a VPC CIDR that does not overlap the data center. Replace hardcoded IPs at the infrastructure layer where possible: DNS aliases, load balancer VIPs, and database endpoints that resolve to the old addresses. Freeze autoscaling and use load balancer persistence; set connection draining and a maintenance page for node replacement. For session state, the least-risk option without code change is sticky sessions plus a shared file layer only if Ehcache is configured for disk persistence and the latency is acceptable; otherwise accept that node loss logs users out and cap availability expectations. Do not claim 99.9% until session externalization is delivered. Sequence: non-production pilot, batch test, performance test at 800 requests per second, then production.
3. Design the cutover approach for the nightly batch job and its rollback path separately from the online tier.
Read the worked answer
Run the batch as a first-class workload. Measure the current four-hour job by phase: extract, transform, load, reporting. On cloud, the risks are storage throughput, database latency, and network egress. Give the batch dedicated compute and storage, schedule it outside the interactive peak, and set an alarm at 05:00 if it is not 80% complete. Do not co-locate batch and online nodes if the batch saturates CPU. For cutover, run the batch in parallel against a copy of the data, reconcile outputs, then switch the scheduler. Keep the old scheduler available for one cycle. Define rollback: if the job misses 06:00 twice, revert the batch tier to the data center while leaving online traffic migrated. This separates batch risk from the interactive cutover and protects the SLA.