You have built something that works, and now you have to hand it to a team that did not write it and does not particularly want it. How do you run that handover?

Short answer

Treat reluctance as a rational response to inheriting on-call burden rather than as resistance to change: find out what it costs them, transfer ownership through work they do themselves while you are still there, and get the acceptance recorded by whoever committed their capacity.

Mention embedded delivery where it changes the risk, the owner, or the next check.

Reluctance is usually a correct calculation

The framing of this situation as resistance to change is almost always wrong, and candidates who reach for change-management language give away that they have not thought about the receiving team's position. Consider what is actually being offered to them. They are being given a codebase they did not design, in a shape they did not choose, solving a problem that was somebody else's priority, and the thing that transfers with it is a pager. Their existing commitments do not shrink to make room. Somebody senior agreed to this and quite possibly did not consult them.

So the diagnosis comes first, and it is a genuine investigation rather than a courtesy. Ask the engineers directly what worries them about owning this. The answers cluster: it uses something they do not know, it will page them for things they cannot fix, they have no slack in their roadmap, they do not believe the business will keep caring about it, or they proposed a different approach a year ago and were overruled. Each of those has a different remedy, and only one of them is solved by more documentation.

Reduce the cost of ownership before you argue about ownership

Once you know the objection, the strongest response is to change the thing rather than to reframe it. If the fear is being paged for failures they cannot resolve, the work is to remove the alerts that are not actionable and make the remaining ones carry a runbook line that says what to do. If the fear is an unfamiliar dependency, consider whether the last two weeks of the engagement are better spent removing it than adding features. If the fear is roadmap capacity, produce an honest estimate of the ongoing cost — hours per month for routine operation, and what a typical change request would take — because a number they can plan against is far less threatening than an open-ended obligation.

That estimate is also the most persuasive artefact you can put in front of their manager. "This needs roughly a day a month, and here is what that day consists of" is a negotiable claim. "The team will now own this system" is not a claim about anything, which is precisely why it produces silent non-acceptance.

Ownership transfers through their hands, not through your slides

A handover conducted as a series of walkthrough sessions transfers information and no ownership at all. What transfers ownership is the receiving team doing the work while you are still available to be asked, in roughly this order.

Weeks -6 to -4   They make a real change: one field, one report column,
                 in their own branch, reviewed by you rather than written by you.
Weeks -4 to -3   They run a deployment end to end. You sit behind them and
                 say nothing unless asked.
Weeks -3 to -2   Fault drill: you break something in a controlled window
                 during working hours. Their on-call finds and fixes it.
Weeks -2 to -1   They take primary support. You are reachable but do not
                 respond first. Every question they ask becomes a doc line.
Final week       Nothing new ships. You write down only what the previous
                 four weeks proved was missing.

The reversal in the middle is the important part. Most handover plans have the outgoing engineer doing the work with the new team observing, which is comfortable and teaches almost nothing. The version above has them doing it and you observing, which is uncomfortable, slower, and the only sequence that surfaces what they do not yet know while there is still time to fix it. Every question they ask during those weeks is a defect in the handover, and it is far cheaper to find it now than in the first incident after you have gone.

Get the acceptance from whoever spent their capacity

There is a political element you cannot solve at engineer level. Somebody agreed that this team would own this system, and there is a fair chance the engineers heard it as an announcement rather than a negotiation. Your handover cannot succeed if the receiving team's manager has not actually allocated capacity for it, no matter how good your drills were, because the first time it competes with their own roadmap it loses.

So the completion of a handover is a conversation with that manager in which three things are stated plainly: what the system does for the business, what owning it costs per month, and who on their team is the named owner. Ask for the name. A system owned by "the platform team" is owned by nobody, and the absence of a name is the single most reliable predictor that this will be abandoned within two quarters.

When you should refuse to complete the handover

The hardest version of this scenario is when the receiving team is not ready and the engagement is ending anyway. The pressure to declare completion is real: your own company wants the engagement closed cleanly, the customer sponsor wants to report a delivery, and the receiving team may even sign the acceptance to avoid a confrontation. Signing an unsafe handover is the worst available outcome for everyone, because the failure arrives three months later attached to your firm's name, with nobody left on site who understands the system.

What to do instead is to say so, in writing, to the sponsor, with specifics rather than sentiment: the team has not deployed this without help, the on-call rota does not include it, there is no named owner. Then offer the smaller options — a four-week reduced-hours extension, turning off the part of the system nobody is ready to operate, or a formal support arrangement with your firm. Any of those is recoverable. A clean-looking exit over a handover you know did not take is not, and the credibility you lose is your own rather than the customer's.

The failure that looks like success

Watch for the handover that goes beautifully and still fails. The team is polite, attends every session, asks good questions, signs the acceptance, and then the system quietly stops being maintained. The usual cause is that nobody on that team ever believed the business cared about this system, and they were right — it was one executive's initiative and the executive has moved on. Reading that early changes what you should build, not just how you hand it over, and it is a legitimate thing to raise with your sponsor mid-engagement rather than discovering it in the final fortnight.

A handover is complete when their engineer has fixed a real failure in this system without you, and their manager can name the person whose objective includes it. Anything short of that is a document exchange.

---

© 2026 Preptima. Originally published at preptima.com.