The contract is signed and a new team is now responsible for keeping a system running that they did not build. Everything that determines whether this works happens in the first three months, and most of it has nothing to do with the technology. Transitions fail because knowledge stayed with people who left, because access was never fully granted, or because nobody agreed what good looks like until the first incident made it urgent. This is the foundation of any managed services engagement.
01Knowledge transfer is not a documentation exercise
The standard transition plan allocates a few weeks for the incumbent team to document the system and hand over. What arrives is an architecture diagram, some runbooks and a list of credentials, all of which describe the system as designed rather than as it behaves.
The operational knowledge that matters is different: which alert is always noise, which batch job has to finish before another starts, which customer calls directly when something breaks, and which component nobody restarts on a Friday. None of that is in a document and most of it is never volunteered, because the people who know it no longer notice that they know it.
02Access takes longer than anyone plans for
Every transition underestimates access. Production systems, monitoring, cloud accounts, source control, CI pipelines, databases, third-party vendor portals, the domain registrar, the certificate authority, the payment provider dashboard. Each has its own owner and approval path, and several will be held by someone who has left.
Start the access inventory on day one and track it as a work item with named owners and dates. An incident during transition where the incoming team can see the alert but cannot reach the system is a predictable and entirely avoidable failure, and it damages confidence at exactly the wrong moment.
- Enumerate every system, including vendor portals and registrar accounts.
- Name the current owner and the approver for each, then track to completion.
- Verify access by actually using it, not by confirming the account exists.
- Identify credentials held personally by individuals and move them to a managed store.
- Check that on-call alerting reaches the new team before the old team stands down.
03Agree what good looks like before you own it
Service levels written into a contract are often generic, and the specifics that cause disputes are absent: what counts as a priority one, whether the clock runs overnight, what happens when the cause is a third party, and who decides severity when the customer and the provider disagree.
Resolve these during transition while the relationship is cooperative. The same conversation held during a live outage, with a customer under pressure, produces a much worse answer and a worse relationship. Write the severity definitions with concrete examples from this system rather than abstract descriptions.
| Question | Why it causes disputes later |
|---|---|
| What is a priority one, in examples? | Severity is argued during the incident otherwise |
| When does the response clock start? | Detection time versus report time differ |
| Does the clock run overnight and at weekends? | Cover assumptions rarely match |
| Who owns third-party failures? | Most outages involve someone else's system |
| What is explicitly out of scope? | Scope creep begins in week three |
04Run in parallel before taking sole responsibility
A hard cutover, where the incumbent stops on a Friday and the new team starts on a Monday, concentrates all the risk at one point with no fallback. A parallel period where both teams receive alerts and the incoming team leads while the outgoing team observes is far safer and costs a few weeks of overlap.
Use that period deliberately. The incoming team should handle real incidents with support available rather than watching, because the knowledge gaps only reveal themselves when someone has to act. Ending parallel running early because everything seems calm is a common and regrettable economy.
05Expect the first month to surface neglected work
A system arriving into managed services almost always brings deferred maintenance with it: expiring certificates, unpatched dependencies, backups that have never been restore-tested, monitoring gaps, and alerts that have been muted so long nobody remembers why.
Budget explicitly for a stabilisation period rather than treating these as surprises that consume the support capacity the client is paying for. Finding them is a normal outcome of the first month, and presenting them as a prioritised remediation plan is far better than absorbing them silently and appearing slow.
- Audit certificate expiry across every domain and internal service in week one.
- Test a restore from backup rather than confirming backups exist.
- Review every muted or ignored alert and either fix it or delete it.
- Check that dependency and operating system patching has a process, not just a history.
- Produce a remediation backlog with severity, and get the client to prioritise it.
06Report from the start, including when it is uncomfortable
Reporting established in month one sets the relationship. It should cover what happened, what was learned and what is being changed, rather than a count of tickets closed which tells the client nothing about whether their system is improving.
Reporting an SLA miss before the client notices is the single most effective trust-building action available in a support relationship. The alternative, discovering later that the provider was quietly reclassifying incidents to protect a metric, is the fastest way to lose a contract that was otherwise going well.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.