Carve-out technology in one hundred days

A carve-out is the only kind of deal that arrives with a countdown printed on it. The transition services agreement says the seller will run payroll, email, the network, the enterprise resource planning system and a dozen other things for a stated number of months, at a stated price that usually rises after the first extension. On the day that agreement ends, the separated business either runs on its own systems or it does not run. Everything else in the deal thesis, including whatever analytics or AI the model assumed, sits behind that date. The technology program of a carve-out is therefore not a modernization project with a deadline. It is a separation program, and the difference in sequencing is what decides whether the business is standing at the end of it.

This is written for the person accountable for that program: an operating partner, a chief financial officer of a newly separated business, or a chief information officer hired into a company whose systems belong to somebody else. The work is knowable. What ruins carve-outs is not difficulty. It is discovering the dependencies in the wrong order.

Read the transition services agreement as an engineering document

The agreement was negotiated by deal teams under time pressure and is usually the most consequential technical specification in the transaction. Read it early, line by line, with engineers in the room, and produce three lists.

What the seller provides, by service, with its actual end date. Services often have different durations. Email might run twelve months and the enterprise resource planning system twenty-four, or the reverse. The binding date for planning is the earliest date on a service the business cannot operate without, not the headline term.

What the seller does not provide but the business assumed. This list is where carve-outs go wrong. Historical data extracts beyond a stated scope, a test environment, engineering support for a migration, access to a system's underlying database rather than its user interface, help with a customer integration the seller built years ago. If it is not written into the agreement, it is a negotiation, and negotiations after close are slower and more expensive than negotiations before it.

What the agreement costs by month, and what an extension costs. Extension pricing is usually stepped and punitive by design. That schedule is the real budget for the separation program, because every month saved is a month not paid. Put it on the same page as the build plan; it makes prioritization arguments end quickly.

One more reading task belongs here. Find every third-party contract the separated business depends on and determine whether it transfers, requires consent, or must be replaced. Software licenses, hosted platforms, data feeds, telecommunications, and the certificates and domains the business runs on. Consent processes have vendor-controlled timelines, which means they belong at the very front of the schedule regardless of their technical difficulty.

Identity is the first build and it is not close

Every other separation task depends on identity. Employees currently sign in with the seller's accounts. Those accounts authenticate email, file storage, the core systems, the network, and every hosted application the business uses. Until the separated company has its own directory, its own sign-in, its own device management and its own access model, nothing else can be cut over, because cutting over a system means pointing it at an identity provider that does not yet exist.

The work has a known shape. Stand up the company's own directory and sign-in. Establish groups and roles that reflect how the business actually works rather than a copy of the seller's structure, because a carve-out is the one moment when an access model can be designed correctly at almost no extra cost. Enroll devices under the company's own management. Migrate mailboxes and files with a dual-delivery window so nothing is lost in transition. Then re-point applications one at a time, in an order set by business criticality and by which ones have the fewest downstream dependencies.

Two details cause most of the pain and both are cheap to handle early. External-facing identifiers, meaning the domain, the certificates, the email addresses customers already have, and the sending reputation attached to them, need a migration plan of their own, because a mishandled domain cutover means customer email stops being delivered. And service accounts, meaning the non-human identities that integrations run under, are almost never documented anywhere. Find them by watching authentication logs before the cutover rather than by asking, because nobody knows the full list.

Data separation, which is harder than it is described

The deal documents say the separated business gets its data. What that means technically is rarely specified, and the gap between the legal statement and the engineering reality is where schedules break.

The shared systems hold records for both businesses, interleaved. Separating them requires a rule for every entity: which customers, orders, invoices, employees, products, contracts and history belong to the carved-out business. Those rules are business decisions, not technical ones, and they need an owner in finance and an owner in operations who will sign them. A shared customer that buys from both businesses is the case that will consume a disproportionate amount of the schedule; decide the treatment early and in writing.

Then the mechanics, which have a correct order.

Extract to a landing area the company controls, immutably, with the schema recorded. Take everything within scope early, even before the destination is decided. Extraction access is the thing the agreement grants and the thing that becomes hard to get later, so use it while it is easy. Store the raw extracts unchanged, dated, and never edit them in place.

Profile before you transform. Row counts, key uniqueness, referential integrity, null distributions, value domains, and the fields whose meaning differs from their name. Every carve-out finds a field being used for something other than its label, usually a code column repurposed years ago. Finding these during profiling is a note; finding them after cutover is an incident.

Decide what history actually comes across, and prove you can read it. Full history into the new core system is often neither possible nor necessary. A common and workable pattern is a defined recent window into the operational system and everything else into a queryable archive the company owns, with a documented path from an archived record to its meaning. The test is not whether the archive exists. It is whether a person can answer an auditor's question about a five-year-old transaction using it, and that test should be run before the agreement ends.

Reconcile at every step, to the seller's numbers, while the seller is still available. Balances, counts, and totals by period, agreed in writing. This is the single artifact that makes the first independent close possible, and the window to produce it closes when the agreement does.

Core systems, and the decision that sets the whole schedule

The largest question in a carve-out is whether to lift the seller's system configuration into an instance the company owns, or to implement a new system. The answer sets the schedule, the cost and the risk, and it is frequently decided by preference rather than by the constraints.

The constraint that should decide it is the calendar arithmetic, done honestly and early. Count backward from the earliest binding end date: cutover and stabilization, parallel running, user acceptance testing, at least two full data conversion rehearsals, build and configuration, and design. If that arithmetic does not fit, a new implementation is not an option regardless of how attractive it is, and the choice is between lifting and bridging. Doing this arithmetic in the first three weeks, rather than in month five when an implementation partner's plan arrives, is the highest-value hour in the program.

The integrations nobody has written down

