CelinQ Insights · No. 30

Leaving a client with a repository they can actually maintain

Consultancy handovers that don't decay the moment you leave the room.

The end of a consultancy engagement is supposed to be the good part. The work is done, the model is delivered, the client is satisfied, and the consultant moves on to the next problem with a clean conscience. This is the story everyone tells at the closing meeting. The truth is usually more melancholy, and every honest consultant knows it. Six months after the handover, the model that was delivered in pristine condition has begun to rot. It is out of date, because nobody on the client side quite knew how to change it safely. It is inconsistent, because the one person who understood its conventions has left and taken the conventions with them. And increasingly it is simply not opened, because it has drifted so far from reality that consulting it would mislead rather than inform. The engagement succeeded and the deliverable failed, and the two facts sit next to each other uncomfortably.

This decay is not a failure of the consultant's skill or the client's diligence. It is a structural feature of how architecture handovers are usually done, and it will happen to good work delivered to good people as reliably as it happens to bad work delivered to careless ones. The reason is that most handovers transfer the artefact without transferring the capability to maintain it, and an architecture model that cannot be maintained is not an asset. It is a photograph of an asset, accurate on the day it was taken and less accurate every day thereafter. The consultant who wants to leave something durable has to think about the handover not as the delivery of a file but as the transfer of an ongoing capability, and that is a much harder thing to do than it sounds.

What actually gets handed over, and what quietly does not

Consider what typically changes hands at the end of an engagement. There is the repository itself, the model, usually delivered as a file or a set of files. There is documentation, of varying quality, describing what the model contains and how it is organised. There may be a walkthrough session where the consultant explains the structure to whoever on the client side has been nominated to inherit it. And there is a handshake, metaphorical or literal, after which the consultant's responsibility formally ends. On paper this looks complete. In practice it transfers the least important things and omits the most important one.

The most important thing is not the model and it is not the documentation. It is the working knowledge of how to change the model without breaking it: the conventions, the reasoning, the accumulated sense of why things are the way they are and what will go wrong if they are changed carelessly. This knowledge lived in the consultant's head, and it was built up over the whole engagement through hundreds of small decisions, most of which were never written down because writing them down was not the job. When the consultant leaves, this knowledge leaves with them, and no walkthrough session is long enough to transfer it. The client is left holding the artefact and missing the capability, which is precisely the recipe for decay.

A handover that transfers the model but not the ability to maintain it has not delivered an asset. It has delivered a beautiful object that the client will be afraid to touch, and fear is what turns a living model into a museum piece.

There is a second, quieter omission that compounds the first. In a great many engagements, the working repository lived on the consultant's own machine or in the consultant's own tooling arrangement throughout the project. The history of how the model came to be, the sequence of changes, the record of what was tried and abandoned, all of it accumulated in the consultant's environment. At handover, the client receives the final state but not the history, because the history was never in a place the client controlled. This is not usually malicious or even deliberate; it is simply where the work happened to live. But it means the client inherits the last page of a book whose earlier pages they never had, and when they later need to understand how a particular decision was reached, the record is gone with the consultant who made it.

The engagement lives on the wrong infrastructure from day one

The root of both omissions is that the ownership question is usually settled far too late. Handover is treated as an event at the end, when in reality the conditions for a good handover or a bad one are set at the very beginning, in the decision about where the work will live and on whose infrastructure it will run. If the model lives on the consultant's laptop for the duration of the engagement, then handover is necessarily an act of extraction and transfer, a moving of the model from the consultant's world into the client's, and everything that does not transfer cleanly in that single act is lost. If instead the model lives, from the first day, on infrastructure the client owns, then handover is not an extraction at all. It is a change in who holds the keys to something that was always in the client's house.

This is the shift that CelinQ's shape enables, and it is worth being concrete about how. CelinQ is local-first: each architect, including the visiting consultant, edits a local repository at full speed, online or offline, and a background companion reconciles each save with a shared workspace. The crucial detail for handover is where that shared workspace runs. It runs on a server the organisation runs itself. If the engagement is set up correctly, that organisation is the client from the outset. The consultant works locally, as they always would, but the authoritative shared workspace, the accumulating history, the whole living record of the model, lives on the client's own server the entire time. Nothing has to be extracted at the end because nothing was ever removed from the client's control at the beginning.

