Carving Out a UK Technology Business: Stand-Up Costs, Data Separation and Transitional Services

1. Underwrite an operating business, not an asset list

A carve-out can transfer shares, assets, contracts, employees and intellectual property while leaving critical operations inside the seller. The practical question is whether the separated business can continue to sell, deliver, support, invoice, collect, pay, report and comply when control passes. That question should govern the diligence request, cost model and transaction documents.

Technology businesses make the problem unusually interconnected. A customer-facing product may depend on a group identity tenant, shared cloud landing zone, central security operations, common engineering tools, enterprise data warehouse, group-wide software agreement and specialists allocated across several businesses. Revenue may sit in a dedicated product, while the mechanisms that authenticate users, release code, process payments and investigate incidents remain shared.

The diligence team should define a service-to-cash spine for each material product or service. It starts with customer acquisition and contracting, continues through onboarding, authentication, delivery, support, metering, billing and collection, and ends with reporting, renewal and regulatory obligations. Every dependency is attached to a stage. This approach exposes gaps that an entity chart or application inventory can miss.

The transaction decision map should answer five questions. What must exist at completion? What can remain temporarily with the seller? What must move because the buyer needs ownership or control? What can be replaced because transfer is impractical? What evidence proves that the resulting business is operationally and economically independent? Those questions create the separation perimeter.

The perimeter follows the service and cash flow across legal, operational and technology dependencies.

2. Define the perimeter through decisions and evidence

The perimeter register should combine legal ownership with operational use. Each line records the asset or service, current owner, users, data involved, contracts, location, control owner, Day 1 disposition, exit disposition, cost, timing, dependency and acceptance evidence. The same register becomes the common language for diligence, the separation programme and the transitional services agreement.

Applications need more than a name and business owner. The register should identify tenant, instance, environment, integrations, privileged roles, authentication method, hosting, source code, data stores, licences, release pipeline, support model, recovery method and end-of-life status. A seller may describe an application as dedicated while its identity, monitoring, backup or vendor contract remains shared.

People should be mapped by activity and critical knowledge. The question concerns who performs the work, which proportion of time serves the carved business, which decisions they own, which credentials they hold and whether their knowledge is documented. GOV.UK explains that TUPE can protect employees when a UK business or part of a business transfers, and Acas notes that employees assigned to the transferring part may transfer automatically.[9][12] Employee allocation, consultation and liability information require specialist legal and human-resources review.

Contracts require transfer mechanics. Supplier and customer arrangements may permit assignment, require consent, prohibit transfer or require novation. HMRC's transfer-of-going-concern manual notes that novation is a tripartite agreement requiring consent and releases the original party while establishing a new contract.[14] The programme should track every consent, replacement contract and temporary workaround by operational criticality.

Table 1. Separation perimeter decision register

Each dependency is assigned a Day 1 state and a tested exit state.

3. Separate the four economic burdens

Carve-out economics become confused when every item is called a separation cost. Four burdens should be modelled separately. One-time stand-up spend creates the buyer's independent capability. Recurring standalone cost is the annual cost of operating after separation. Seller stranded cost remains with the seller after revenue and activity transfer. Dis-synergy is the economic loss from reduced scale, altered commercial terms or duplicated capability. A fifth category, transformation, covers elective improvement beyond minimum independence.

The categories have different deal consequences. Stand-up spend may affect price, completion funding or buyer returns. Recurring standalone cost affects maintainable earnings and valuation. Seller stranded cost affects the seller's retained-business case and can influence negotiation behaviour. Dis-synergy affects both parties according to contract, volume and operating model. Transformation belongs in the value-creation plan unless the current architecture makes it necessary for safe separation.

The cost model should use quantities and rates rather than a single percentage. Examples include applications to replace, interfaces to rebuild, users to provision, data stores to migrate, vendors to contract, roles to hire, months of dual running and tests to complete. The rate card should show internal labour, external delivery, licence, infrastructure, contingency and tax treatment separately. Each estimate needs an evidence grade and named assumption owner.

