Taking over an abandoned platform and stabilising it

The situation

What was going wrong

• 01

  The original developer had ceased trading, leaving no documentation or handover.

• 02

  Dependencies were years out of date, including packages with known vulnerabilities.

• 03

  There was no staging environment; changes had been made directly in production.

• 04

  Nobody knew whether the backups were valid, and no restore had ever been attempted.

Our approach

What we did, and why

1. 01

   Established control before changing anything

   First priority was securing account ownership, taking a verified backup, and standing up a staging environment so the production system was no longer the only place to test.

2. 02

   Triaged by risk, not by ease

   We audited the codebase and dependencies, then sequenced remediation by exploitability and business impact rather than starting with the quickest wins.

3. 03

   Documented as we learned

   Architecture notes, runbooks, and deployment steps were written while reverse-engineering the system, so the knowledge is now the client's asset rather than ours.

4. 04

   Moved to a supported footing

   The platform moved onto an SLA-backed retainer with monitoring, patching, a transparent ticket queue, and monthly reporting on what changed and why.

The outcome

What changed

All critical and high-severity vulnerabilities were cleared within the six-week remediation window, and dependencies are now on a maintained upgrade path. Deployments go through staging with rollback. Recovery has been tested rather than assumed, and the client has documentation that survives any single supplier.

0

Critical vulnerabilities outstanding

99.9%

Monitored uptime under SLA

4 hrs

Priority-one response target