Handover and team training
The point at which your own team takes over. Done properly this is a deliberate engagement with a defined finish, not an email with some credentials attached and a wish of good luck.
Handover as a formality
Access is transferred, a folder of documents appears, and the outgoing team leaves. Three weeks later the new team hits their first real problem and discovers the documentation covers the parts that were easy to write, the deployment has undocumented manual steps, and nobody knows why a particular service exists. The handover technically happened and the knowledge did not transfer.
You’ll recognise this if
- You are bringing development in-house and need it to actually work
- A vendor relationship is ending and you need a clean exit
- Your team has inherited software they do not yet understand
- One person holds all the operational knowledge and is leaving
What we actually deliver
Complete transfer of access and ownership
Repositories, cloud accounts, domains, certificates, third-party services, and licences — enumerated, transferred, and verified against a checklist rather than remembered.
Documentation written for the next person
Architecture, deployment, operational runbooks, and — most valuable and most often missing — the record of why things were decided the way they were.
Working sessions with your team
Time spent in the code together, not a slide deck. Your developers make real changes and deploy them while we are still there to answer the questions that only arise in the doing.
A supervised period
Your team runs it while we remain available to consult. The problems that matter surface in the first weeks of real ownership, and that is exactly when help should still be reachable.
The way we approach it
Verify by having them do it
Handover is complete when your team has deployed a change, restored from a backup, and resolved an incident themselves. Documentation reviewed and nodded at proves nothing.
Find the undocumented steps
Every system has manual steps that live in someone's habits rather than in writing. We look for them deliberately, because they are precisely what breaks first after a handover.
Taper rather than stop
Full availability, then reduced consultation, then done — with an explicit end date. A clean, planned exit rather than a relationship that fades ambiguously.
What changes
- Every account and asset transferred and verified
- Documentation that answers the questions people actually have
- A team that has deployed, recovered, and debugged it themselves
- A defined end date rather than an open-ended dependency
Asked often enough to answer here
How long does a handover take?
Typically two to six weeks depending on the size of the system and your team's familiarity with the stack. Most of that is working sessions and supervised operation rather than document writing.
What if our team isn't ready yet?
We will say so, with specifics about which gaps matter. Often the answer is a longer supervised period or targeted training in one area rather than abandoning the plan.
Can you hand over to another agency?
Yes, and we treat it the same way as handing over to an internal team. Making an exit difficult would be a poor way to run a business that depends on being recommended.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.