I’ve never seen a supplier handover fail because nobody remembered to share the release calendar. The trouble is everything around it: why a date moved, which defect is genuinely risky, who can approve an exception, and which “temporary” workaround has quietly been keeping things stable for the past year.
Most of that knowledge exists somewhere. Some of it is in Jira. Some is in old meeting notes. Quite a lot of it is in the heads of people who are already moving to another project.
That is the part of a handover I would worry about.
The documents are not the handover
There will usually be a list of documents to transfer. Test plans. Release schedules. Support procedures. Risk logs. Architecture diagrams. Maybe a few recordings from handover sessions.
The list may be complete. That doesn’t mean the information is useful.
A test plan can tell you which types of testing should happen. It may not tell you that one environment is regularly unavailable on Tuesday mornings, that a particular integration produces unreliable test data, or that one regression pack hasn’t been maintained properly since a team restructure.
A release schedule can tell you when a release is planned. It won’t necessarily explain why that date matters, which other teams are working around it, or what happens if it slips by three days.
The same is true of defects. An open defect is not just an ID, a severity and an owner. There may have been weeks of discussion behind the current status. Perhaps the technical impact is small but the affected client is important. Perhaps the defect is marked as low priority because there’s a workaround, but the workaround depends on someone performing a manual check every morning. Perhaps it was accepted for one release, under specific conditions, and those conditions no longer apply.
When the context disappears, the ticket remains. It still looks official. That’s what makes it dangerous.
I don’t think the answer is more documentation. At least, not by default. Asking an outgoing team to document everything usually creates more pages for the incoming team to read and very little clarity about what deserves attention.
What the new team actually needs is a way to separate routine information from the decisions, exceptions and awkward dependencies that have been holding the delivery together.
That takes conversation. It also takes time, which is often the first thing cut from a handover plan.
The release work doesn’t stop politely
Supplier changes tend to be planned as if one team will finish, pass over a stable service, and then leave. Meanwhile, the new team will arrive, read the documents and take control.
Actual delivery rarely pauses long enough for that.
Releases are still moving. Testing is still happening. Defects are being fixed, reopened and argued about. Someone is waiting for evidence. Someone else needs an approval by the end of the day because a change window is approaching.
On a large programme, there may also be several suppliers handing work to each other, not one clean exchange between an outgoing team and an incoming one. A delay in one area changes the test window somewhere else. An environment problem is treated as a QA delay. A missing interface specification appears as an integration defect. By the time the issue reaches a release meeting, three teams have a different version of what happened.
I’ve worked in programmes where acceptance testing involved internal teams, external suppliers and large groups of business testers working in different locations. In that kind of setup, status reporting has to be more than a percentage and a traffic-light colour.
“Testing is 90% complete” tells me very little.
Which 10% is left? Is it a low-risk browser check, or the end-to-end journey that proves the service can actually be used? Are the blocked tests waiting for a fix, an environment or a decision? Has the supplier provided enough evidence for acceptance? Who has reviewed it? What remains open, and who has explicitly accepted that risk?
Those questions already matter during normal delivery. During a handover, they matter more because the people answering them may not share the same assumptions.
This is usually where the trouble starts. The outgoing team reports against the way it has always worked. The incoming team reads the same status through a different process. Both may be acting reasonably, but the release still ends up with a gap nobody owns.
Release readiness can’t be transferred as a finished document. It has to be rebuilt around the current release, with the new owners in the room.
Someone still has to decide
Handover plans often concentrate on tasks: access requested, documents shared, meetings completed, tools demonstrated.
Fine. But who decides?
Who can accept a known defect? Who can move a date? Who says the test evidence is sufficient? Who decides that an environment problem has invalidated a result? Who calls a no-go when the delivery pressure is pointing the other way?
If the answer is “the same people as before”, the handover hasn’t happened yet.
I’m particularly wary of approval routes that survive only because everybody knows whom to message informally. They work until one of those people leaves, changes role or simply isn’t available during a release window. Then a decision that used to take twenty minutes sits unresolved for two days because nobody is sure who has the authority to make it.
This can look like a small administrative problem. It isn’t. A release manager can chase an approval, but she can’t invent the authority behind it. QA can explain the residual risk, but QA shouldn’t quietly accept that risk on behalf of the business.
The rules don’t need to be complicated. They do need to be explicit enough that the new team can use them without relying on the outgoing team’s personal contacts.
The same applies to escalation. A contact list is useful, but it’s not an escalation route. The new team needs to know when an issue should move beyond the delivery team, what information the decision-maker expects, and how quickly an answer is realistically available.
Otherwise, every difficult issue becomes a fresh discussion about process while the release date gets closer.
I’d start with the uncomfortable parts
If I were taking over release or QA responsibility, I wouldn’t begin with a tour of every dashboard. I’d want to know what the dashboards don’t show.
Which part of the release regularly causes trouble?
Which test results do people trust least?
What gets approved late?
Which defects have been carried for several releases?
Where do teams disagree about ownership?
What must happen manually because the expected automation or integration never quite worked?
And I’d ask the outgoing team what they would check first if they were staying for the next release. That answer is often more useful than the formal priority list.
I’d also look at the recent history, not only the current plan. The last few releases usually show where dates slip, when defects are discovered and which dependencies are more fragile than they appear. A release calendar without that history is just a set of optimistic dates.
The same goes for test evidence. I don’t only want the final Test Summary Report. I want to understand how the team reached its conclusion. Which results were challenged? Which tests were repeated? What remained blocked? Was the final sign-off based on completed evidence, or on confidence that the remaining work would be finished later?
There’s no scandal in finding exceptions. Every large delivery has them. The problem is inheriting exceptions that still look like standard process because nobody has explained the difference.
A useful handover should make those exceptions visible while the people who understand them are still available to answer questions.
That may mean walking through a real release together rather than arranging another presentation. Let the incoming team prepare the readiness view. Let them run the defect meeting. Let them challenge the evidence and trace an issue across teams. The outgoing team can then see what has been misunderstood before that misunderstanding reaches production.
It’s slower than sending a folder of documents.
It’s also much cheaper than discovering, during the first release under new ownership, that the green status depended on three people who are no longer there.