Costs should be timed by cash requirement. Some payments arise before completion, others on Day 1, during migration or at TSA exit. Deposits, annual licence prepayments, implementation milestones and parallel-run costs can create a cash profile that differs from expense recognition. The investment committee should see both the total cost and the peak funding requirement.

4. Build a bottom-up stand-up cost model

Consider a hypothetical UK business with 500 employees, GBP 100 million of annual revenue, 65 applications, three cloud environments, 28 material interfaces and 24 critical third-party agreements. It currently consumes finance, payroll, identity, cyber monitoring, procurement and data-platform services from its parent. The figures below illustrate modelling mechanics only.

The hypothetical one-time stand-up estimate is GBP 16.9 million. Application and infrastructure work contributes GBP 5.0 million; identity and cyber GBP 2.2 million; data separation GBP 2.1 million; finance and corporate functions GBP 1.8 million; people and change GBP 1.4 million; vendor and licence transition GBP 1.2 million; premises and network GBP 0.8 million; programme governance GBP 1.0 million; and contingency GBP 1.4 million. The estimate assumes several systems are replaced with standard services, while the core product platform transfers.

This model is sensitive to perimeter changes. If five shared engineering tools require replacement rather than tenant separation, delivery and dual-running cost increases. If customer consents delay data migration, the TSA period extends. If a group software agreement cannot be replicated on comparable terms, annual standalone cost increases. If finance requires a new enterprise platform rather than a managed service, both timing and implementation risk change.

The model should include an exclusion log. Cyber remediation, product redesign, international expansion and data-platform modernisation may be valuable, while they should not enter the minimum stand-up estimate unless independence or control requires them. An understated base case and a hidden transformation plan are equally unhelpful. The distinction should be explicit.

Table 2. Hypothetical stand-up cost model

Values are illustrative modelling assumptions in GBP millions; they are not market benchmarks.

Values are illustrative assumptions; the chart separates buyer stand-up cost, recurring cost and seller stranded cost.

5. Reconstruct recurring standalone cost

The buyer needs a post-exit operating model, not a gross-up of seller allocations. Group charges may include services the business does not need, omit specialist support provided informally, or reflect favourable enterprise pricing that cannot be replicated. The analysis should rebuild each function from required activities, service levels, staffing, suppliers and control obligations.

Recurring cost starts with the target operating model. Finance needs transaction processing, control, tax, treasury, management reporting and statutory reporting. Technology needs service ownership, architecture, operations, security, data, engineering tools and vendor management. People operations need payroll, benefits, recruitment, learning and employee relations. Procurement, legal, insurance, facilities and governance require similar activity-based design.

The hypothetical business adds GBP 5.4 million of annual recurring cost after TSA exit. It replaces parent allocations of GBP 3.0 million with independent services costing GBP 8.4 million. The GBP 5.4 million difference is a standalone uplift, not automatically a synergy loss. Some of the new cost buys control and service capacity that the carved business previously received from group functions.

Recurring cost should be reconciled to headcount, contract and consumption. A security operations service requires a defined asset count, log volume, coverage window and response scope. A cloud platform requires workload, storage, network and support assumptions. A finance managed service requires transaction volume, entity count and close timetable. Unit drivers improve negotiation and later cost control.

The EBITDA bridge should distinguish current allocations, services received without allocation, services no longer required, pricing changes, new control roles and scale effects. Sensitivities should show earlier or later TSA exit, higher cloud consumption, different support coverage and recruitment delay. The valuation case should use the model that the buyer can actually implement.

6. Treat seller stranded cost as a separate programme

The seller's retained organisation can carry cost after the carved revenue leaves. Shared teams may not reduce immediately. Enterprise licences may contain volume commitments. Offices, networks and platforms may be sized for the pre-transaction group. The seller needs its own removal plan and should avoid embedding stranded cost inside TSA pricing without clarity.

Stranded cost should be mapped to removal actions, timing and accountability. People cost may require redesign, consultation or redeployment. Technology cost may require contract repricing, environment decommissioning or consolidation. Facilities cost may depend on lease expiry or subletting. Supplier commitments may remain until renewal. Each action should show gross cost, avoidable amount, cash cost to remove and timing.

