Transaction support
A carve out looks clean on the term sheet. Inside the shared technology estate it is anything but. The unit you are buying has spent years woven into a parent's ERP tenant, CRM org, identity provider, email domains and licence bundles. Separating it without breaking the business or blowing the transition services agreement deadline is a systems problem with a hard clock. We do the technical work of untangling those dependencies, extracting only the data that belongs to the unit, and standing up the standalone environment. We do not advise on deal structure or valuation. We build and operate the separation itself.
Most mid market operating companies run on a set of shared platforms. A single ERP tenant serves multiple business units. A single CRM org holds sales data for every product line. One identity provider authenticates everyone. One set of email domains, one Microsoft or Google tenant, one network of shared drives and SharePoint sites. The parent company built this deliberately. It is cheaper to run and easier to govern. But it means the unit being carved out has no standalone technology footprint at all.
When the purchase agreement is signed, the clock on the transition services agreement starts. The TSA gives the buyer a fixed window to keep using the parent's systems while the separation is executed. That window is rarely generous. Every week of overrun costs money and goodwill. The work is not just technical. It is a sequencing problem. Some things can be cloned quickly. Others must be rebuilt from scratch because the shared tenant cannot be split. Knowing which is which before the TSA is drafted changes the negotiation.
We have built and operated twenty live properties through exactly this process. We have shipped two thousand six hundred and twenty five indexed pages across those properties, in sixteen languages, with five hundred and sixty seven mailboxes warmed daily across one hundred and sixteen sending domains. That infrastructure exists because carve outs need outbound capability from day one. The sales team cannot wait for a new domain to build reputation. We bring owned infrastructure that is already working.
The hardest part of most carve outs is the ERP. If the parent runs a single tenant with multiple legal entities, extracting one entity's transactional history, master data, open orders, payables and receivables is a data engineering exercise. You cannot simply copy the tenant. The parent's other businesses are in there. We identify every object that belongs to the carved out unit, write the extraction scripts, validate completeness against the source, and load the result into a new standalone instance. The same applies to CRM. A shared Salesforce org might hold a decade of activity across five divisions. We isolate the records for the unit being acquired, map the relationships that survive the split, and build the new org.
Some platforms make this straightforward. Others do not. We will tell you plainly when a system cannot be split and must be rebuilt. That is not a failure of execution. It is a fact about the architecture, and the sooner the buyer knows it the better the TSA can be structured. We have seen deals where the separation plan assumed a clean ERP clone that the system simply did not support. The workaround cost months. We surface those constraints during diligence so they are priced into the deal, not discovered after close.
The output is a functioning standalone environment. We operate it, we do not hand over a build document and walk away. Our eighty call centre agents, working US business hours from Egypt, can begin dialling qualified lists the day the new CRM is live. Dispositions are written back to the client's systems. The outbound motion does not pause for the carve out.
A carved out unit typically shares an email domain with the parent. The day after close, employees of the new entity cannot be logging into the parent's Microsoft or Google tenant. We stand up a new tenant, migrate mailboxes and drive data, and cut over the domain or establish a new one with forwarding from the old. The identity layer is equally critical. If the unit authenticates against the parent's Active Directory or Entra ID, we build the new identity provider, sync users and groups, and sever the trust before the TSA clock expires.
Shared single sign on integrations are a hidden risk. The unit's applications may authenticate through the parent's identity provider. Each of those integrations must be mapped, re pointed to the new identity provider, and tested. Some will be straightforward SAML or OIDC reconfigurations. Some will be custom integrations that require development work. We catalogue every integration during diligence and sequence the migration so that no application is left without an authentication path on cutover day.
Email deliverability matters from the first hour. A new domain has no sending reputation. We operate five hundred and sixty seven warmed mailboxes across one hundred and sixteen sending domains with per domain authentication and inbox placement monitoring. Replies are routed to humans. The new entity can send and receive email at volume from day one because the infrastructure is already live and trusted.
The parent company's licence agreements rarely transfer cleanly to a carved out entity. Microsoft Enterprise Agreements, Salesforce contracts, and other enterprise software deals are negotiated at the parent level with pricing based on total seat count across all business units. The carved out unit may represent a small fraction of those seats but a large fraction of the complexity if it runs specialised modules. We map every licence dependency, identify which agreements can be assigned to the new entity and which must be renegotiated, and build the cost model the buyer needs to budget for standalone operations.
Some contracts contain change of control provisions that trigger renegotiation or termination. We flag those during diligence so the buyer's counsel can address them. The technical work is understanding what software the unit actually uses, not what the parent's IT asset register says it uses. We find the shadow IT, the spreadsheets that run a department, the legacy application someone forgot to decommission. Those become the new entity's problem on day one and they need to be in the separation plan.
We do not provide legal advice on contract terms. We identify the technical dependencies and the operational impact of each licence decision. The client's own counsel determines the legal path. Our role is to make sure the technical facts are complete and accurate so that counsel can do their work on a solid foundation.
The parent company's reporting environment is almost always shared. A data warehouse that consolidates every business unit, a set of Power BI or Tableau dashboards that cross filter the entire enterprise, a budgeting and forecasting system that rolls up to group. The carved out unit needs its own reporting capability. We extract the unit's data from the parent's warehouse, build a new reporting instance, and recreate the essential reports and dashboards that the unit's management team relies on to run the business.
Some reports will need to be rebuilt because they depend on data from other business units that is not part of the transaction. Some will need to be simplified because the new entity does not have the same data engineering team the parent had. We design for what the standalone business can actually operate, not for what the parent's central IT department could support. That means choosing tools the new entity's team can maintain and building documentation that assumes a lean staff.
The data extraction itself requires care. We must identify only the data that belongs to the carved out unit. That is not always obvious. A customer record might be shared across units. A product hierarchy might span divisions. We trace the data lineage back to source systems and extract only what the unit owns. The client's own accountants and licensed advisors review the completeness and accuracy of the extraction. We provide the technical analysis and the data itself. We do not issue opinions on financial completeness or compliance. Those conclusions belong to the client's own licensed advisors.
The transition services agreement sets a deadline for every system separation. Those deadlines are not independent. Email cutover depends on identity being ready. CRM migration depends on ERP data being extracted. Reporting depends on both. We build a dependency map and sequence the work so that no team is blocked waiting for a predecessor task. The critical path is rarely what the deal team assumed. We find it and surface it.
Some separations can be done in parallel. A new email tenant can be stood up and warmed while the ERP extraction is still running. A new website can be built and indexed while the CRM migration is in progress. We have shipped two thousand six hundred and twenty five indexed pages across twenty live properties. That work does not wait for the back office systems to be ready. It runs in parallel so the new entity has a public presence the moment it needs one.
The TSA also covers services the parent will continue to provide during the transition. We treat those as a fixed window and plan the separation to complete before the window closes. If a system cannot be separated in the available time, we say so early. The buyer can then negotiate an extension or a different approach. Surprises after close are expensive. We eliminate them by testing the separation plan against the architecture before the deal is final.
A clone is possible when the system architecture supports multi tenancy or when the unit's data can be cleanly extracted and loaded into an identical instance. A new Microsoft tenant with migrated mailboxes is a clone. A new CRM org with extracted records is a clone. These are the fast workstreams. They can often be completed within the TSA window if the extraction logic is sound and the data is clean.
A rebuild is necessary when the shared system cannot be split. A single tenant ERP that does not support entity level extraction may require the unit's transactional history to be extracted and loaded into a different ERP altogether. That is a rebuild. A custom application built by the parent's internal team, with no export capability and no documentation, is a rebuild. We identify rebuilds during diligence and estimate the effort. The buyer can then decide whether to rebuild, replace with a commercial product, or negotiate a different separation approach with the seller.
The decision between clone and rebuild is not purely technical. It is a cost and time trade off against the TSA clock. A rebuild takes longer but may produce a better long term result. A clone is faster but may carry forward technical debt from the parent. We lay out the options with plain estimates of time and effort. The buyer makes the call. We execute whichever path is chosen.
Carve out technology separation is one workstream in a larger transaction. It sits alongside technical due diligence, which examines the target's systems before the deal is signed. It feeds into post close technology transfer, which handles the actual migration of systems and data to the buyer's environment after the separation is complete. And it depends on systems and data room review, which verifies that what the seller represented in the data room matches what is actually running in production.
We perform all four workstreams as a connected service. The findings from technical due diligence inform the separation plan. The separation plan defines what post close transfer must accomplish. The data room review catches discrepancies before they become post close disputes. This is not advisory work. We build the systems, operate the infrastructure, and run the processes. Our eighty call centre agents, our five hundred and sixty seven warmed mailboxes, our one hundred and sixteen sending domains, our sixteen languages in production are all live and working.
The client's deal team, accountants and counsel retain full control over conclusions, opinions and decisions. We provide the technical facts, the working systems and the operational execution. We do not hold professional licensure and we issue no professional opinions. The conclusions drawn from our work belong to the client's own licensed advisors.
A failed carve out separation is expensive in ways that do not appear on the deal model. The TSA overrun costs are the obvious ones. The parent charges for extended use of its systems, often at rates that rise steeply after the initial window. Less obvious is the operational damage. A sales team that cannot send email for a week loses pipeline. A finance team that cannot close the books because the ERP extraction was incomplete loses credibility with lenders and investors. A customer that cannot log in because single sign on was not migrated loses trust.
The harder cost is distraction. The operating partner who bought the business to improve it spends the first six months fighting technology fires instead of building value. The management team the partner installed spends its energy on workarounds instead of strategy. That is a cost no TSA extension can recover. The separation must work on day one, not eventually. That requires a plan that was tested against the architecture before the deal closed, not one that was written in the two weeks after.
We have built and operated twenty live properties through carve outs. We have learned what breaks and in what order. We bring that experience to the diligence phase so the separation plan is grounded in what the systems actually allow, not in what the deal team hopes they allow.
Lawless LLM is not a CPA firm, not an audit firm and not a law firm. We do not issue audit opinions and we do not provide legal, accounting, tax or investment advice. This work is data and systems analysis carried out to support your own licensed advisors, who remain responsible for the professional conclusions drawn from it.
Questions
The timeline depends on the number of systems, the complexity of the shared tenants and the length of the TSA window. Simple separations with a clean ERP extraction and a standard email migration can complete in ninety days. Complex separations involving multiple ERP instances, custom applications and cross border data transfers can take six months or more. We provide a timeline estimate during diligence based on the actual architecture, not on a generic assumption. The estimate includes the critical path and the dependencies that could cause delay.
We identify that risk during diligence, before the deal closes. The buyer has several options: negotiate a longer TSA window with the seller, narrow the scope of systems covered by the TSA to only the ones that are truly blocking, or accept a phased separation where some systems are cloned quickly and others are rebuilt over a longer period outside the TSA. We lay out the trade offs for each option. The earlier the constraint is known, the more leverage the buyer has in the negotiation.
Yes, when the ERP architecture supports entity level data extraction. We extract only the data that belongs to the carved out unit, validate completeness against the source, and load it into a new standalone instance. The parent's tenant is not modified. In cases where the ERP does not support clean extraction, we identify that constraint early and recommend a rebuild approach. The parent's systems remain intact throughout. We have performed this work across multiple ERP platforms and we understand the extraction capabilities and limitations of each.
We price the work as a fixed scope engagement with a clear statement of what is included and what is not. The cost depends on the number of systems, the complexity of the data extraction, the number of users and mailboxes to migrate, and the timeline. We provide a priced proposal after reviewing the target's architecture during diligence. There is no hourly billing and no open ended discovery phase. We define the scope, we price it, and we deliver against that scope. If the scope changes because new systems are discovered, we price the change separately.
A large systems integrator will sell you a methodology and a team of junior consultants learning on your deal. The parent's IT team has its own priorities and no incentive to make the separation fast or clean. We are a focused operating firm that has built and operated twenty live properties through carve outs. We own the infrastructure, we employ the agents, we run the mailboxes. We do not advise and hand off. We build and operate. Our work is priced for the mid market, not for enterprise transformation budgets. And we will tell you plainly when something cannot be done, which is more than most firms will offer.
Related
Next step
Carve out technology separation is a systems problem with a hard deadline. It rewards early planning, honest assessment of what the architecture allows, and execution that does not pause for the transaction. We bring the infrastructure, the experience of twenty live properties, and a team that builds and operates rather than advising and departing. If the separation plan is grounded in the actual systems, the new entity stands up on day one with email delivering, CRM running, ERP processing and the sales team dialling. If it is not, the TSA clock runs out while the buyer is still fighting fires. We make sure it is grounded. Contact zach@lawlessllm.com to discuss a specific carve out or to begin diligence on a target.
Start a conversation