The handover: how we transfer ownership so the system still works a year later.
ISO Cloud Consulting editorial teamA quality system handed over in a final meeting is handed over too late. Name an administrator and deputy in week one and have them build alongside, train the twenty tasks they will actually do, write runbooks, keep change control light, assign process owners, and check in at thirty, sixty and ninety days.
Why is the usual handover too late?
Most quality systems are handed over at the end of a project, in a meeting, with a folder of documentation. That is too late. Here is how we transfer ownership so the system still works a year later.
Who should own the system, and when do they start?
It starts in the first week. We ask you to name a system administrator and a deputy from your own team. Not the managing director, and not IT alone, but someone who works with the quality processes and has some time each week.
From that week they build alongside us. When we configure a list, they watch, then build the next one. When we build a flow, they change a condition and test it. By go-live, they have already run every workflow without us.
What does admin training cover?
Admin training is practical. We do not teach the whole platform. We teach the twenty or so tasks the administrator will actually do.
Adding someone to a role group. Creating a new document type. Changing an approval route.
Adding a column to a register. Fixing a stuck flow. Restoring a deleted item.
Running the quarterly access review. Each one is practiced on the live system, with the administrator at the keyboard.
Each of those tasks gets a short runbook: when to do it, the steps, how to check it worked, and what to do if it fails. The runbooks are controlled documents inside the system itself, so they are versioned and easy to find.
How heavy should change control be?
Change control is set up to be lighter than the changes it governs. Adding a choice to a list needs a log entry and a quick test. A new workflow needs a short plan, a test in a copy, approval and a review afterwards.
If change control is heavier than the change, people bypass it and the system drifts.
Who owns processes versus the platform?
Ownership covers processes, not just the platform. Each process page has an owner from your team, by role, who owns the procedure, the register and the metric. The administrator owns the platform.
That split matters, because a system with only a technical owner slowly turns into an IT project.
What happens after go-live?
Then the check-ins. At thirty days we review usage: which forms are used, which are not, and why. At sixty days we look at the data: are records complete, are actions closing, is the dashboard being opened?
At ninety days we sit down with leadership and the administrator, fix what does not fit, and agree what the system needs next. After that, you call us because you want to, not because you need to.
Why record the reasons behind design decisions?
One more thing gets handed over: the reasons. For every design decision that is not obvious, such as why an approval routes to a role or why a register has a particular field, we leave a one-line note in the system documentation. Two years later, when someone wants to change it, they can see what it was protecting.
How do you know the handover worked?
The test of a good handover is simple. Twelve months on, the system has changed because your team improved it, and nobody had to ask us how.
How do we run a build?
The turnkey eQMS section of the consulting page explains how we build and hand over a quality system on Microsoft 365 or Google Workspace. For the documents inside it, see the ISO 9001:2026 Complete QMS Documentation Kit and the ISO 9001:2026 templates collection.