TSA charges should reflect the agreed commercial basis and service scope. A seller can price services at cost, cost plus margin or another negotiated method. The price should remain separate from the seller's internal stranded-cost recovery plan. Otherwise the buyer may fund costs unrelated to its consumption, and the seller may postpone the actions required to resize the retained business.

The stranded-cost bridge also improves deal comparability. A transaction can appear attractive on transferred EBITDA while leaving material cost behind. A retained-business case can overstate earnings if it assumes immediate cost removal without executable actions. The board should see transferred profit, buyer standalone profit and seller retained profit as three related views.

7. Make data separation a rights-and-controls programme

Data cannot be separated safely by copying folders and databases. The programme needs to establish what data exists, why it is processed, who controls it, which party may receive it, where it resides, which contracts and notices apply, how it relates to other records and when it should be deleted. The ICO states that a controller change in a merger or acquisition should be addressed through due diligence, including the data transferred, original purpose, lawful basis, transparency, documentation and security.[1]

The inventory should cover structured databases, object stores, source repositories, documents, logs, backups, analytics stores, model artefacts, support tickets, marketing systems, employee records and archives. Each dataset should link to system, owner, controller or processor role, data subjects, purpose, lawful basis, sensitivity, retention, location, recipients, contracts, encryption, access groups and migration decision.

The UK GDPR principles include lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, security and accountability.[2] Those principles shape the separation design. A dataset needed for one customer service should not automatically bring unrelated parent records. Historical data should be retained only for justified purposes. Accuracy and reconciliation matter because a partial or duplicated transfer can harm customers and weaken records.

International access needs separate analysis. The ICO's international-transfer guidance addresses restricted transfers, appropriate safeguards and transfer risk assessments, now referred to in legislation as data protection tests.[3] A buyer that changes hosting region, support location or group access may create a new transfer path. The migration plan should identify that path before data moves.

High-risk changes may require a data protection impact assessment. The ICO describes a DPIA as a process for assessing the impact of envisaged processing and requires one before processing likely to create high risk to individual rights and freedoms.[4] Legal advice should determine application to the specific transaction and target state.

Table 3. Data separation rights and controls matrix

The matrix links migration mechanics to lawful purpose, access and disposal evidence.

8. Design the migration around evidence gates

The migration roadmap should start with discovery and finish with provable separation. Discovery inventories stores, flows, interfaces, identities and legal conditions. Design establishes the target model, mapping, transformation rules, retention, access and rollback. Build creates target environments and repeatable pipelines. Rehearsal tests volume, duration, reconciliation, security and operational cutover. Execution moves controlled data. Closure removes access, resolves residuals and produces deletion or retention evidence.

Reconciliation should be defined before extraction. Customer records may reconcile by count, account status, balance and entitlement. Financial data may reconcile to control totals and ledger. Product records may reconcile by tenant, object and checksum. Identity data may reconcile by active user, role and privileged access. Logs may reconcile by period and event coverage. A single record count is rarely enough.

Data lineage should survive transformation. Each target field should link to its source, rule, version, exception and reviewer. Rejected records remain visible and owned. Manual fixes are recorded. This evidence supports operational confidence, regulatory accountability and later dispute resolution.

Security controls should operate during the migration, when temporary accounts, staging stores and elevated permissions can increase exposure. NCSC cloud guidance emphasises supply-chain understanding, secure identity, protected interfaces and auditable administration.[5]-[7] Migration identities should be time-bound and least-privileged; staging data should be encrypted and monitored; credentials should be separated; and logs should be preserved beyond the cutover window.

Backups require special treatment. NCSC guidance on ransomware-resistant backups recommends that backup solutions can be isolated and that privileged actions and significant changes create alerts.[8] A carve-out should determine who owns each backup, who holds keys, which datasets are commingled, whether independent restoration works and when the seller can remove the buyer's data.

Exit requires reconciliation, independent restore, access revocation and residual-data evidence.

9. Separate identity, privileged access and secrets first

Shared identity is a hidden dependency across almost every technology service. Employees, contractors, service accounts, customers and machines may authenticate through the seller's directory. Applications may inherit group policies, certificates, keys and privileged roles. A buyer can receive the application and data while remaining dependent on seller-controlled identity.

