Transaction execution
Closing the deal is the midpoint, not the end. The weeks that follow determine whether value leaks through forgotten accounts, orphaned systems and transition services agreements that drag on because nobody can execute the technical separation. We do the hands on work of moving domains, DNS, email, cloud accounts, payment processors, phone numbers and code repositories out of seller control and into the buyer's own infrastructure. This page describes how that work gets done, what breaks along the way, and where the real risk sits.
A business changes hands at signing, but its technology stack does not. Seller controlled accounts, shared cloud tenants, corporate email on a parent domain, payment gateways tied to a treasury system that was not part of the sale, phone numbers on a carrier contract the seller still owns. These dependencies are documented in a transition services agreement that sets a deadline for separation. The deadline is always shorter than the work requires. The seller's IT team, if it remains at all, is focused on the retained business. The buyer's operating team owns the clock.
The work splits into three streams that run in parallel. First, inventory and access. You cannot migrate what you cannot list, and you cannot list what you cannot log into. We map every account, subscription, domain registration, DNS zone, TLS certificate, code repository, third party API key and payment method tied to the acquired entity. Second, migration and cutover. Domains move to a buyer controlled registrar. Email moves to a new tenant with fresh authentication. Cloud resources fork into buyer owned accounts. Phone numbers port. Code repos transfer. Third, decommissioning and verification. Seller access is revoked, shared credentials are rotated, and every service is tested from outside the new perimeter.
The failure modes are predictable because they happen on most deals. An account nobody can access because the administrator left at close and the recovery email points to a former employee's inbox. A domain still on a seller credit card that expires in sixty days. A payment gateway whose API keys were hard coded into a script that runs on a server nobody documented. A TLS certificate that will expire and take the customer portal offline because nobody set up monitoring. The work is not glamorous. It is detail work done under time pressure with incomplete information. That is the standard condition, not an exception.
Before anything moves, you need a complete asset register. Most deals close with a partial one. The seller provides a list of domains and major systems, but the list misses the long tail: the monitoring service that sends alerts to a distribution group on the seller's Exchange server, the analytics account created by a marketing manager three years ago, the GitHub organisation owned by a personal account, the backup MX record that still routes mail through the seller's spam filter.
We build the register from the ground up, not from the seller's handover document. We interrogate DNS for every zone that references the acquired entity's domains. We scan certificate transparency logs for issued certificates. We trace MX records, SPF includes, DKIM selectors. We map cloud accounts by following IAM roles and cross account trusts. We inventory payment methods by pulling billing data from every service we can access and flagging the ones we cannot. The output is a structured asset register with ownership, access status, renewal dates and migration priority.
This phase surfaces the accounts that will block separation. A domain registered through a reseller that requires a login nobody has. A Google Workspace tenant whose super admin account was deleted. An AWS root account tied to an email address on a domain the seller already decommissioned. We classify each asset by recoverability and work with the seller's IT team, the client's counsel and the registrars and vendors directly to regain control. Some recoveries take days. Some take weeks and require notarised letters to a registrar's legal department. We have done enough of them to know which vendors respond and which ones stall.
Domain transfers are the highest risk cutover in any post close separation. Get it wrong and email stops. Customers cannot reach support. Inbound leads bounce. Password reset emails fail. The business goes dark in a way that is immediately visible to the market. The technical steps are well understood: unlock the domain at the losing registrar, obtain the auth code, initiate the transfer at the gaining registrar, approve it, wait five to seven days. The risk is not in the steps. It is in the dependencies nobody documented.
DNS is a graph, not a list. A domain hosts records that point to services the business depends on, and those services often depend on other domains the seller controls. An SPF record includes a mechanism that references a sender domain the seller will decommission. A CNAME points to a load balancer in the seller's AWS account. An NS record delegates a subdomain to a DNS provider the seller's networking team configured and forgot about. We map the full dependency graph before we touch a single record. We lower TTLs days in advance. We stage the target zone and validate it with dig queries against the new nameservers before cutting over the delegation.
Email cutover is the hardest sub problem. The business has been sending mail from the seller's infrastructure, building sender reputation on the seller's IPs and domains. Moving to new infrastructure resets that reputation. We warm the new sending infrastructure before cutover, starting with low volume and ramping over weeks. We configure SPF, DKIM and DMARC on the new domains and monitor delivery and spam placement. We route replies to the right humans. We maintain the old mail infrastructure in a forwarding state until we are confident the new setup is stable. The process is methodical because the cost of getting it wrong is silence.
Cloud accounts are rarely cleanly separable. The acquired business often runs in a shared VPC, in a sub account of the seller's organisation, or on resources tagged to a cost centre that spans both retained and divested operations. Separating them means forking infrastructure, replicating data, re establishing network connectivity and cutting over without downtime. The work is different for every cloud provider and every architecture, but the pattern is consistent: inventory, replicate, test, cut over, verify, decommission.
We start by mapping every resource the acquired entity uses. Compute instances, databases, object storage buckets, load balancers, CDN distributions, IAM policies, security groups, VPC peering connections, VPN tunnels. We identify what can be replicated in the buyer's own cloud organisation and what must be rebuilt because it depends on seller shared services that are not transferring. We build the target environment, replicate data where the transfer agreement permits it, and test with a subdomain or a staging endpoint before cutting over production traffic.
The hard cases are the ones where the acquired business shares a database with the seller's retained operations, or where the application code hard codes references to seller owned resources. We have seen connection strings with IP addresses that belong to the seller's corporate network, authentication systems that redirect to a seller SSO provider, and logging pipelines that ship to a seller owned Splunk instance. Each one is a negotiation between the technical reality and the transition services agreement deadline. We surface the conflicts early so the operating team can make informed trade offs.
Phone numbers are easy to overlook and hard to recover. A business may have dozens or hundreds of numbers spread across carriers, resellers, VoIP providers and twinned mobile devices. Some are on a seller corporate account that also serves the retained business. Porting them out requires a letter of authorisation, a recent bill and a winning carrier willing to accept the port. The process takes days to weeks depending on the carriers involved and whether the numbers are local, toll free or international.
We inventory every number the acquired business uses: main lines, direct dials, support lines, sales lines, fax numbers, numbers printed on packaging and websites, numbers embedded in customer contracts. We identify the losing carrier for each, obtain the account details from the seller, prepare porting documentation and submit port requests in the correct order. Toll free numbers require a RespOrg change, which adds a layer of complexity. International numbers may not be portable at all, requiring a call forwarding arrangement during the transition period.
While ports are in progress, we set up call forwarding from the old numbers to temporary numbers on the buyer's system. We update website listings, email signatures, CRM records and customer facing documents. We test every number after porting to confirm it reaches the intended destination. The work is tedious and detail heavy. It is also the kind of work that, if neglected, means a top customer calls the old support line and reaches a confused employee in the seller's retained business.
Customers need to know what changed and what did not. A post close transition site answers the obvious questions: who owns the business now, where to send payments, how to reach support, whether contracts and pricing remain in force. We build and deploy these sites on a short timeline, often between signing and close, so they are live the day the deal is announced. The sites are simple, static, fast and hosted on infrastructure the buyer controls.
The content work is harder than the technical work. Legal and communications teams need to review every word. The seller may have contractual approval rights over customer communications. The message must be accurate, reassuring and compliant with the purchase agreement. We handle the technical build, deployment, TLS configuration and monitoring. We coordinate with the client's counsel and communications team on content, but we do not draft it and we do not provide legal review. That sits with the client's own licensed advisors.
Beyond the transition site, we set up the email flows for customer notification. We configure the sending infrastructure, warm the IPs and domains, set up SPF, DKIM and DMARC, and monitor delivery and bounce rates. We build the subscription management pages so customers can opt in or out. We route replies to the right team. The goal is that customers experience a professional, coherent transition, not a series of confusing emails from unfamiliar addresses.
A transition services agreement is a clock. It says the seller will provide email, hosting, network access or other services for a defined period, typically ninety to one hundred and eighty days. After that, the seller can shut them off. The operating team's job is to complete the separation before the deadline. Our job is to execute the technical work that makes separation possible, on a timeline that does not rely on the seller's goodwill past the contractual end date.
We build a workback schedule from the TSA expiry date. For each service the seller provides, we identify the technical dependencies, the migration steps, the testing required and the cutover window. We sequence the work so that services with the longest lead times start first. Domain transfers and phone number ports begin the week after close because they can take a month or more. Email cutover follows once the domains are under buyer control. Cloud separation runs in parallel.
The schedule always slips. A registrar takes three weeks to process a transfer because the seller's legal team is slow to provide documentation. A cloud migration hits a dependency on a seller maintained API that nobody documented. We track every dependency, flag every blockage and update the schedule weekly. The operating team needs to know which TSA deadlines are at risk and what it will cost to extend them. We give them that picture in plain terms, without padding.
Code is an asset like any other, but it is often the last one transferred and the easiest one to lose. Repositories sit in GitHub organisations, GitLab groups or Bitbucket workspaces that the seller controls. Some are private forks of open source projects with custom modifications. Some contain hard coded secrets that reference seller infrastructure. Some have commit histories that include code from the seller's retained business, raising IP contamination questions that the client's counsel needs to resolve.
We inventory every repository the acquired development team uses. We identify the owner, the access model, the CI/CD pipelines attached to it and the deployment targets. We clone, transfer or migrate repositories to the buyer's own version control system. We scan for hard coded secrets, seller internal URLs and references to seller infrastructure that will break after cutover. We do not make legal determinations about IP ownership. We flag the repositories that contain commingled code and let the client's counsel decide how to handle them.
The work extends beyond source code. We look for design files, database schemas, infrastructure as code templates, test suites, documentation wikis, issue trackers and project management boards. Anything the development team needs to keep building the product. We have seen deals where the only copy of the production database schema lived in a wiki the seller deleted thirty days after close. The operating team cannot prevent every loss, but they can make it a conscious decision rather than a surprise.
The technical work described on this page is data and systems analysis performed to support the client's own accountants and counsel. We are not a licensed professional services firm. We do not hold CPA licensure, we do not practice law and we issue no professional opinions of any kind. The conclusions drawn from our work, including any decisions about asset treatment, IP ownership, regulatory compliance or financial reporting, belong solely to the client's own licensed advisors. Our role is to surface the facts, organise the data and execute the technical migration.
In practice, this means we work alongside the client's deal team, their outside counsel, their accountants and their operating partners. We provide the asset registers, the dependency maps, the migration schedules and the cutover runbooks. We attend the weekly calls. We flag the risks. We do the hands on keyboard work. But when a question requires a legal or accounting determination, we stop and hand it to the people licensed to answer it. That division of labour keeps the work moving without crossing lines that should not be crossed.
This page is part of a broader set of services for private equity operating teams. Related work includes carve out technology separation for deals where the acquired entity must be disentangled from a larger corporate parent, technical due diligence for pre close systems and data room review, and back office automation for the processes that run the acquired business after transfer. Each service addresses a different phase of the deal lifecycle, but they share the same operating philosophy: do the work, document the facts, stay in your lane.
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 full separation usually takes between ninety and one hundred and eighty days, which is the standard duration of most transition services agreements. Domain transfers and phone number ports can take four to six weeks on their own, so those start immediately after close. Email cutover typically runs in month two. Cloud separation runs in parallel and can extend into month three or four depending on complexity. The schedule compresses when the TSA is shorter, but some steps, like domain transfers, are gated by registrar processing times that cannot be accelerated.
We escalate through the vendor's account recovery process, which usually requires proof of business ownership, a letter from the client's counsel and sometimes notarised documentation. The success rate depends on the vendor. Major registrars and cloud providers have formal recovery processes that work, though they can take weeks. Smaller vendors, resellers and platforms with minimal support are harder. In some cases the only path is to rebuild the service from scratch on new infrastructure. We flag these situations early so the operating team can weigh the cost of delay against the cost of rebuilding.
We scope the work in phases. The first phase is always inventory and assessment, which produces a fixed price based on the size of the acquired entity's technology footprint. That phase typically takes two to three weeks and delivers the asset register and a prioritised migration plan with cost estimates for each workstream. The client can then choose which workstreams we execute and which they handle internally or with other vendors. We do not ask for a large upfront commitment before we have shown the client exactly what needs to be done and what it will cost.
The seller's IT team has conflicting priorities. They are focused on the retained business and on meeting their TSA obligations with minimum distraction. They are not incentivised to go deep on the buyer's future needs. General IT services firms understand technology but not deal mechanics. They may not recognise the legal constraints in a purchase agreement or the urgency of a TSA deadline. We operate at the intersection of technology and transaction execution. We understand the deal context, we read the TSA, and we work to the timeline the deal demands.
Smaller deals have the same failure modes as large ones, just with fewer assets to lose. We offer a lighter engagement for smaller acquisitions: a focused inventory and cutover plan delivered in a week, followed by remote execution of the highest priority migrations. The client handles the rest with our runbooks. The cost scales down because the scope does. The alternative is leaving the separation to someone internally who has another full time job, which is how domains expire and email stops working six months after close.
Related
Next step
Post close technology transfer is detail work done under time pressure with incomplete information. The assets are scattered across vendors, accounts and former employees. The TSA clock is running. The seller's IT team is moving on. Our job is to bring order to that chaos: inventory every asset, map every dependency, execute every migration and verify every cutover before the deadline. We have done this work across twenty live properties, moving domains, email, cloud accounts, phone numbers and code repositories from seller control to buyer control. We know what breaks and we plan for it. If your operating team is staring at a TSA expiry date and a list of assets that still need to move, we can help.
Start a conversation