Migrating a stateful monolith to PaaS

WHAT THIS TESTS This evaluates whether you can drive a strategic, principled migration rather than a naive lift-and-shift, using Twelve-Factor as the framework for making the app cloud-native.

A GOOD ANSWER COVERS Start by auditing where the monolith holds state, since statefulness on local disk is the core blocker on a horizontally scaled PaaS. Apply Twelve-Factor systematically. Treat backing services as attached resources: move uploaded files to object storage, session state to a shared store like Redis or the database, and queued work to a message broker. Make processes stateless and disposable so any instance can handle any request and the platform can start and kill instances freely, which enables horizontal scaling behind a load balancer instead of one big vertical box. Externalize configuration into environment variables so the same artifact runs across environments. Send logs to stdout as an event stream for the platform to aggregate, rather than writing log files locally. Run admin tasks like migrations as one-off processes. Strategically, do this incrementally: containerize first, peel off the riskiest stateful pieces to backing services, and only then consider decomposing the monolith into services if warranted, rather than rewriting everything at once.

COMMON WRONG ANSWERS Lift-and-shift the monolith unchanged onto PaaS and keep writing to local disk, which breaks on restart and scaling. Using sticky sessions as a permanent crutch. Trying a full microservices rewrite in one step. Keeping config and secrets in code.

LIKELY FOLLOW-UPS How do you migrate sessions without logging everyone out? Which Twelve-Factor factor maps to each change? When is the strangler-fig pattern appropriate? How do you handle the database during migration? When should the monolith stay a monolith?

ONE CONCRETE EXAMPLE A legacy Java app stores uploads in /var/data, sessions on disk, and logs to a file. The plan: containerize it, repoint uploads to S3, move sessions to Redis, stream logs to stdout, read all config from environment variables, and run schema migrations as a release-phase one-off process. Now any instance is interchangeable, the platform scales it horizontally and restarts it safely, and only later does the team carve a billing service out of the monolith using the strangler-fig pattern.