The handover checklist we sign before a system is called done

Handover is where most digital-transformation projects quietly fail. The system works on the day of the ceremony. The vendor leaves. Eighteen months later a regulation changes, a report needs a new column, and nobody in the department can deploy the change. The system is not broken. It is simply frozen, and the only route to unfreezing it is another procurement round with the original vendor holding all the leverage.

We finished the digital transformation of the Land and Tax Department in Palestine in 2026, and handover was planned from the first month rather than the last. That is the main thing we would tell any department: handover is a deliverable with its own acceptance criteria, its own budget line and its own dates. Treated as a milestone at the end, it becomes a folder of PDFs that nobody opens.

The failure mode, in detail

The pattern is consistent enough to describe precisely. The department receives documentation, and the documentation is accurate on the day it was written. Then the vendor applies three fixes in the first support quarter, and none of them reach the document. A key person on the department side moves to another role. The build machine that produced the last release was configured by hand, and the person who configured it is the one who left. Nobody notices any of this, because the system keeps running.

The discovery moment is almost always external. A new tax rule, a court decision, an integration partner changing their API, or a security advisory that requires a library upgrade. Now the department needs a build, and finds that it can produce a running system only by asking the vendor. At that point the negotiating position is gone, and the cost of the next change is whatever the vendor says it is. This is not usually malice. It is the accumulated result of nobody testing the handover while testing was still cheap.

The checklist, and how each item is proved

Source code in a repository the department owns, on infrastructure the department controls, with full history. Not a zip file, not a copy pushed at the end. The test is that a department administrator can revoke every vendor account and the repository still works.

Every environment reproducible from that repository. Infrastructure described as code, with a documented path from a blank server to a running system. The test is the one that matters most and is skipped most often: department staff build a fresh environment from scratch, at their own keyboards, while our engineers sit in the room and answer nothing unless asked. If it takes three attempts, that is fine, and the three attempts are exactly the documentation gaps you needed to find.

A runbook for the ten most likely incidents. Not every incident, the ten most likely ones, written as sequences a tired person can follow at night. Database will not start. Disk full. Queue backed up. Certificate expired. Integration partner returning errors. Report totals disagree with the ledger. Login failing for one office. Backup job silent for three days. Each entry names the symptom, the first check, the fix, and who to escalate to. The test is a drill: we break something in a staging environment without warning and department staff work the runbook.

A data dictionary for every table a report depends on. Column, meaning, source of truth, and the rule for nulls. This one matters more in a tax and land context than anywhere else, because the disputes that reach a court are about what a field meant, not about whether the software ran.

Named administrators, with every credential rotated at handover. The rotation is the point. If the vendor's keys still work after the closing meeting, nothing was handed over. The department should rotate them itself and confirm that our access has stopped.

A training record per operator role, with a refresher already scheduled in the calendar rather than promised. Roles, not individuals, because individuals move.

A support agreement that says plainly what we still do, for how long, how to reach us, and what we do not do. The clarity about what is out of scope prevents the slow drift where the department stops building internal capability because the vendor is still answering the phone.

A scenario most departments will recognise

A new levy is announced with a six-week implementation window. It needs one new field on a form, one change to a calculation, one new column in a monthly report, and a migration for existing records. In a department that owns its handover, this is a week of work by two internal developers, run through the department's own test environment and deployed from the department's own pipeline. The vendor is told about it, not asked to do it.

In a department that accepted a documentation-only handover, the same change starts with finding a contract vehicle, then a scoping call, then a quote, then a purchase order, then scheduling against the vendor's other commitments. The engineering is still a week. The elapsed time is three months, the six-week window is missed, and the department explains the delay to people who do not care whose fault it was. The difference was decided two years earlier, in a meeting about acceptance criteria that felt procedural at the time.

When a strict handover is the wrong demand

There is a real counter-argument and we would rather state it than pretend it does not exist. Full operational handover assumes the department can and will staff the operation. If there is no internal team, and no realistic budget to hire one, insisting on full self-sufficiency produces a worse outcome than a managed arrangement. You get a department that owns a system it cannot patch, which is more dangerous than a department that knowingly buys an operated service with a clear exit path.

The honest version in that situation is a split. Hand over ownership of the code, the data, the schema and the deployment description in full, so that the department can move to another supplier or bring the work in-house later. Contract the running of it separately and openly, with a defined notice period and a tested extraction procedure. Ownership and operation are different questions, and conflating them is how departments end up with neither.

The other case is a genuinely short-lived system. A campaign portal that will be retired in a year does not need a five-year maintainability posture, and imposing one spends the department's attention where it will not pay back. Be explicit that it is short-lived, and put the retirement date in the contract, because temporary systems that survive are the ones that cause trouble.

What it costs

For the department, the checklist costs staff time at the worst moment, when the project feels finished and everyone wants to move on. The environment rebuild is a day. The incident drill is half a day. The training is several days spread across roles. It is also political effort, because somebody has to hold the line on acceptance when there is pressure to declare a launch.

For us it costs future revenue. A department that can deploy its own changes will buy fewer change requests. We decided some time ago that this is the correct trade, partly because it is the right way to build for the public sector, and partly for a practical reason: in tender after tender, evaluation committees now ask directly about vendor lock-in, and a specific, testable handover checklist is a stronger answer than any assurance about partnership.

It also costs us during the build. Writing infrastructure as code from the start is slower than configuring a server by hand, and insisting that staff perform the rebuild rather than watching us do it makes the final weeks less comfortable. Both are cheaper than the alternative, which is being the only organisation on earth that can deploy a department's tax system.

Two clauses worth putting in the tender

First, make the rebuild a payment condition. Wording along these lines works: final acceptance requires that department personnel, without vendor intervention, provision a complete environment from the department-owned repository and pass the agreed functional test set. Observers permitted, participants not.

Second, require an exit test during the support period, not only at the end. Once a year, the department revokes vendor access for a fixed window and runs its own deployment. If it works, the handover is still real. If it does not, you have found out while the relationship is still cooperative rather than during a dispute. That annual afternoon is the cheapest insurance in the contract.