For the chief information officer

You will own this longer than anyone who is selling it to you

So the honest opening is the boundary: this does not replace your systems of record, and nobody here is going to tell you it collapses your estate. It joins the estate. What follows is what it costs you to carry, what it can genuinely let you retire, and where it plugs into the identity and integration you already run.

The estate you did not choose, and still answer for

Most of what you run arrived before you did, or arrived past you. A department bought a tool with a corporate card, ran it for two budget cycles, and it now holds records somebody needs. Half the portfolio sits on renewal dates you inherited and licence counts nobody has audited since the person who negotiated them left.

Meanwhile the mandate coming down is consolidation, and the mandate arriving sideways is artificial intelligence in everything, immediately, without additional headcount. Those two instructions are in direct tension and both are issued to you as though they were compatible.

The part nobody in a demonstration acknowledges is the carrying cost. Everything joining the estate needs an owner, a directory integration, a provisioning path, a place in the access review, a line in the disaster plan, a vendor contact who answers, and somebody who knows how it works when that colleague resigns. The licence fee is the cheapest part of the bill.

And you have been promised a rationalisation before. It arrived as one more platform beside the eleven it was going to absorb, because the absorption quietly depended on a migration nobody was willing to fund once the demonstration enthusiasm wore off.

Additive capability is a cost, even when it works

A capability that only ever adds to the estate makes your position worse every year, however well it performs — because carrying cost compounds and nothing ever leaves.

The question that decides whether this deserves your attention is not whether it works. It is whether anything can be put down as a result. If the answer is nothing, the correct decision is usually no, and we would rather you reach that quickly.

What can genuinely be retired is a narrow, specific list, and it is short on purpose. Point automations glued between two systems by a departed contractor. Standalone workflow tools bought for a single queue. Spreadsheet-and-inbox processes that were never software in the first place but consume the same review attention. Where a function is currently held together by a colleague manually moving records between two screens, that is the shape this replaces well.

What it does not replace is your system of record. Not the finance ledger, not the electronic record, not the case-management platform a regulator expects to see. Those stay, they remain the source of truth, and this reads and writes against them under your access model rather than duplicating them into a second store you would then have to reconcile.

Stated that way the sum is honest: one arrival, several departures, and a system of record left alone. If that arithmetic does not come out in your favour for a given function, that function is not the right first scope.

What moves on your side of the ledger

Whether anything leaves the estate rather than only joining it — measured by count of tools actually decommissioned against the list named before signature.

How long a new joiner waits for correct access — measured by elapsed hours from directory record to working access, against your current baseline.

Where undocumented glue lives between two systems — measured by named integrations moved off a colleague or a contractor script onto something with an owner.

How much of a function survives its expert resigning — measured by whether the workflow still runs, and who has to be called when it does not.

Whether an access review can be completed from one place — measured by time to produce a full entitlement list for the function, end to end.

How early an interoperability gap is discovered — measured by stage at which a missing connection surfaces — scoping is the target, implementation is the failure.

that your estate gets smaller. One thing joins it. Whether the net is favourable depends on what actually leaves, which is why the retirement candidates are named in writing before signature rather than described in a slide afterwards.

Where it sits against what you already run

Identity is the first question and it decides the rest. Authentication goes through your existing provider by standard federation, and provisioning follows your directory rather than creating a parallel population of accounts that drifts out of your joiner-mover-leaver process inside a quarter.

Evidence and audit records stream to wherever you already collect them, so this does not become an eleventh place your security team has to remember to look during an investigation.

For systems of record the pattern is read and write under your access model — the record stays where the regulator, the auditor and your own people expect to find it. Where a connection does not exist for something you depend on, that is named during scoping along with the work it would take, rather than surfacing during implementation.

The parts a four-year owner should check first

The questions that matter to somebody holding this in year four are not the ones asked in year one. They are: can I get everything out, does it still work if the vendor relationship ends badly, and is there a single place an auditor can see who did what.

Those are answered on their own pages rather than summarised here, because a summary is where a caveat goes to disappear. The exit procedure, the observability position and the change-management commitments each have a page that states the limit as well as the capability.

What your own architecture review will want

An architecture review board asks a different set of questions from a security questionnaire, and the two are frequently answered with the same document to the satisfaction of neither. The items below are the architecture set.

Ask for the ones that apply to the deployment you are actually contemplating. A single bounded queue and an estate-wide rollout have different answers, and receiving the estate-wide pack for a single-queue decision wastes the reviewer time it appears to save.

Name what leaves before anything arrives

One function currently held together by a colleague moving records between two screens — small enough that ending it costs a scope, specific enough that the retirement arithmetic is checkable.

The single most useful thing you can do at the start costs nothing and is almost never done: write down what this is supposed to let you retire, and get it agreed before signature. Afterwards it is a discussion. Before, it is a criterion.

Then pick a function where the current glue is a colleague rather than a platform. Those are where the arithmetic comes out clearly, where success is unambiguous, and where the reversal cost is a scope rather than a migration.

And decide in advance what would make you stop. A chief information officer who has written that down has a decision. One who has not has a renewal.

Questions buyers actually ask

I have been sold consolidation before and ended up with one more platform.

That is why the retirement candidates are named in writing before signature here, and why this page says in its opening line that no rationalisation is on offer. If the list of things that can actually be put down comes back empty for the function you have in mind, the arithmetic is against you and the right answer is no. We would rather establish that in a first conversation than in your third budget cycle.

My mandate is to reduce vendor count, and this increases it.

It does, by one, and the question is whether more than one leaves as a result. Where a function is currently run by a departed contractor’s scripts plus two single-queue tools plus a spreadsheet, the net is favourable and checkable. Where it is currently run by a platform you are contractually committed to for three more years, it is not, and that function should not be the first scope.

Who owns this internally once the sponsor moves on?

That is the right question and it is the one most often left until it is urgent. It gets established during the first scope rather than after: a named owner on your side, a named escalation path on ours written into the contract rather than a portal page, and an access review that can be completed from one place. If nobody on your side will own it, that is a genuine reason to decline and it does not improve with a larger deployment.

What happens to us if you are acquired or you fail?

Ask for the export and reconstitution procedure before signature — it is the request that tells you most about any vendor precisely because it is the one they gain nothing by answering well. Governed state, workflows, history, evidence and configuration are designed to leave in open or documented forms, and reconstitution testing is part of that design rather than export alone. Read that page and judge it; it states its limits as well as its capabilities.

You have no SOC 2 report and my architecture board treats that as a gate.

Then say so now rather than after an evaluation that cannot conclude. The attestation is in progress and the observation window has to run — no contracting language substitutes for the report. If your policy permits a bounded, low-sensitivity first scope while it completes, that is the conversation worth having. If it does not, declining is the correct call and we would rather have it early.