# Managed application takeover for a logistics provider: mean restore time down from 7.5 hours to 1.8 hours

> A European logistics provider engaged TechSupport Team to take over an undocumented shipment-tracking system in end-of-life PHP with MySQL after the original developers left. The takeover produced a risk list, runbooks written from zero and a staged runtime upgrade, with mean restore time down from 7.5 hours to 1.8 hours over 90 days.

- Publisher: TechSupport Team
- Canonical page: https://techsupport-team.com/case-studies/application-support-takeover/
- Updated: 2026-10-25

TechSupport Team took over an undocumented shipment-tracking system, end-of-life PHP with MySQL, for a European logistics provider after the original developers left. Two engineers and a part-time L3 (third-level) lead ran the managed takeover: risk list at assessment, runbooks written from zero, vendor cases for the closed component. Over 90 days, mean restore time fell from 7.5 hours to 1.8 hours, according to the client's incident records. The client kept risk acceptance and change approval.

## Engagement facts

Table: Facts of the takeover engagement

| Fact | Value |
| --- | --- |
| Industry | Logistics and freight |
| Client location | Europe, four countries, anonymized |
| Application type | Shipment-tracking application with file-based exports to the warehouse system |
| Stack | End-of-life PHP, MySQL, one closed commercial reporting component |
| Roles supplied | One senior L2/L3 engineer, one mid-level L2 (second-level) engineer, part-time L3 lead |
| Seniority | Senior and mid-level, with an L3 lead for the upgrade |
| Engineer count | 2 full-time plus a part-time L3 lead |
| Engagement duration | Ongoing managed support after a 6-week takeover |
| Coverage hours | Client business hours, eight hours a day, five days a week |
| Time zones | Two European time zones, aligned to the client's operations desk |
| Reporting line | TechSupport Team engagement lead; client IT manager owns approvals and risk acceptance |
| Model | Managed support takeover, then ongoing managed application support |

## Why the client needed engineers

The system tracked every shipment the client moved, but knowledge of it had left with the original developers. Incidents were survived rather than solved, through restarts, careful manual steps and the memory of one long-tenured employee. There was no current documentation, no tests, an unsupported database version and one closed component the license forbade touching.

The client chose a managed takeover over hiring because the skills needed, legacy PHP diagnosis plus disciplined documentation, were hard to recruit locally, and the risk needed a named owner fast. Rebuilding was a separate decision the client deferred; the immediate need was safe, documented support.

## Team composition and responsibilities

A senior L2/L3 engineer and a mid-level L2 engineer ran daily support, with a part-time L3 lead for the runtime upgrade. A TechSupport Team engagement lead directed the takeover work within the agreed scope. The client's IT manager approved runbooks, changes and risk acceptances, and the operations desk kept customer and depot communication. The client's one long-tenured employee remained the product knowledge source during shadowing, then returned to their own job.

## Selection and onboarding

1. **Assessment and risk list.** Two weeks of read-only assessment produced the written risk list that became the takeover contract: runtime, database, backups, single points of failure and the closed component.
2. **Access and knowledge transfer.** Access was granted per the risk list controls. Knowledge transfer ran as guided shadowing of the long-tenured employee, recorded into runbook drafts as it happened.
3. **Supervised work.** The first incidents were handled in pairs with the client's employee present. Each one ended in a runbook entry and a reviewed incident record.
4. **Independent work.** The client approved independent work at week 6, measured as a new engineer covering an incident class from intake to closure using only approved runbooks.

## Technical work performed

- Mapped the application, its exports and its cron jobs from code, logs and the long-tenured employee's knowledge.
- Tested backup restoration, found it failing, and fixed the restore path with the client before any incident demanded it.
- Wrote runbooks incident by incident: intake checks, log locations, safe commands, rollback steps and escalation points.
- Built a diagnosis package for the closed reporting component from its logs and configuration, and ran vendor cases with evidence.
- Planned and staged the end-of-life PHP runtime upgrade with regression checks after each stage.
- Reported recurring causes monthly with proposed preventive work.

## One representative incident

### Database disk failure in month 2, after the restore runbook existed

*Client incident. Sanitized timeline approved by the client.*

- **Intake:** Monitoring reported database write failures on the shipment-tracking system during the morning shift.
- **Investigation:** The on-shift engineer followed the restore runbook written in week 3: checked the error log, confirmed a disk fault and verified the latest backup against the rehearsal checklist.
- **Action:** Restoration ran on spare capacity while the failed disk was replaced. The client's IT manager approved the restore window and the communication to depots.
- **Approval:** The client approved the restore from the verified backup; the vendor case for the disk ran in parallel with the hardware supplier.
- **Restoration and permanent fix:** Service was restored inside the agreed window with no shipments lost. The root cause analysis (RCA) added a second restore rehearsal and a disk-space alert, both completed within two weeks.

Service was restored from the verified backup inside the agreed window, without the old employee being called. The incident closed with one RCA and two preventive actions: a second restore rehearsal and a disk alert.

## Measured results

Table: Takeover results over the first 90 days

| Metric | Baseline | Result | Window | Sample | Source |
| --- | --- | --- | --- | --- | --- |
| Time to independent work for a new engineer | Unknown, no materials | 6 weeks | Takeover | Engineers onboarded | Onboarding records |
| Incident classes with an approved runbook | None | 85 percent | First 90 days | All incident classes | Runbook register |
| Mean restore time | 7.5 hours | 1.8 hours | First 90 days | All incidents | Client incident records |
| Repeat incidents | 14 per month | 2 per month | Months 2 to 3 | Confirmed repeats | Client incident records |

## Evidence and limitations

The metrics come from the client's incident records and the runbook register kept during the takeover. Ticket counts are lower in month 1 because the takeover started mid-quarter; the repeat-incident comparison uses months 2 and 3 against the prior baseline quarter. The disk failure was one incident; its clean handling shows the runbook working, not a promise that every failure ends the same way. The client's IT manager reviewed this case study before publication; company and system details are anonymized with approval.

## Questions buyers ask

### Why take the system over instead of rebuilding it?

The client needed safe, documented coverage now and wanted modernization decisions separate from incident survival. The takeover keeps options open: the runbooks and risk list become the evidence base for any later rebuild.

### How did engineers support a system with partial source rights?

The assessment mapped what was readable. Readable code was diagnosed directly; the closed component was handled through its logs, its configuration and vendor cases with evidence attached.

### What happened to the one employee who knew the system?

They guided shadowing during the takeover and reviewed runbooks, then returned to their own role. Coverage no longer depends on their memory.

### Did the takeover include modernizing the system?

No. The scoped work was safe support, documentation and a staged runtime upgrade, then handed over to ongoing maintenance. Rebuild decisions stayed with the client.

### Could this run as dedicated engineers instead of a managed team?

Yes. The same takeover runs under dedicated engineers directed by the client; the difference is who directs daily work. See the comparison on the outsourcing page.

## Related pages

- [Application support](https://techsupport-team.com/services/application-support/): The support scope this system ran under.
- [Technical support outsourcing](https://techsupport-team.com/services/technical-support-outsourcing/): The managed model used for ongoing coverage.
- [How we work](https://techsupport-team.com/how-we-work/): The assessment and knowledge-transfer phases behind the takeover.
- [Hire support engineers](https://techsupport-team.com/hire/support-engineers/): The dedicated-engineer alternative for a takeover.
- [Software maintenance](https://techsupport-team.com/services/software-maintenance/): The maintenance service the staged runtime upgrade was handed over to.

## Contact

Request engineers from TechSupport Team or ask a question: https://techsupport-team.com/contact/