Every established business runs on integrations that exist in nobody's inventory: a nightly file to a logistics provider, a customer's purchasing system that posts orders directly, a bank file, a tax engine, a spreadsheet with a database connection that a controller built and maintains. In a carve-out these break silently, because they authenticate with the seller's credentials or run on the seller's infrastructure.

Find them by observation rather than by interview. Network and authentication logs, scheduled job listings, database connection records, and outbound file transfer histories will surface integrations no one remembers. Then classify each one: does it transfer, must it be rebuilt, can it be retired. Customer-facing integrations get priority and get the longest lead time, because changing them requires the customer's own change process, and a customer who cannot submit an order is a revenue event rather than a technical one.

Reporting, and then the thing the thesis assumed

The separated business needs its own close, its own lender reporting and its own operating metrics, on its own data, by its first independent period end. This is where the reconciliation work above pays for itself. Build the reporting foundation during the separation rather than after it: the extracts already exist, the definitions are being decided anyway, and a warehouse with tested definitions costs far less when it is built alongside the migration than when it is retrofitted afterward.

The analytics or AI the deal model assumed comes after, and it should. It sits last in sequence and it is the reason the whole program exists in the investment committee's mind, which creates pressure to start it early. Resist that pressure with a plan that shows it starting on a date, because the work depends on the data being separated, defined and trustworthy. Started before that, it produces a demonstration on the seller's data that has to be rebuilt on the company's own. Started after, it takes a fraction of the time because the platform underneath it already exists.

How the program is run while the business keeps operating

The constraint that shapes everything is that the same finance and operations people who know the answers are also closing the books, serving customers and answering diligence questions. A separation program that requires forty hours a week from a controller will not get it.

• One dated plan, backward from the binding date, with a named owner per workstream. Identity, data, core systems, integrations, reporting, infrastructure and security, each with one person accountable on the company side and one engineering lead.
• A dependency map that is maintained, not drawn once. Carve-out schedules fail through dependencies rather than through effort. When a vendor consent slips two weeks, the map tells you within an hour which cutover moved and what it costs in agreement extension.
• Rehearsals, at least two, on production-scale data with the clock running. A conversion that has never been rehearsed at full volume has an unknown duration, and duration is what determines whether the cutover fits in a weekend.
• A written rollback for every cutover. Including the point of no return and who decides. Most cutovers do not need it. The one that does needs it to have been written calmly in advance.
• Business time protected and scheduled. Get the finance and operations decision-makers booked in advance for defined blocks, and bring them decisions rather than discovery. Engineers should arrive with the analysis done and a recommendation.
• Security designed in during separation. Access control, logging, backup and recovery that has been tested, and endpoint management. This is the one chance to establish them cleanly, and a buyer's diligence team will examine all four at the next transaction.
• A weekly one-page status with the binding dates and the extension cost. For the board. Keeping the extension cost visible on the same page as the plan is what keeps scope arguments short.

Failure modes we plan around

The plan is written forward from today instead of backward from the binding date. Forward plans always fit. Backward plans reveal in week two that a workstream cannot finish, which is when there is still time to change the approach.

Vendor consents start late. They are administrative and therefore feel low priority, and they have timelines nobody controls. Start them in the first fortnight.

The seller's cooperation is assumed rather than specified. The seller's team has been reassigned and their goodwill decays predictably. Anything needed from them should be in the agreement, scheduled early, and requested while the relationship is fresh.

The data extract is taken once and found insufficient later. Extract broadly and immutably at the beginning while access is easy. Storage is inexpensive compared with a renegotiated extract in month ten.

The AI initiative starts first because it is the most interesting. It then gets built on the seller's data, in the seller's environment, and has to be built again. Sequence it after the data is separated and it costs a fraction as much.

How we run a separation program

Precision Federal builds AI systems, data platforms, software, cloud infrastructure and full-stack applications and delivers them into production, including inside U.S. federal agencies, where identity, access control, logging, accessibility and recovery are set by the government and reviewed independently. Separation work is the same discipline applied under a deadline someone else set.

In the first two to three weeks our engineers produce five things. A read of the transition services agreement as a technical specification, with every service, its binding date and its extension cost. An observed inventory of systems, integrations, service accounts and third-party contracts, built from logs and job schedules rather than from interviews. A backward-dated plan from the earliest binding date, with the calendar arithmetic that says which core-system approach is actually available. A data separation design with the entity rules that finance and operations need to sign. And a written scope with acceptance criteria and a price for the first increment.

The build then runs in increments, with security, access control and accessibility inside them rather than after. Rehearsals are run at production scale. The company's own team performs the final cutover with our engineers alongside, which is also the handover: they have done it in rehearsal before they do it for real.

The company owns everything by present written assignment: source, infrastructure as code, pipelines, extracted data, archives, documentation and runbooks. Any pre-existing components we bring are named, carved out, and licensed perpetually to the company for use and maintenance of the delivered systems, including after a sale. Pricing is fixed-price milestones against written acceptance criteria, or a committed team for a defined period where the separation runs longer than a single scope.

The first step is one email with a one-page brief: the transition services agreement dates, the core systems by product and version, roughly what the business runs on, who can grant access, and who approves a scope change. We return a scoped, priced statement of work.

Bottom line

A carve-out is a dependency problem with a deadline attached. Read the transition services agreement as a technical specification and find the earliest binding date. Build identity first because everything else depends on it. Start vendor consents in the first fortnight since their timelines belong to someone else. Extract data broadly and immutably while access is easy, and reconcile to the seller's numbers while the seller is still there. Do the backward calendar arithmetic in week three, because it decides whether a new core system is even available. Build reporting alongside the separation, and put the analytics the thesis assumed last, where it costs least. A program run in that order finishes before the clock does.

Frequently asked questions