Several business-critical legacy applications had to return to service in a new environment after an incident, without recreating the previous risk profile.
Situation #
The recovery had to separate code and operational data from backups, uploads and old configuration, while keeping the system usable enough to restore continuity.
My responsibility #
I helped structure the recovery sequence, containment boundaries, selective restoration, minimum permissions and the distinction between immediate continuity and structural modernization.
Key decisions #
- Build a clean and more controlled environment.
- Contain legacy dependencies rather than silently upgrading them during recovery.
- Restore code and uploads selectively.
- Prevent execution in upload paths and exclude unsafe backup artifacts.
- Identify real runtime paths, minimum permissions and heavy request-time processes.
- End recovery with a staged modernization roadmap.
Defensible outcome #
Operation was restored under tighter controls and the remaining architectural, security and operability debt was made explicit as a separate modernization path.
Limits #
Recovery did not mean the platform was fully modernized. No claim is made that all legacy dependencies, manual releases or observability gaps were eliminated in the recovery phase.