The identity plan should map every human and machine identity to an owner, purpose, privilege, authentication method, environment and target state. It should distinguish workforce identity, customer identity, privileged administration, service accounts, API credentials, certificates and cryptographic keys. Each type has a different migration and revocation path.

NCSC cloud principles state that access to service interfaces should be constrained to securely authenticated and authorised identities, including human and machine users.[5] Its secure-administration guidance highlights tiered privilege, just-in-time and just-enough administration, protected interfaces and detailed audit records.[7] These principles support a clean break between seller and buyer control planes.

The sequence should avoid orphaning critical services. Target identities and roles are created and tested. Applications are configured to trust the new identity source. Service accounts and secrets rotate through controlled automation. Privileged access is transferred with named owners and emergency procedures. Seller accounts are disabled after acceptance, and logs confirm that residual access has ended.

Customer identity may require a different cutover. Password hashes, multi-factor settings, consent records, federation relationships and identity-provider contracts need review. The programme should test login, recovery, support and fraud monitoring at realistic scale. A technically successful user copy can still fail if customers cannot reset credentials or support teams cannot verify them.

10. Establish intellectual-property and licence independence

Technology value often depends on rights that do not follow the servers. Source code, databases, patents, trade marks, domains, models, documentation, open-source components and know-how may have different owners and licences. Shared development can produce code contributed by group employees or contractors outside the carved entity. The rights perimeter should therefore follow each product component.

The Intellectual Property Office explains that intellectual property can be bought, sold or licensed and that licensing grants permission to use rights without transferring ownership.[15] Government knowledge-asset guidance distinguishes assignment, which transfers ownership, from licensing, which grants use under agreed terms; it also identifies software, datasets and know-how as licensable assets.[16] The transaction should specify the chosen mechanism for each material right.

The code review should map repositories, branches, build tools, dependencies, artefact stores, secrets, contributor agreements and licences. The target must be able to reproduce a release from its own environment. A successful source transfer without the build pipeline, signing keys, test data or deployment permissions does not create practical control.

Third-party licences should be tested for entity, territory, user, processor, affiliate and change-of-control restrictions. Enterprise agreements may cover group companies without permitting a separated buyer. Open-source obligations should be recorded by component and distribution model. Vendor consent and replacement timing belong in the critical path.

Table 4. Intellectual-property and vendor consent register

Operational control requires ownership or enforceable use rights plus a reproducible delivery chain.

11. Design the TSA as a declining operating bridge

A transitional services agreement should describe temporary services that permit safe continuity while the buyer builds or transfers independent capability. It should not conceal an undefined operating model. Every service needs a start state, service boundary, users, volume assumption, service measure, dependency, charge, security model, exit deliverable and final date.

The TSA catalogue should be built from the perimeter register. Typical technology services include identity, connectivity, hosting, service desk, security monitoring, backup, engineering tools, enterprise applications, data feeds and vendor administration. Corporate services may include finance, payroll, procurement, tax, treasury, insurance and facilities. Each service should map to the buyer workstream that removes the dependency.

Service measures should fit the temporary purpose. Availability, response, recovery, transaction cut-off, payroll accuracy, batch completion, access-request timing and incident notification may matter. The agreement should state how service is measured, which exclusions apply, how severity is classified and what happens when the seller changes the underlying platform.

Capacity assumptions prevent disputes. User count, transaction volume, storage, network, support hours, environments and change requests should be baselined. The agreement needs a process for volume variance, emergency change and new regulatory or security requirements. A static fee with undefined consumption can misprice both parties' obligations.

Security and data terms should identify controller and processor roles, permitted access, logging, incident handling, sub-processors, international access, retention and termination. The buyer should receive the audit information needed to monitor its services and investigate events. The seller should limit access to what service delivery requires.

Each service declines through readiness, migration, acceptance and termination gates.

12. Price and govern TSA exit risk

The TSA fee should be reconciled to scope, volume and change. One-time setup, recurring service, pass-through vendor cost, project change and exit assistance should be separated. Taxes and foreign-exchange treatment should be confirmed. The buyer needs a forecast of monthly cash by service and a sensitivity for extension.

