Migrating a stateful monolith to the cloud

WHAT THIS TESTS The interviewer wants to see structured thinking under uncertainty: can you de-risk a migration rather than chase an ideal end state immediately.

A GOOD ANSWER COVERS Start with assessment. Inventory the application, its dependencies, data volumes, performance baselines, and compliance constraints. Then choose a migration strategy from the common patterns: rehost or lift-and-shift moves it as-is to cloud VMs; replatform makes small optimizations such as a managed database; refactor restructures the code. For a tight timeline, rehosting first and modernizing later is usually the safer path. The hardest part of a stateful monolith is the data: you must replicate it, keep it consistent during transition, and plan the cutover.

COMMON WRONG ANSWERS Proposing an immediate rewrite into microservices, which multiplies risk and delays value. Ignoring the data tier. Forgetting a rollback plan. Underestimating network latency between on-prem and cloud during a hybrid phase.

LIKELY FOLLOW-UPS How do you migrate a large database with minimal downtime. What is your rollback plan if cutover fails. How do you handle licensing and compliance in the new environment.

ONE CONCRETE EXAMPLE For a monolith backed by a large relational database, you might set up ongoing replication from the on-prem database to a managed cloud database, letting it catch up while the source stays live. You rehost the application onto cloud compute, run it against the replicated data in a staging configuration, and validate functionality and performance. For cutover you schedule a maintenance window, stop writes on-prem, let replication drain the final delta, repoint the application to the cloud database, and verify before reopening traffic. The key risks to mitigate are data loss during the final sync, mitigated by verifying replication lag is zero before cutover; extended downtime, mitigated by rehearsing the cutover and keeping the window tight; performance regression, mitigated by baseline comparison; and an inability to recover, mitigated by keeping the on-prem environment intact as a rollback target until the cloud version is proven stable.