Framed this way, handover stops being a cliff edge and becomes a taper. During the engagement, the consultant is an Editor, or perhaps an Administrator, working against the client's shared workspace alongside whichever client staff are participating. As the engagement winds down, client staff take on more of the substantive work while the consultant does less, and the transition of capability happens gradually and in situ rather than in a single overwhelming session at the end. On the final day, the consultant's role is simply removed. The model does not go anywhere, because it was never anywhere else. The history does not need to be transferred, because it already lives on the client's server. The client is not handed a file; they are handed nothing, because they already had everything, and that is the point.

Roles are the mechanism of a clean exit

The graceful exit depends on the tool being able to distinguish between people and to change those distinctions cleanly, which is exactly what roles are for. CelinQ carries roles that map onto the reality of a mixed consultant-and-client team. A Viewer can see the model but not change it. An Editor does the substantive modelling. An Administrator manages the workspace and its people. An Owner holds ultimate control. The single most important thing a consultant can do for a clean handover is to make sure that from early in the engagement, the Owner is the client and not the consultant. The consultant should be a powerful contributor, an Editor and perhaps an Administrator, but the ownership of the workspace should sit with the client from the start.

When ownership sits with the client from the start, the exit is almost administrative in its simplicity. The client, as Owner, removes the consultant's access. The consultant's local repository becomes an inert copy with no path back into the client's workspace, because the token that authorised the connection is revoked and the encrypted, certificate-pinned link no longer has anyone on the other end willing to talk to it. There is no awkward negotiation about who holds the master copy, no risk that the consultant retains live access to a client's sensitive model after the engagement has ended, no ambiguity about whether the client truly has everything. The client always had everything, and the exit is simply the moment they stop sharing it with the departing consultant. This is cleaner for the client and, worth saying plainly, cleaner for the consultant too, who is relieved of the liability of holding a client's architecture after they have no business holding it.

Change review and governance play a role here too, and it is a role that outlives the consultant. During the engagement, the review mechanism lets the client's own staff watch and understand the changes the consultant is making, which is itself a form of knowledge transfer that happens continuously rather than in a rushed final session. After the engagement, the same mechanism lets whoever the client puts in charge of the model govern the contributions of others, so that the discipline the consultant established does not evaporate the moment they leave. The governance is not something the consultant does to the model and takes away; it is a capability that stays behind, embedded in how the workspace works, and it is available to whoever inherits the Owner and Administrator roles.

Handing over the history, not just the state

The complete, ordered revision history is where this approach delivers something that a file-based handover structurally cannot. Because every change was reconciled into the client's shared workspace as it happened, the client inherits not just the final model but the entire sequence of how it came to be. When a client architect, a year after the consultant has gone, needs to understand why a particular structure was chosen, the answer is not lost with the consultant. It is in the history, in the ordered record of changes that lives on the client's own server. The reasoning that used to walk out of the door in the consultant's head now has a durable trace that the client can consult long after the engagement is a memory.

This is the difference between inheriting a photograph and inheriting a film. The photograph shows you the final state and tells you nothing about how it was reached, so every question about the past is unanswerable and every future change is made in ignorance of the history that shaped the present. The film shows you the whole sequence, so the client's own architects can reconstruct the reasoning, understand the trajectory, and make their future changes in a way that is continuous with the past rather than a fresh guess layered on top of a state they do not understand. A model that can be understood historically is a model that can be maintained, because maintenance is fundamentally about changing something without breaking the reasoning that made it what it is, and you cannot preserve reasoning you cannot see.

Because a workspace can be cloned to a fresh local repository, the practical mechanics of getting the client's own architects up and running are trivial. Each client architect who will maintain the model clones the workspace and has the entire model and its history on their own machine, ready to work in at full speed. There is no dependency on the consultant's environment, no proprietary arrangement that only the consultant understood, no lingering need to call the consultant back to explain how to open the thing. The storage underneath is an ordinary database, SQLite or PostgreSQL, that the client's own infrastructure team already knows how to run, back up and secure. The whole arrangement is built out of components the client can operate without the consultant, which is the only kind of handover that does not decay.