Extension rights should be bounded. A buyer may need limited protection against a delay outside its reasonable control, while an automatic extension can reduce urgency. The agreement can use notice periods, stepped pricing, maximum extensions and service-specific conditions. The programme should monitor the latest responsible exit date as well as the contractual end date.

Exit criteria should be objective. A replacement service is ready when target infrastructure exists, data reconciles, access works, controls operate, users are trained, recovery has been tested, support ownership is accepted and residual seller access can be revoked. A project manager's percentage-complete estimate is not enough.

Change governance requires both transaction and operational authority. The seller may need to patch, upgrade or retire shared platforms. The buyer may request configuration, access or volume changes. A joint control forum should assess service, security, cost, timing and exit impact. Urgent incident action should remain possible under a defined emergency process.

Dispute and escalation design should protect continuity. Operational teams need named contacts and response times. Commercial escalation should distinguish service failure, scope dispute, buyer-caused delay and seller-caused delay. Remedies may include service credits, priority action or documented extension, subject to negotiated legal advice.

Table 5. TSA service schedule and exit control

The schedule is illustrative and should be adapted to the transaction and negotiated agreement.

13. Protect competition-law separation before control passes

Pre-completion planning should remain separate from pre-completion control. The parties need information to price the transaction and plan continuity, while competitively sensitive information and operational decisions require safeguards. Legal advisers should define clean-team membership, permitted datasets, aggregation, access, retention and decision boundaries.

CMA interim-measures guidance states that pre-emptive action can extend beyond integration of business functions and systems to closer collaboration or steps that undermine either business's independent competitive capability.[18] The guidance also explains that the CMA may require unwinding where integration has occurred. The separation programme should therefore record which actions are planning, which are reversible preparation and which require completion.

Customer-level pricing, pipeline, product roadmap and supplier terms may need restricted treatment. Clean teams can analyse information under defined protocols and provide aggregated conclusions to commercial decision-makers. Systems access should follow the protocol, and logs should show who viewed which data.

The buyer should avoid directing seller operations before legal control. It can identify Day 1 requirements, prepare its own infrastructure, draft communications and test migration tooling using permitted data. Decisions affecting current customers, staff, pricing, products or suppliers remain subject to the agreed legal boundary.

Some UK technology acquisitions may also require analysis under the National Security and Investment Act. Government guidance identifies 17 sensitive areas, including artificial intelligence, communications, computing hardware, cryptographic authentication, data infrastructure and quantum technologies, subject to detailed criteria.[19] Transaction counsel should assess whether notification or conditions affect the timetable and separation design.

14. Stand up people, payroll, tax and corporate controls

Operational independence includes the routine obligations that receive less attention than systems. The buyer needs a legal entity, bank accounts, payment authority, payroll, pension arrangements, tax registrations, insurance, accounting records, procurement authority, policies, delegations and a reporting calendar. Each must be ready for the first event, not only configured in principle.

Companies House guidance describes incorporation requirements and current registration services.[20] HMRC states that an employer should register, choose payroll software, collect records, report employees and make deductions, with reporting on or before the first payday.[21] The Pensions Regulator states that employer automatic-enrolment duties begin when the first member of staff starts.[22] These external dependencies should appear in the Day 1 plan with realistic lead times and owners.

TUPE planning should link employee allocation to systems and knowledge. GOV.UK explains that transferred employment contracts can carry terms, holiday entitlement, continuous employment and collective agreements, subject to the specific legal facts.[10] The seller must provide prescribed employee information within the applicable timetable.[11] Consultation, communications, benefits, payroll data, pensions and access changes should be coordinated.

Tax treatment requires early analysis. HMRC states that transfer-of-going-concern rules are mandatory when conditions apply and that the buyer's intention and VAT status can be relevant.[13] A carve-out may involve asset transfers, shares, contracts, property and staged completion; specialist tax advice should determine the treatment and data needed.

First close is a critical acceptance test. The standalone business should process opening balances, revenue, payroll, payables, receivables, cash, tax, consolidations and management reporting through its target controls. Parallel close or an early mock close can reveal mapping, cut-off, intercompany and access failures before the first statutory deadline.

