The double-spend window: what happens to access during a post-merger integration

Every post-merger IT integration has a period during which the acquired company’s people can do their old job in the old estate and their new job in the new one. It usually starts on completion day and it is meant to end when migration finishes. In practice it ends when someone remembers to close it, which is a different date entirely and frequently never.

I have been through this six times. The pattern does not vary much, and neither does the outcome.

What the window actually is

On day one, the acquired company has its own directory, its own groups, its own file shares and its own line-of-business systems. The people in it have access to all of that. The commercial imperative is that the business keeps running, so nothing is switched off.

Within a few weeks, those people also need access to the acquiring company’s systems: the intranet, the shared drives, the finance system, whatever the group standard is. So accounts are created for them in the parent directory, or a forest trust is stood up, or — most commonly — both, because the trust covers some systems and manual account creation covers the rest.

At this point every person in the acquired business holds two sets of access. Both sets are live. Both sets are justified. Nobody is doing anything wrong.

I call this the double-spend window because the organisation is paying twice for the same person’s access: twice the licences, twice the attack surface, twice the review burden. The licence cost is the one that gets noticed, because it appears on an invoice. The other two are the ones that matter.

Why it does not close on schedule

The integration plan almost always has a decommissioning phase. It is at the end, it is not resourced as heavily as the migration phases, and it is the first thing that slips when the migration itself runs late — which it does, because migrations always do.

Then a few specific things go wrong, in roughly this order.

The long tail of systems nobody documented. The migration covers the systems that appeared in the due diligence pack. It does not cover the reporting tool that one analyst runs, the FTP account a supplier uses, or the ancient application that authenticates against the old domain and has no supported migration path. Each of these is individually small and collectively the reason the old directory cannot be switched off.

The person who leaves during the integration. Attrition after an acquisition is high, and it is highest among exactly the people who understand the old estate. When they go, the offboarding process runs against whichever directory HR is connected to — usually the new one — and the old-estate access stays behind. This is the single most common way a leaver’s access survives.

The trust that becomes permanent. A forest trust set up “temporarily, for six months” is load-bearing within a year. Removing it requires knowing what depends on it, which requires the documentation that does not exist. So it stays, and with it stays the transitive access nobody has enumerated.

The reorganisation that happens mid-integration. People move roles during the integration, because that is often the point of the acquisition. They pick up new access for the new role and keep the old access from the old one, in both estates simultaneously. A mover during an integration can accumulate four distinct sets of permissions inside a year.

What it looks like eighteen months later

The technical shape is consistent. In the acquired estate you find enabled accounts belonging to people who left, service accounts whose purpose nobody can state, and groups whose names refer to the acquiring company’s structure as it was during the integration — which is not the structure now.

In the acquiring estate you find accounts that were created manually during the window, so they never came from the HR feed and are not covered by the joiner-mover-leaver process that governs everyone else. They are invisible to the process precisely because they predate their subject’s arrival in it.

And connecting the two, you find nested groups. Someone needed a quick way to give the acquired company’s finance team access to the group finance share, so a group from one side was nested inside a group on the other. That nesting is now four levels deep and the outermost group has three hundred members.

None of this is exotic. It is the predictable consequence of doing a difficult thing under time pressure with a team that is smaller than the work.

The audit conversation

The point at which this becomes a live problem is the first certification audit after the integration. The auditor asks for evidence of access review across the combined estate, and the honest answer is that access review has been running against one directory while a second one existed.

There is a version of this conversation that goes badly, and it goes badly not because the estate is a mess — auditors have seen messy estates — but because the organisation cannot describe the mess. “We have some legacy access we are working through” is a survivable answer if you can produce the list. Without the list it reads as not knowing, and not knowing is the finding.

What to do about it

The mitigation is not clever, it is just unglamorous and it has to start on day one rather than at the decommissioning phase.

Enumerate the double-spend at the start, and re-enumerate monthly. A list of every person holding access in both estates, produced repeatedly, is the single most useful artefact of an integration. It goes down over time or it does not, and either way you know.
Tag every object created during the window. Accounts, groups and grants made during an integration should be identifiable as such — a naming convention, a description field, an OU, anything queryable. Two years later, “created during the Cygnet integration” is the difference between a five-minute answer and a fortnight of archaeology.
Run the leaver process against both estates. This one is cheap and it closes the largest single source of orphaned access. It requires only that somebody writes down that the second directory exists.
Give the trust an expiry with a named owner. Not a date in a plan, a date with a person attached and a diary entry. The trust outlives the integration because nobody owns removing it.
Resolve effective access, not group membership. The nesting created during an integration is where the surprises live. A list of who is in which group tells you very little once groups contain groups contain groups. What you need is the resolved answer: for this share, this system, this permission, who actually ends up with it.

That last point is the one that is genuinely hard by hand, and it is the reason this problem tends to be described rather than fixed. Resolving effective access across two directories, one of which is being progressively dismantled, is not a spreadsheet exercise.

The uncomfortable summary

The double-spend window is not a failure of process. It is a deliberate, correct decision to keep the business running during a change that is inherently disruptive. The failure is treating it as a temporary state and therefore not measuring it — because the whole difficulty is that it is not temporary, and by the time that becomes obvious, the evidence of how it started is gone.

Measure it while it is open. It is much cheaper than reconstructing it afterwards.