AMS transition and estate baseline
Illustrative use case, not a case study.
Taking over applications we did not build: inventory the estate, agree scope and severities, transfer knowledge, and baseline the service before operating it.
The problem
The applications work, but the people who understood them have moved on or the incumbent vendor is leaving. Documentation is partial, customizations are undocumented, and nobody can say which integrations are critical. Support cannot be improved until it is first understood.
How it works today
A new support team inherits a ticket queue and a shared drive. Knowledge transfer happens in a few calls with the outgoing team. Severity definitions, service hours, and escalation paths are assumed from the old contract. The first months are spent rediscovering the estate through incidents.
See the scenario
Illustrative workflow. Subtitled.
Transcript
- The applications work, but the people who understood them have gone. Documentation is partial, customizations are undocumented, and nobody can say which integrations are critical.
- We inventory the applications, agree support scope and hours, document procedures and gaps, then establish the starting service baseline.
- Nothing changes in production during discovery. The owner approves the definitions before service starts, and findings inform an improvement backlog the owner prioritizes.
- Measured on estate coverage and incidents from unknown components. Illustrative use case. Let us discuss yours.
Proposed workflow
- Inventory the estate: modules, integrations, customizations, agents, and the environments they run in, with evidence gathered from the systems rather than from memory
- Agree the scope, severity definitions, service hours, and vendor-escalation responsibilities in writing before any ticket is taken
- Transfer knowledge into runbooks and an approved knowledge base, with gaps listed instead of hidden
- Baseline the service: current incident volumes, resolution times, release cadence, and known risks
- Operate under the agreed definitions, record findings, and propose improvement items for the owner to prioritize
Where a person stays in control
- Scope, severities, hours, and escalation responsibilities are approved by the owner before service starts
- No change is made to production during discovery; findings are recorded, not fixed on the spot
- The improvement backlog is prioritized by the owner, not by the support team
Platform mappings indicate environments in which to assess this idea. Actual implementation depends on configuration, licenses, APIs, data, and permissions. Benefits are stated qualitatively; numeric claims require a documented baseline.