Separate business capabilities before separating systems
An IT carve-out starts with a practical question: who will be able to sell, ship, invoice, pay staff and support users on the first day of the separated business? Legal completion does not create these capabilities. A working application may still rely on the seller’s identity domain, a shared master record or an administrator who is not joining the buyer. Start with the transactions needed to operate the business and trace their technical, human and contractual dependencies.
Day 1 aims at controlled minimum autonomy. It does not require immediate modernisation of every application. A transitional services agreement, or TSA, can protect a capability while its replacement is built. The danger is an agreement that conceals undocumented dependencies or has no funded exit. Design the temporary service and the target service together, with separate evidence for opening the business and closing the transition.
A fictional separation exposes a hidden dependency
Consider a fictional manufacturer selling two factories and a commercial operation. Every number in this example is for teaching purposes. Its 620 employees use 38 applications, of which nine support essential opening capabilities. The shipping application seems independent, but label printing calls a central database, a licence server and a group identity service. A successful shipment test can conceal an authentication token that will fail to renew the next morning. The rehearsal must reproduce that delayed dependency.
Here, the seller’s ERP remains under a TSA while email, support and network access move to the buyer. The separation director assigns an owner to each capability, including payroll and bank reconciliation. Both parties approve one dependency map showing reads, writes, operating hours, personnel, contracts and exit conditions. An unexplained arrow is an unresolved decision, rather than a cosmetic imperfection. The team must identify whether the dependency remains available after completion.
Make Day 1 acceptance observable
Write an acceptance statement for each capability. A salesperson can create an authorised order, a warehouse operator can ship it, finance can issue the correct invoice and support can resolve an incident. Record the test identifiers, expected result, evidence owner and decision deadline. Test access denials as carefully as successful access: the buyer’s users must not see customer records belonging to the retained business.
Data separation needs a specific decision process. Legal ownership of a customer relationship, historical documents, shared postings and retention requirements cannot be inferred from a company-code filter alone. Finance, legal and privacy specialists approve copying, masking and retention rules. Run these rules on a trial extract and reconcile results to source totals before releasing data. Encrypt transfers and restrict recipients. A signed transaction agreement does not replace these operational controls.
Worked model: capabilities and exit conditions
| Fictional capability | Day 1 arrangement | Evidence owner | Exit condition |
|---|---|---|---|
| Orders and invoices | Seller ERP TSA: EUR 42,000 monthly | Finance director: 50 orders, tax and credit notes reconciled | Target ERP completes two business cycles without major correction |
| Identity and support | Buyer directory and dedicated support | Security lead: 620 accounts, prohibited access denied | Trust relationships removed after service-account review |
| Factory labels | Seller service TSA: EUR 8,000 monthly | Factory manager: printing and recovery tested | Target licence signed, load and supplies checked |
| Payroll | Existing provider under separate contract | HR manager: payment file and headcount checked | First payment and exception handling accepted |
Write the TSA as an operating service
A usable TSA specifies its catalogue, included volumes, service hours, incident priorities and escalation path. It says who authorises changes, owns data, reviews access and shares security incidents. The commercial contact and operating owner may be different people. Urgent capacity requests need a known approval route and price. Specify cooperation when several seller teams support one service; otherwise each team can meet its own commitment while the capability still fails.
Tie the end date to a credible delivery milestone and negotiate extension procedures before an emergency. Ending invoices is not the same as transferring data, configuration, knowledge and unresolved tickets. For critical services, define export formats, response times and cooperation after transfer. The separation committee treats contractual disagreements as operating risks with an empowered decision owner. An exit timetable without access to the people performing the service is not an executable plan.
The cost model includes two organisations
In this example, total separation cost equals one-off migration expense plus cumulative TSA charges, autonomous target operations, overlapping services, seller stranded costs and a reserve for identified risks. The reserve must not hide every unknown. A support estimate without ticket volumes, coverage hours or staffing requirements remains an assumption. Separate cash movement, recurring expense and sunk cost so that the investment decision does not compare unlike quantities.
Removing two months of a EUR 50,000 TSA would nominally save EUR 100,000. If acceleration adds EUR 70,000 of delivery expense and EUR 45,000 of overlap, it costs EUR 115,000: a EUR 15,000 loss before risk. The finance director therefore compares incremental cost, extension likelihood and the business consequences of failure. TSA reduction is not automatically value creation. The model also tests a slower migration and a controlled degraded-service option.
The seller may retain an entire licence or team after users leave. These stranded costs need their own reduction plan. At the buyer, shared capabilities may become more expensive per user because monitoring, on-call support and compliance have fixed costs. Transaction pricing and the transformation budget should use consistent assumptions. Treat theoretical savings separately from contracts that can actually be terminated, and assign someone to obtain the termination evidence.
Opening and exit require different gates
The Day 1 committee brings together separation leadership, business owners, IT, security and data specialists. For this exercise it refuses opening if any of the nine essential capabilities lacks evidence, a privileged account has no owner or recovery would exceed the permitted interruption window. A minor defect can be accepted only with a tested workaround, available staffing and a resolution date. Delay does not make a defect less material.
Exiting a TSA requires a different demonstration: the target service produces correct results, operators can handle exceptions and the old service is no longer called. Observe logs and flows for two cycles suited to the capability, rather than imposing one duration on payroll and shipping. A monthly flow missing from tests can preserve a silent dependency. The business owner accepts performance, the technical owner confirms independence and the contract owner closes the agreement.
Schedule around actual constraints
Before completion, freeze the legal data perimeter and rehearse essential journeys with the people who will actually run the separated operation. During the separation window, maintain one decision log. After opening, track order errors, rejected payments, support delays and residual seller calls. These observations should determine TSA exits. They should not merely decorate a green programme report.
Resolve blocking dependencies before the final rehearsal. If the factory’s target licence is unavailable, retaining a clearly defined TSA may be the sound option. If the seller cannot guarantee service, quantify degraded operations: achievable shipments, required staff, tolerable duration and delay costs. Leadership can then choose a measured risk. An undocumented manual fallback may be physically impossible at normal operating volume.
Sector implications
Manufacturing prioritises equipment, production recipes, traceability and maintainer access. A plant may tolerate temporary email loss while being unable to operate without reliable labels or machine programmes. Include shared terminals and intermittent connections in rehearsals. Retail needs precise ownership of available stock and returns: who honours a credit issued before completion, and in which system is it recorded?
Financial services add reconciliation, reporting and access to historical records. Sector outsourcing guidance offers a governance reference within its scope, rather than a universal carve-out rule. Professional services often prioritise billable time, document permissions and named licences. Evidence principles remain consistent, but critical capabilities and validation cycles change with the economics of the business being separated.
Sources and method
This retrospective examines decisions available in 2022. The 2010 NIST continuity guide informs recovery and exercises, the 2019 EBA guidelines concern their financial-sector scope, and the GDPR addresses personal-data processing. None sets TSA prices or prescribes a universal carve-out method. Editorial verification in 2026 does not make later practices part of the 2022 baseline.
Primary sources checked in October 2026. NIST SP 800-34 Rev. 1, 2010. EBA, Guidelines on outsourcing arrangements, 2019. CNIL, RGPD, articles 28 et 32.
All situations, amounts, durations and thresholds are fictional teaching examples. They illustrate a decision method and do not describe any CYTIZEN engagement or market benchmark. The operational recommendations are the author’s proposals, separate from the cited documents.