15. Use operational resilience to define Day 1

Day 1 readiness should be anchored in business services. A business can have every project workstream marked green and still fail if one customer service crosses several incomplete dependencies. The readiness model should therefore map people, process, technology, facilities, information and third parties to each material service.

The FCA's operational-resilience guidance for firms in scope requires identification of important business services, impact tolerances, resource mapping, scenario testing and remediation of vulnerabilities.[17] Its 2026 observations emphasise mapping beyond technology to people, processes, information, facilities and third parties. Even where the target is outside those rules, this service-based method is useful for carve-out governance.

Each service should have a maximum tolerable outage or failure condition determined by management and specialist advice. The programme then tests the Day 1 architecture against scenarios such as seller identity unavailability, delayed data feed, cloud-region failure, payroll error, vendor consent delay, cyber incident and migration rollback. The response should include customer communication and manual workarounds where safe.

Readiness evidence should be binary where possible. Accounts are provisioned and tested. Interfaces complete an end-to-end transaction. Backups restore. Monitoring alerts reach the new team. Payroll reconciles. Customer support can authenticate users. Finance closes a mock period. Legal and regulatory conditions are satisfied. Open issues show impact, owner, workaround, deadline and approval.

Scores are illustrative management assumptions; a production gate requires transaction-specific evidence and approval.

16. Apply a gated standalone-readiness score

A readiness score can discipline reporting when its inputs are evidence-based. The score should combine outcome, control and exit criteria rather than project activity. Domains may include customer continuity, people, applications, identity, data, cyber recovery, finance, contracts and TSA exit. Each domain receives defined tests and evidence.

The hypothetical scores in Figure 5 average 77. The average is insufficient for approval because cyber recovery scores 69 and TSA exit readiness 62. A weighted average can hide a single failure that prevents safe operation. The model therefore uses red-line gates alongside the score. No-go conditions might include inability to authenticate customers, complete payroll, restore critical data, process cash, maintain regulatory permission or revoke seller privileged access.

Evidence quality should affect the score. A control observed in a design document receives less confidence than a control that passed an end-to-end test. A buyer claim without seller confirmation may remain provisional. A test performed on a small data sample may require volume rehearsal. The scoring record should state evidence date, environment, reviewer and exceptions.

Management should approve exceptions explicitly. An open issue can pass with a tested workaround, named owner, expiry and residual-risk approval. A generic statement that the issue is manageable provides weak governance. The exception register should feed the completion agenda, TSA schedule and 100-day plan.

Table 6. Standalone readiness gates

Gate design is illustrative; legal, regulatory and management requirements govern a specific transaction.

17. Translate diligence into price and transaction protection

The separation model should influence the deal before documents are final. One-time stand-up spend, recurring standalone cost and dis-synergy affect value differently. Unsupported assumptions should appear as sensitivities or conditions rather than disappearing into a blended adjustment.

Price analysis may include a recurring earnings adjustment for verified standalone cost, a one-time cash deduction or funded budget for necessary stand-up work, and scenario sensitivities for consent, timing and cloud consumption. Accounting and valuation specialists should determine the appropriate treatment. The model should avoid double counting the same item in EBITDA, net debt, working capital and one-time cost.

Contractual mechanisms may address asset and IP transfer, data rights, employee information, vendor consent, access, cooperation, leakage, warranties, indemnities, conditions, completion deliverables, TSA scope and post-close assistance. The right mechanism depends on legal advice and evidence. An operational problem should be expressed in the document as a measurable obligation or accepted risk.

The cost model needs a change-control rule through signing and completion. Perimeter discovery can reveal additional shared applications, data stores or licences. New findings should update cost, schedule, TSA and acceptance criteria through one governed record. Otherwise the model, programme and legal documents diverge.

The investment committee should receive a separation bridge alongside the valuation case. It should show current reported earnings, allocation adjustments, standalone cost, stranded-cost treatment, stand-up spend, optional transformation, timing, peak cash, confidence and downside scenarios. Each material line should link to the perimeter register and source evidence.

