Knowledge transfer that doesn't stall your delivery
How we hand over your systems, code and processes
Handover is where subsidiary projects usually go wrong. Documentation turns out to be few years old, the one person who understands the payments module leaves, and delivery stalls for a quarter.
So we run the knowledge transfer as a project: phases, named owners, dates. Not as something that happens on its own while everyone is busy with their day job.
Here is how it normally goes.
How we run a handover
1. Find out what exists
Access and inventory
We start by finding out what exists. That sounds obvious until the deployment runbook turns out to describe a server that was switched off before anyone currently on the project arrived. We collect the repositories, the tickets, the access rights and the project history before anybody starts teaching anybody anything.
Documentation review
We read it all and write down what is missing, outdated or contradictory. That list usually starts the real conversation.
Architecture and code review
We go through the architecture and the code before the handover starts properly. The point is not to audit your developers. It is to find the places where the documentation and the system tell different stories.
2. Learn how the work is done
Shadowing and reverse shadowing
First we work alongside your team to learn the daily routine. Then we swap: we do the work and your people watch, correct and hand over more as confidence grows.
Workshops only where they help
Some things need a workshop. Most do not. A two hour presentation about the whole platform is usually worth less than sitting with the person who handles failed payments and watching three real incidents from start to finish.
3. Hand over and step back
The new team takes over
Tickets, releases and on call move across. Your people stay reachable and stop being asked. Supervision drops off as the team proves it can run things on its own. We take the same approach to the AI tools our teams use — we never leave them unsupervised either.
Then we stay reachable
After the handover we remain available for the hard problems until business as usual really means usual. That period has an end date agreed in advance, not an open commitment nobody tracks.
How we know the handover is done
Not when the workshops are finished, and not when somebody signs a document. A transfer is not finished when somebody has watched a demo. It is finished when the new team can do the job and the old team only has to watch.
In practice we treat it as done when the new team can:
- deploy without help
- diagnose a production problem without calling anyone
- explain the architecture to somebody new
- pick up a ticket without first asking where things live
- run the periodic jobs that only come round once a month or once a quarter
Until all five are true the handover is still in progress, whatever the plan says. The last one catches people out more than the others, because a quarterly reconciliation nobody has seen yet is invisible until the quarter ends.
Who decides what
Two standing meetings, and deliberately no more than that.
Weekly working meeting
Progress, blockers, access that has not been granted yet, and knowledge nobody has managed to explain so far.
Monthly steering meeting
Are we on schedule, is the new team getting more independent or just busier, and what needs a decision from someone senior.
We use your tools, not ours
A handover should not leave your team with another system to maintain. If the work lives in Jira, Confluence and GitHub, that is where we work. If it lives in Azure and Teams, we use that instead.
What matters is not the tool. It is that every system, every recurring process and every significant past decision has an owner, a current source of truth, and somebody on the new team who can explain it without ringing the old one.
If the documentation genuinely needs to move somewhere else we will say so. We will not make it a condition of the project.
When a handover happens
Four situations account for almost all of the ones we run.
An outsourcing contract is ending. The outgoing vendor has no incentive to hurry and the knowledge is in their heads. This is the case where starting early matters most.
The work is moving to your own team in Poland. Often alongside setting up the company, which we cover separately in our guide to setting up an IT subsidiary in Poland.
Somebody critical is leaving. The worst version is when nobody realises how much only that person knew until the notice period has already started.
A system arrived through an acquisition. Nobody in the buying company chose it, documented it or wants to own it.
Frequently asked questions
How long does a knowledge transfer take?
For one system with a cooperative outgoing team, six to twelve weeks is typical. The variable is rarely the technology. It is how much of the knowledge exists only in somebody’s head, and how available that person is.
What do you need from our side?
Access, and time from the people who currently do the work. Access is usually what slips: a handover can sit still for a fortnight waiting for one repository permission.
What if the documentation is bad or does not exist?
That is the normal case. We write down what is missing as we go, which is part of why the first stage is a review rather than a reading exercise.
Do the outgoing developers have to stay until the end?
Not all of them, and not for the whole period. What matters is that the people holding the parts nobody has written down are available during the shadowing weeks rather than in their final fortnight.
What is reverse shadowing?
The second half of the swap. First the new team watches the old team work. Then the new team does the work while the old team watches and corrects. The second half is where most of the real learning happens.
Can a handover be done remotely?
Yes, and we’ve done it before. Being in the same room for the first week or two shortens it noticeably, particularly when the system is large or the documentation is thin. That is also why we usually suggest a hybrid setup for a new team rather than fully remote from day one.
If a handover is coming, plan it early!
The cheapest time to plan a handover is before the people who understand the system start leaving. Tell us what is being handed over and we will tell you how we would run it.