A TSA exit is planned backward from the end date, one service at a time.
Standing up systems after a carve-out means replacing every service the former parent still provides under the transition services agreement before those services end. The work follows a clear order: inventory what the parent provides, decide what to buy and what to build, migrate data out, run the new and old systems side by side until results match, then cut over in a sequence that keeps the business operating.
The deal sets the TSA end date, and that date drives everything. Plan backward from it, leaving room for parallel running and for problems discovered late. Extensions are sometimes possible but awkward to negotiate, and they keep the new company dependent on a parent whose priorities have moved on. The plan should show which services are on track and which are at risk well before the date arrives.
A carve-out also differs from an ordinary system replacement because the business has never run these functions on its own. Processes the parent handled centrally, such as payroll, purchasing approvals, or IT support, may have nobody responsible for them in the new company. Part of the work is designing those processes for the first time, not only choosing software to run them.
Inventory everything the parent provides under the TSA.
Start with the TSA schedules, then go further. The agreement lists services, but the business also relies on things nobody wrote down: a shared network drive, a report the parent’s finance team runs monthly, an integration between the parent’s ERP and a supplier portal, or user accounts managed by the parent’s identity system. Interviews with each department will surface dependencies the schedules miss.
For each service, record what it does, which people and processes depend on it, what data it holds, and how it connects to other services. Group them into categories: finance and accounting, HR and payroll, IT infrastructure and identity, operations systems such as ERP and warehouse, customer-facing systems, and reporting. The dependencies between them will shape the order of replacement.
Pay particular attention to data. Confirm with counsel what the separation agreement says about which records transfer, in what format the parent will provide them, and which records are commingled with the parent’s other operations. Commingled records, such as shared customer masters or combined ledgers, usually need the most effort to separate cleanly, so identify them early and plan their extraction as a distinct task.
Decide which systems to replace with purchased products and which to build.
Most TSA services should be replaced with established products. Payroll, email, identity, accounting, and standard HR functions are well served by commercial software, and standing them up is configuration and data migration rather than development. Choosing products the team can implement and support without specialists reduces risk against a fixed end date, and it keeps attention on the pieces that are truly specific to the business.
Custom work is justified where the parent’s systems supported something distinctive: a pricing engine, a scheduling process, integrations with particular customers, or reporting the business depends on. It is also needed to connect the new products to each other, since separately purchased applications will not share customers, products, and financial codes on their own. Scope this work early, because it often sits on the critical path.
Avoid replicating the parent’s entire environment. An enterprise ERP sized for the parent may be far more than the carved-out business needs, and copying it keeps the complexity without the parent’s support staff. Use the separation to choose systems that fit the standalone company’s size and plan, and record the decisions so later add-ons can move onto the same standard.
Migrate the data out and run both systems until the numbers match.
Plan data migration as its own workstream. Extract the carved-out records from the parent’s systems, map them to the new systems’ structures, clean duplicates and inactive records, and load them into test environments first. Rehearse the migration more than once. Each rehearsal finds mapping errors and missing fields that would otherwise surface on the day the business starts depending on the new system.
Parallel running is the proof. For a period, process the same transactions in the parent’s system and the new one, then compare results: invoices, payroll, inventory balances, and the month-end financial statements. Differences point to mapping errors, configuration gaps, or process changes nobody documented. Only when the numbers match, or the remaining differences are understood and accepted, is the new system ready to take over.
Parallel running costs staff time, because people enter work twice or reconcile two outputs. Plan for it in staffing and in the TSA schedule, and keep the parallel period focused on the transactions that matter most, such as payroll, billing, and financial close. Cutting parallel running short to recover lost time is a frequent source of problems after cutover.
Cut over in an order that keeps the business operating.
Sequence cutovers by dependency and risk. Identity, email, and network access usually move first, because every other system relies on them. Finance and payroll follow, timed to period boundaries such as a month end or the start of a pay cycle. Operational systems that touch customers, such as ordering, scheduling, and warehouse management, typically move last, once the supporting systems are stable underneath them.
Avoid moving everything on one weekend. Staggered cutovers limit how much can go wrong at once and let the same team support each move. For each one, define the go or no-go criteria, the rollback plan, who is on call, and how customers and staff will be told. Keep read-only access to the parent’s system for a period where the TSA allows it.
Close the TSA formally: confirm each service is replaced, the transferred records have been received and verified, and the parent’s access to the new company’s systems is removed. Baybloom Software builds the custom systems and integrations that carve-outs often need alongside purchased products. Whoever carries out the work, a TSA exit goes best when it is planned against the deal’s date from the day the transaction closes.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project