A separation plan is often organised by application: migrate finance, copy data, stand up email, replace the network. The failure appears in shared services that do not belong cleanly to either side. One identity directory authenticates both businesses. One administrator holds the cloud estate. One data warehouse combines customers. One vendor contract contains pricing and licences neither side can reproduce. The asset has been carved out on paper while the operating system remains joined.
Shared means more than jointly used
A service is materially shared when separation requires a decision from both sides, exposes one side to the other or cannot be changed without affecting both. Look for shared:
- Identity, domains, certificates and recovery contacts.
- Networks, cloud subscriptions and security tooling.
- Data models, master records and reporting logic.
- Service accounts, integrations and automation.
- People, administrators and after-hours support.
- Vendor contracts, licences and minimum commitments.
- Policies, approvals and incident command.
Value object — The Separation Coupling Register
For each shared service, record:
- Business outcomes supported on each side.
- Technical and data components that are shared.
- Authority required to change, copy or terminate.
- Security exposure during continued sharing.
- Target end state and interim boundary.
- Critical path, substitution time and evidence of completion.
- TSA obligation, exit date and consequence of delay.
Order the register by the longest credible lead time, not by system prestige.
Separate identity first in the design
If identity remains shared, administrators and recovery paths remain entangled. Every later migration depends on who can authenticate and who can grant access. Design separate ownership of domains, directories, privileged accounts and machine identities before broad application migration. Use controlled federation as an interim state rather than leaving ambiguous ownership.
Data copies create new obligations
The buyer may need a copy while the seller must retain an archive. Determine which records transfer, which are duplicated, which must be redacted and how later corrections propagate. A database clone can preserve commingled data and excessive access. Separation must occur at the record, permission and retention levels.
The TSA can hide non-transferability
A transition-services agreement keeps operations running. It may also postpone the discovery that a vendor licence, administrator or process cannot be transferred. For every TSA service, define the buyer’s replacement capability, seller cooperation, test milestones and evidence required for exit. A date without an executable path is not a plan.
Exercise the cut
Run a controlled separation test for identity, data exchange and critical workflows. Observe what still calls back to the seller, which approvals are missing and which teams rely on shared dashboards or informal support. Do not wait for the final weekend to discover the undocumented interface.
Separation is a security architecture
The objective is not merely independent operation. It is a clean boundary in which each side can authorise, observe, recover and change its environment without exposing or disabling the other. Shared services are where that boundary becomes real—or fails.