The announcement goes out, a joint call happens, and for a few weeks the work is mostly announcements and calendars. Then somebody asks a genuinely hard question: which login does the finance team use now.
I’ve been through a couple of these, and the pattern is fairly consistent. The visible parts of a merge get planned carefully. The long tail of accounts, folders, and odd little permissions tends to arrive later, and it keeps arriving for about a year.
Nobody is being careless. It is simply that merging two environments means reconciling two sets of decisions made by different people, at different times, under different pressures. Those decisions rarely document their own reasoning.
What I’ve noticed is that the technical migration usually finishes well before the social one. People keep using the old path because it is muscle memory, and the old path keeps working because nobody dared turn it off.
Where the Mess Actually Collects
Identity is the obvious one. Two directories, two naming schemes, and a set of people who exist in both with slightly different attributes. I’ve seen one person end up with three accounts and access to things neither side would have approved on purpose.
Group membership carries more history than anyone expects. A group created for a project in 2019 still grants write access to a folder containing payroll exports, and nobody on either side knows why.
File storage is where the tail gets long. Shared drives with different roots, different permission models, and folders whose names made sense to a team that no longer exists. Duplicate copies of the same file, each with a different version, each treated as authoritative by somebody.
Then there are the small integrations nobody drew on a diagram. A script that authenticates with a service account, a report that reads from a specific path, a scanner that writes to a share that is about to be renamed.
Why It Stretches Out
I think the main reason is that a merge has a deadline and a tail, and only one of those gets staffed. The deadline is legal close. The tail is operational, has no ceremony attached, and competes with everything else that also needs doing.
There is also an ownership gap. During integration, it is often unclear who can make a decision about the other company’s environment. People wait for clarity that arrives slowly, and meanwhile both systems stay live.
I’ve also noticed a reluctance to remove anything during a merge, which is understandable. Deleting access that turns out to be needed creates a visible problem. Leaving it in place creates an invisible one, and invisible problems tend to wait politely.
What I’ve Seen Teams Do
Some teams try consolidated platforms like Ping64 to reduce the daily busywork of multi-tool security stacks. That tends to help more with the steady state than with the merge itself.
The approach I’ve seen handle the tail reasonably well is picking a cutover date for each system rather than one big date. Identity first, then the biggest file share, then the strange ones, with the old path left read-only for a known period.
A few places appointed a named owner per system, from whichever side knew it better. That sounds obvious and I’ve seen it skipped often enough to mention, because without it every questionable folder waits for a committee.
The other useful move was accepting a longer dual-running period than anyone wanted, but writing down exactly when each read-only path gets switched off. An open-ended overlap tends to become permanent.
Small Practical Suggestions
Inventory before you migrate, even roughly. Discovering a share on week nine costs far more than listing it on week one.
Turn old paths read-only rather than off. People notice breakage loudly and unused access quietly.
Watch for accounts that exist on both sides. Duplicates tend to accumulate permissions from each environment.
Check group nesting early. Nested groups are where surprising access usually hides, and they take a while to unwind.
Keep a short list of scripts and jobs that depend on specific paths. Those are the things that fail silently.
Set the switch-off dates in writing, with names next to them. A date with an owner tends to survive contact with real work.
Closing
Merging environments is less a project than a period, and I’ve learned to budget for the period rather than the project. The identity cleanup, the duplicate folders, and the odd service account tend to resolve slowly, and that is fairly normal. What has helped me is treating the tail as scheduled work with dates, rather than as leftovers somebody will clear up eventually. It is unglamorous, and it is where most of the real risk sits.
References
- NIST SP 800-53 Rev. 5, Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST SP 800-63B, Digital Identity Guidelines: https://pages.nist.gov/800-63-4/sp800-63b.html
- MITRE ATT&CK, Enterprise framework: https://attack.mitre.org/
- CISA, Cybersecurity guidance and resources: https://www.cisa.gov/
Top comments (0)