18. Govern the programme through exit, not completion

Completion is the start of execution for services that remain under TSA. The programme should retain one integrated plan across business services, workstreams, data migrations, vendor consents, people moves, TSA exits, finance close and control testing. Separate project plans need a common dependency model.

Governance should distinguish decision rights. The deal executive owns transaction outcomes. Business service owners approve continuity and acceptance. Workstream leads deliver capability. Legal, tax, employment, privacy, cyber and regulatory specialists approve within their domains. The programme office maintains the integrated baseline, evidence and changes.

The control room should monitor readiness, cost, TSA consumption, exit milestones, incidents, data exceptions, vendor consents, recruitment, seller actions and decisions. Measures should show outcome and trend. A count of completed tasks can coexist with a delayed critical exit. Reporting should highlight the dependency that determines the latest responsible action.

TSA exit should include a closure certificate by service. The buyer confirms target service, data, knowledge, control and recovery. The seller confirms deliverables, access removal, residual data treatment and termination. Financial teams close charges and pass-through costs. Security teams preserve audit evidence. Unresolved claims remain recorded without extending unnecessary access.

Benefits should be measured after independence. The recurring-cost model becomes a budget with unit drivers. Optional transformation is governed separately. Revenue continuity, service performance, customer retention, cloud consumption, staffing and control outcomes should be compared with the underwritten case. This closes the loop from diligence to value creation.

Conclusion

A UK technology carve-out succeeds when the transferred business can meet customer promises, control its people and systems, use its data lawfully, produce reliable accounts and exit seller dependence on tested terms. The separation perimeter should therefore follow the service-to-cash chain rather than stop at legal ownership.

The economic model should distinguish one-time stand-up spend, recurring standalone cost, seller stranded cost, dis-synergy and transformation. A bottom-up quantity-and-rate model creates clearer ownership and sensitivity than a broad percentage allowance. The buyer can then connect each cost to a build, buy, transfer, duplicate, replace or TSA decision.

Data separation requires rights, purpose, minimisation, security, lineage, reconciliation, access removal and disposal evidence. Identity, privileged access, secrets, source code, vendor licences and recovery must be separated as operating controls. A migration is complete when the business and its evidence agree.

The TSA should decline toward service-specific exit outcomes. Scope, measures, capacity, security, charges, change and termination should be explicit. Readiness scoring can support governance when red-line gates prevent an average from hiding a critical failure.

The resulting framework gives transaction teams a practical path from diligence to price, protections and a controlled operating plan. Its value depends on current transaction evidence, specialist advice, tested acceptance and accountable decisions.

Appendix A. Minimum separation data request

1. Legal entity, asset, contract, licence, IP and consent schedules. 2. Product and customer-service maps from contract through cash collection. 3. Employee activity, role, allocation, access and knowledge-dependency records. 4. Application, infrastructure, identity, interface, environment and support inventories. 5. Data inventory with purpose, controller, location, recipients, retention and access. 6. Source-code repositories, build pipelines, artefact stores, signing keys and test suites. 7. Vendor agreements, enterprise pricing, usage, renewal, change-of-control and transfer terms. 8. Cyber architecture, privileged access, vulnerabilities, incidents, monitoring and recovery evidence. 9. Finance, payroll, tax, treasury, procurement, reporting and first-close requirements. 10. Parent allocations, unallocated services, service volumes and seller stranded-cost actions. 11. Proposed TSA services, baselines, service measures, charges, dependencies and exit dates. 12. Regulatory permissions, notifications, legal holds and transaction conditions.

Appendix B. Investment committee questions

1. Which customer service has the lowest readiness and why? 2. Which critical dependency remains under seller control on Day 1? 3. Which cost is recurring and therefore affects maintainable earnings? 4. Which one-time spend is required for independence rather than transformation? 5. Which seller stranded costs have executable removal actions? 6. Which data transfers require consent, notice, safeguards or a revised purpose assessment? 7. Can the buyer reproduce, deploy, monitor and recover the product independently? 8. Which vendor and IP rights remain subject to consent or replacement? 9. Which TSA service has the latest responsible exit action? 10. Which readiness condition is a no-go regardless of the average score? 11. Which price or protection mechanism addresses each material uncertainty? 12. What evidence will prove that seller access and residual data have been closed?

