The failure mode of infrastructure consulting is a system that works and nobody but the consultant understands. It is rarely deliberate. It happens because the knowledge that made the thing work lived in conversations, and conversations do not get committed.
So we treat handover as a deliverable with a definition of done, not as the last week of the calendar.
The test
If OpsaFlow disappeared overnight, could your team keep this running?
Not "could they read the code". Could they deploy a fix on a Friday, restore from a backup, rotate a credential, and understand why the 3am alert fired. Until the answer is yes, the engagement is not finished, regardless of what the schedule says.
We check it the obvious way: someone on your team does the operational tasks, from the documentation, while we watch and say nothing. Every place they get stuck is a documentation bug, and it is ours to fix.
What actually gets handed over
Repositories. In your organisation, not ours, from the first commit. Full history, including the commits where we got it wrong — those are often the most useful thing in there six months later.
Infrastructure as code. Terraform and Helm definitions that describe every environment. The test is that a new environment is a file and a pipeline run, not an afternoon of clicking and a colleague's memory.
Pipelines. Build, test, scan, sign, deploy. In your CI, using your secrets store, with no step that depends on something only reachable from a machine we own.
Credentials and accounts. In your accounts from day one. Cloud, registries, DNS, monitoring, third-party APIs. We work inside your boundary rather than building in ours and transferring later, because the transfer is exactly where things get forgotten.
Monitoring and alerts. Dashboards, alert rules, and thresholds — with a written note for each alert saying what it means and what to do about it. An alert without a documented response is a notification, and notifications get muted.
Runbooks. Written for the operational tasks: deploying, rolling back, restoring a backup, rotating secrets, scaling a component, handling each alert. Plain prose with commands you can paste. Not a wiki page that says "see the deployment guide" and links to itself.
The architecture document. What the system does, why it is shaped this way, and — the part usually missing — what we considered and rejected. The rejected options matter most. Without them, the next engineer to arrive re-litigates a decision you already paid to make, or worse, quietly reverses it.
The known-issues list. What is deliberately unfinished, what we would do next, and what will need attention in six months. Every system has this list. Most handovers do not include it, because writing it down looks like admitting fault. It is the single most valuable page in the pack.
What we do not do
We do not keep a component only we understand. If part of the system needs OpsaFlow to operate, we have built the wrong thing, and we will say so before you have to.
We do not make a retainer the price of continuity. Plenty of clients keep working with us afterwards, and we would like that — but it should be because the next piece of work is worth doing, not because leaving is expensive. A retainer that exists because the client cannot operate their own platform is a hostage arrangement with an invoice attached.
Why this is a public page
Because it makes it checkable. Ask us at the end of an engagement whether each item on this list exists, and there is no room for a comfortable answer.
That is the same reason our other commitments are written down: a standard nobody can hold you to is not a standard, it is marketing.
Questions about any of it: hello@opsaflow.com.