Moving what already runs.
WHAT TO ASSESS FIRST
Whether it can run as several instances What it writes to local disk What configuration is hard-coded What it assumes about its environment
WHAT USUALLY NEEDS CHANGING
Configuration moved to the environment Sessions moved out of memory Uploads moved to shared storage Logging moved to output Scheduled tasks separated
WHAT TO DO FIRST
Containerise it as it is, running one instance.
WHY
It proves packaging works before changing behaviour.
WHAT TO TACKLE NEXT
Whatever prevents running two instances.
HOW TO FIND THAT
Run two, and see what breaks.
WHAT COMMONLY BREAKS
Sessions Files written locally and read later Scheduled work running twice Locks held in memory
WHAT TO DO ABOUT EACH
External session storage Object storage A single scheduled job, separate from the application A shared lock
WHAT NOT TO DO
Rewrite the application as part of the migration.
WHY
Two changes at once makes failures unattributable.
WHAT TO KEEP AVAILABLE
The previous deployment method, until the new one is proven.
WHAT TO MIGRATE LAST
The database.
WHY
It is the piece with least to gain and most to lose.