The honest work of transferring capability

It would be a disservice to suggest that the right tooling makes handover effortless, because it does not, and NILUS builds automation and tooling precisely because the hard parts deserve real effort rather than a wave of the hand. The tool removes the mechanical obstacles: the extraction, the transfer of history, the ambiguity of ownership, the risk of retained access. These are genuinely worth removing, because they are the obstacles that turn a handover into an event fraught with loss. But removing them exposes the part that was always the real work, which is the transfer of judgement and convention from the people who built the model to the people who will keep it alive. No tool transfers judgement. Judgement is transferred by people working alongside each other, by the client's architects contributing under review while the consultant is still present, by the accumulated understanding that comes from having been in the room while the decisions were made.

What the local-first arrangement does is make that human transfer possible in the first place, by keeping the client's people continuously involved rather than presenting them with a finished object at the end. When the client's architects have been Editors in the shared workspace throughout, contributing real changes under review, watching the consultant's changes flow past, and building up their own sense of the conventions save by save, the final handover is not a cliff they are pushed off but a threshold they walk across having already done most of the walking. The capability was being transferred the whole time, in the ordinary course of the work, rather than being crammed into a farewell session and hoped for. The consultant's departure removes a contributor from a practice that already knows how to function, instead of removing the only person who knew how the model worked.

There is a reason NILUS frames its own delivery as automation, tooling and scripts rather than as a set of clever tricks the consultant performs and takes away, and the handover is where that framing earns its keep. Anything that only works because a particular person is present is, by definition, not something that can be left behind. A model kept consistent by one architect's memory of the conventions decays the moment that memory leaves the building. A model kept consistent by tooling and by a governance mechanism embedded in the shared workspace survives, because the thing that enforces the discipline is not a person but a system, and the system stays. This is why the consultant's most valuable contribution to a durable handover is often not the model itself but the establishment of a way of working around it: the roles, the review, the conventions made mechanical rather than remembered. When the discipline is built into how the workspace operates, the client inherits the discipline along with the model, and the two are not separable.

This also reframes what the closing weeks of an engagement should actually be spent on. The instinct is to spend them polishing the model and thickening the documentation, on the theory that a more complete artefact is a more maintainable one. But documentation describes the model at a moment and ages the instant it is written, and a polished model that the client cannot safely change is still a model the client cannot safely change. The better use of those closing weeks is to shift the substantive work decisively onto the client's own architects while the consultant is still present to catch mistakes through review, so that by the final day the client's people have already been maintaining the model in earnest for some time. The proof that a handover will hold is not a signed document; it is the client's own architects making real changes, confidently and correctly, before the consultant has even left. Everything the tooling does is in service of making that possible rather than making the farewell presentation look impressive.

The intelligent features, where a client chooses to use them, follow the same principle of staying under the client's control. The optional in-tool design assistant that can generate content into a selected package and analyse existing parts is off by default, sovereign, and unnecessary to the core, which means the consultant is never in the position of leaving behind a dependency the client cannot operate or does not want. Whatever the client keeps after the engagement, they keep on their own terms and their own infrastructure, without an external service they must maintain a relationship with in order to keep the model working. The core needs nothing outside the client's control, and that is precisely what makes it safe to leave behind. A handover that creates a new external dependency has not really ended; it has merely changed who the client has to keep calling.

The measure of a good handover is not the polish of the closing presentation or the thickness of the documentation binder. It is what the model looks like a year later, when the consultant is long gone and the client has been living with it on their own. Does it still reflect reality, because the client's own people have been able to change it safely and confidently? Does it still answer questions about the past, because the history came with it and stayed on infrastructure they own? Is it still opened, because it is still trusted, because it never became a museum piece nobody dared to touch? A handover engineered around a model that always lived on the client's server, that carried its full history with it, that transferred capability continuously rather than in a final rush, and that ended with a clean revocation of access rather than an anxious extraction, is a handover with a real chance of passing that year-later test. That is what it means to leave a client with a repository they can actually maintain: not a file and a fond farewell, but a living thing they already owned, already understood, and were already keeping alive before the consultant ever walked out the door.