References

1. Information Commissioner's Office, Due diligence when sharing data following mergers and acquisitions, accessed 29 August 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/due-diligence/
2. Information Commissioner's Office, A guide to the data protection principles, updated 23 March 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/
3. Information Commissioner's Office, International transfers, accessed 29 August 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/
4. Information Commissioner's Office, Data Protection Impact Assessments, accessed 29 August 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
5. National Cyber Security Centre, The cloud security principles, accessed 29 August 2026. https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles
6. National Cyber Security Centre, Cloud security principle 8: Supply chain security, reviewed 7 June 2023. https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-8-supply-chain-security
7. National Cyber Security Centre, Cloud security principle 12: Secure service administration and principle 13: Audit information and alerting for customers, reviewed 7 June 2023. https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-12-secure-service-administration ; https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-13-audit-information-and-alerting-for-customers
8. National Cyber Security Centre, Principles for ransomware-resistant on-premises backups, accessed 29 August 2026. https://www.ncsc.gov.uk/collection/ransomware-resistant-backups/principles-for-ransomware-resistant-on-premises-backups
9. GOV.UK, Business transfers, takeovers and TUPE: Overview, accessed 29 August 2026. https://www.gov.uk/transfers-takeovers
10. GOV.UK, Business transfers, takeovers and TUPE: Transfers of employment contracts, accessed 29 August 2026. https://www.gov.uk/transfers-takeovers/transfers-of-employment-contracts
11. GOV.UK, Business transfers, takeovers and TUPE: Information about employees during transfers, accessed 29 August 2026. https://www.gov.uk/transfers-takeovers/information-about-employees-during-transfers
12. Acas, What a TUPE transfer is, accessed 29 August 2026. https://www.acas.org.uk/tupe/advice-for-employers-and-employees
13. HM Revenue & Customs, Transfer a business as a going concern, VAT Notice 700/9, updated 23 May 2025. https://www.gov.uk/guidance/transfer-a-business-as-a-going-concern-and-vat-notice-7009
14. HM Revenue & Customs, VTOGC3300: transfer of contracts and novation, accessed 29 August 2026. https://www.gov.uk/hmrc-internal-manuals/vat-transfer-of-a-going-concern/vtogc3300
15. Intellectual Property Office, Licensing intellectual property, updated 1 April 2026. https://www.gov.uk/guidance/licensing-intellectual-property
16. Government Office for Technology Transfer, KAM Guide: IP in agreements, updated August 2026. https://www.gov.uk/government/publications/knowledge-asset-management-kam-hub/kam-guide-ip-in-agreements
17. Financial Conduct Authority, Operational resilience and Operational resilience: insights and observations one year on, updated 14 July 2026 and 27 March 2026. https://www.fca.org.uk/firms/operational-resilience ; https://www.fca.org.uk/publications/good-and-poor-practice/operational-resilience-insights-observations-one-year
18. Competition and Markets Authority, Interim measures in merger investigations, CMA108, December 2021. https://assets.publishing.service.gov.uk/media/606d7f2ee90e074e494f4ff8/Interim_Measures_in_Merger_Investigations__CMA108__clean.pdf
19. GOV.UK, National Security and Investment Act: details of the 17 types of notifiable acquisitions, accessed 29 August 2026. https://www.gov.uk/government/publications/national-security-and-investment-act-guidance-on-notifiable-acquisitions/national-security-and-investment-act-guidance-on-notifiable-acquisitions
20. Companies House, Incorporation and names, updated July 2026. https://www.gov.uk/government/publications/incorporation-and-names/incorporation-and-names
21. HM Revenue & Customs, PAYE and payroll for employers: Setting up payroll, accessed 29 August 2026. https://www.gov.uk/paye-for-employers/setting-up-payroll
22. The Pensions Regulator, What is automatic enrolment, accessed 29 August 2026. https://www.thepensionsregulator.gov.uk/en/employers/what-is-automatic-enrolment-video-script