Post-Merger Integration for Mid-Market PE Portcos

Post-Merger Integration for Mid-Market PE Portcos

Post-merger integration for mid-market PE, buy-and-build, and family-office operators starts after close. The model assumed 90 days of stabilization and six months of integration. Then the plan drifts. The CEO knows the deal closed. The CFO knows the model. Engineering hits the TSA with no unwind or the ERP carve-out that cannot produce a report.

Tech is where the deal model dies. This hub is the 30/60/90 operator frame: what diligence missed, what day one has to produce, and how the same operator carries context through month six. For a named team that stays on the file, see the software development retainer for mid-market.

What's broken about the standard integration playbook

Three patterns we see repeatedly:

1. Diligence ends at close. The technology diligence findings, even good ones, get filed. Day one, the integration team is working from the operating model and the LOI, not from the diligence memo. Whatever the diligence flagged about knowledge concentration risk or TSA dependency doesn't make it into the first 30-day plan because nobody owns translating diligence findings into integration line items.

2. The integration plan is built in the financial model, not from the systems. The model says "consolidate to one ERP by Q3." The systems say "the seller's ERP is a 12-year-old customization on Microsoft Dynamics with a finance team of three people who've been hand-bridging eight separate spreadsheets to produce monthly close." Those don't reconcile. The model wins on paper for the first quarter, then loses to reality starting in month four.

3. The portco's engineering org is in survival mode. Whatever the existing engineering team was doing is now interrupted by integration work, layered on top, with no relief. The senior engineers who actually understand the systems get pulled into integration meetings and stop shipping. Knowledge concentration risk that diligence may have flagged becomes acute when one of those senior engineers leaves three months in.

The fix isn't a better diligence checklist. It's an operating model that connects diligence to day one to month six, with the same operator carrying context across the whole arc. We unpack each piece below.

The seven things that determine whether an integration ships

1. Day-one reporting risk

The single biggest under-discussed risk in mid-market integration. When the new owner asks for the first executive view, margin by segment, cash position, top customer concentration, the answer needs to be available on day one, not month four. If finance can't produce a clean view of the management numbers without spreadsheet bridges and tribal knowledge, every post-close decision gets slower.

We've covered this in depth in our Pre-Acquisition Technology Assessment for Day-One Reporting Risk guide. The takeaway for the integration phase: by close, you should know exactly which numbers are produced where, by whom, and what would have to change for the new owner to query them directly. If you don't, the first 30 days become a forensic accounting exercise instead of a value-creation exercise.

2. TSA dependency unwind

Transition Service Agreements are how carve-outs survive close. They're also where most integration timelines blow up. The TSA promises six months of seller-side support; the actual unwind takes nine to fifteen. Every day past the TSA expiry is leverage to the seller and risk to the buyer.

Our deep-dive on this pattern: Pre-Acquisition Technology Assessment for TSA Dependency Risk. For integration teams, the rule is: the day TSA negotiation closes, the unwind plan starts. Not the day the integration team gets stood up. Not the day the IT vendor is hired. The day the TSA terms are signed, somebody owns the unwind sequence by name and date.

3. ERP carve-out execution

The most expensive single integration line item is almost always the ERP. Whether the target is on a customized SAP, NetSuite, Microsoft Dynamics, or a homegrown stack, the carve-out runs through the systems that produce financial reporting, payroll, AR/AP, and inventory.

Most mid-market buyers underestimate the data engineering required to lift the carve-out's data model into the buyer's system. We wrote about this specifically in Pre-Acquisition Technology Assessment for ERP Carve-Out Risk. For the integration team, the practical question is: do you take the seller's ERP forward (cheap to start, expensive over time), migrate to the platform's standard (expensive to start, cheap to operate), or run dual systems with reconciliation (expensive both ways, but flexible). The right answer depends on the deal thesis, but the question has to be asked in week one, not month six.

4. Technical debt audit

Every target has technical debt. Most diligence reports list it. Few quantify the operating drag. The integration phase is when the difference becomes the line item.

We wrote about this in Technical Debt Management for Mid-Market. The frame for integration teams: classify debt by what it blocks, not by what it is. Technical debt that blocks a single product line is one priority. Technical debt that blocks the integration cutover is a different priority. Technical debt that's compliance exposure is a third. Three different classifications, three different remediation timelines, three different teams.

5. Knowledge concentration risk

The most common integration failure pattern: the senior engineer who knows how the seller's systems actually work leaves three months after close. Whatever was in their head is now gone. Documentation that diligence said was "adequate" turns out to cover the happy path only.

This risk should have been quantified in the CTO Assessment for PE Portfolio Companies phase. If it wasn't, the integration team's first 30 days have to include forced knowledge transfer, not because the senior engineer is leaving, but because they might. Pair-programming sessions, runbook authoring, system inventories with named owners.

6. Integration cost surprises

The model has a number for integration. The actual integration costs more. The line items that consistently get under-budgeted include data migration tooling, TSA extension fees, vendor consolidation transition costs, security remediation, and compliance bridge work. The finance and revenue section below splits the one-time reserve from the recurring drag.

The rule of thumb: add 30% to whatever the model says integration costs, then plan to spend the contingency. If the integration comes in at the original number, that's a sign the integration team scoped narrowly, which usually means a long tail of unbudgeted work shows up in months 9-15.

7. Integration timeline blowouts

Related but distinct: even when the cost estimate is right, the timeline almost always slips. The biggest single cause: dependencies between integration workstreams that weren't mapped at planning time. Finance can't close the new entity until IT cuts over the GL, but IT can't cut over the GL until HR finishes the org structure work, which is waiting on legal entity consolidation. The systems and cutover section below adds the capacity tax, the single-engineer dependency, and the cutover window.

The fix isn't a better Gantt chart. It's a weekly cross-workstream blocker review where every blocker has a named owner and a 7-day deadline to resolve or escalate.

The operating model that ships integrations

The best integrations in mid-market PE share three characteristics:

Same operator across every add-on. When a platform is doing 5-10 add-ons a year, the integration team that handled add-on #1 builds patterns. Add-on #4 should be cheaper than add-on #2. Add-on #8 should be predictable. This only works if the same senior operator carries context across every integration. Rotating contractors break the pattern; owner-led continuity preserves it. Our fractional CTO across portfolio model exists precisely for this.

Diligence findings translate to integration line items. The diligence memo's findings should map directly to entries in the day-one + 30-day + 90-day plans. If the diligence said "knowledge concentration risk on the payment reconciliation module," the day-one plan has a line item: "Schedule pair-programming session with senior engineer; produce runbook by day 14; identify backup owner by day 21." The translation work is small but consistently skipped. A lean portco still needs the write path after close: private equity software for lean teams is the system that puts those findings into the deal model and turns portfolio monitoring into a weekly file, not a monthly slide.

The integration team has authority to change the operating model. The biggest integrations don't just consolidate systems, they reshape how the portco operates. If the integration team is purely execution-only, with no authority to recommend that finance close on a different cadence or that operations restructure how data flows, the integration ships systems but doesn't deliver synergies. We wrote about this in Post-Merger Technology Integration: A CEO Guide.

The 30/60/90 framework that actually works

Most integration plans use 30/60/90 because it's the conventional shape, but the contents vary. Here's the framework we run for mid-market PE engagements:

Day 0 to 30: stabilize + audit

• Day 1 to 7: Confirm day-one reporting works. Finance produces last week's close on the new owner's systems (even if temporarily duplicated). If it doesn't, the integration team's #1 priority is fixing the reporting bridge, not progressing on the long-term plan.
• Day 7 to 21: Knowledge transfer. Every senior engineer pair-sessions with at least one other person on every system they own. Runbooks for the top 10 operational tasks. Inventory of vendor relationships, contracts, and renewal dates.
• Day 21 to 30: Integration plan reset. The diligence-era plan was hypothetical; now you have actual ground truth. Reset the 60-day and 90-day plans against what you've learned. Re-baseline the cost + timeline estimates.

Day 30 to 60: cut the high-risk dependencies

• TSA unwind sequence. If TSA expires inside 12 months, this is the dominant workstream. Cut the smallest, lowest-risk TSA dependency first to prove the unwind pattern works.
• First system cutover. Pick one, usually a non-customer-facing system like internal IT, expense reporting, or asset management. Use it to validate the integration team's process. The first cutover is more about the team learning than the system.
• Senior engineer retention conversations. By day 60, the team should know which senior engineers are flight risks and have plans (compensation, role, retention bonus) for the critical ones.

Day 60 to 90: production cutover begins

• The first production-load system cutover. This is the test of whether the integration plan is real. ERP, CRM, or core operational platform, depending on the deal thesis.
• Synergy capture begins. First measurable synergy hits the operating model. If you can't point to a specific dollar saved or a specific revenue lift by day 90, the model assumed something that isn't true.
• Plan the next 90 days. The first 90 was about building muscle. The second 90 is about scaling the pattern. Same framework, more confidence.

Where AI-native delivery changes the integration math

The integration playbook above is the durable shape, it works in 2010, 2020, 2026. What changes in 2026 is how much of it can be automated.

A modern integration team running AI-native software delivery, Claude Code as the primary IDE, MCP connectors to the seller's systems, agentic workflows for repetitive integration tasks, moves through the 30/60/90 framework roughly 2 to 3x faster than a 2019-era team. The framework doesn't change. The execution speed does.

Concrete examples we've shipped:

• Day-1 reporting bridge built as an agentic ETL pipeline that reads the seller's source systems via MCP, normalizes to the buyer's data model, and posts to the buyer's BI tool. What used to be 6 weeks of data engineering work becomes 5 days when the right operator runs it.
• TSA unwind tracking as a structured agent that reads the TSA contract, decomposes into deliverables, generates owner assignments, and produces a weekly status digest from source-system status. Less of the integration team's week spent maintaining the spreadsheet, more spent solving the actual blockers.
• Knowledge transfer acceleration via agent-augmented runbook generation. The senior engineer pair-sessions with the agent, the agent produces a draft runbook, the engineer corrects, the runbook ships in days instead of months.

The point isn't "AI does the integration." The point is: the same diligence findings, the same 30/60/90, the same operator continuity, but executed at AI-native delivery speed. That changes the cost curve enough to make integration profitable on smaller deals than the standard model assumes.

What we run for PE operating partners

Pineapples runs three engagement shapes for the post-merger phase:

1. Integration diagnostic, fixed-fee, 5 days. Before close (or in the first 30 days), we read the diligence memo + the integration plan + the systems and produce a memo: which diligence findings translate to which integration line items, where the cost + timeline estimates are likely under-budgeted, what has to be true for the day-one + 30/60/90 plans to ship. Output is decision-ready for the operating partner.

2. Embedded operator, 30/60/90 day engagement. One senior operator embedded with the integration team for the critical first 90 days. Owns the cross-workstream blocker list, drives the day-1 reporting + TSA unwind workstreams, mentors the platform's existing engineering team, ships the 30/60/90 plan. Same operator, no rotating contractors.

3. Fractional CTO across the platform, 6+ months. When the platform is doing multiple add-ons per year, one senior operator carries integration context across every add-on. Covered separately in our fractional CTO services guide.

If you're a PE operating partner working a live integration, or about to close on one, book a 30-minute call. Same operator who ships these. No SDR, no sales team, no proposal cycle.

Book a 30-minute call · pineapples.dev

Finance and revenue surprises after close

Deferred revenue is a delivery obligation, not a reassuring balance. The schedule can show recognition over the coming year while the operating truth is special terms, half-finished onboarding, service credits promised by sales, usage commitments in order forms, and renewals that assume customer success remembers context the ERP never captured. Operators still need the customer, the promise, what has already been delivered, and the system that can defend the pattern.

Revenue recognition fails the first board pack for the same reason. Diligence reviewed ARR, backlog, and renewals. Integration has to explain contract terms that live in PDFs, billing rules that live in spreadsheets and individual judgment, usage evidence spread across product logs, and a close that depends on a few people who know the exceptions. If the team cannot trace a non-standard discount, a usage customer, a credit, and a renewal with amended terms without tribal knowledge, the pack is an argument.

Run-rate surprises are the costs that remain after the one-time budget is spent. Duplicate systems stay alive because a legacy billing table, a support history, or a reporting database still owns a definition. Temporary integrations still need an owner after the first 100 days. Manual checks on entitlements and invoices become headcount. That drag hits the value creation plan every month, which is a different problem from a one-time overrun.

Working capital is the cash version of the same gap. A defensible schedule can still be a spreadsheet assembled by people who knew which inventory was obsolete, which billing rule lived in email, and which past-due invoice was really a dispute. After close the buyer owns the systems, not those people, and the integration pulls the same operators who were keeping cash moving.

Sales tax is easy to mark complete because returns are being filed. Filing can still depend on spreadsheet adjustments, inconsistent product-code mappings, and exemption certificates in email. Before signing, trace a taxable cross-state sale, an exempt customer, a mixed product and service invoice, a multi-location customer, and a recent credit memo. For each one, name the system that calculated the tax, where the certificate lives, and who owns a manual override.

Pricing data hides the same way. Revenue is real and margin looks stable because a few people still know the freight exceptions, the legacy prices customer service honors, and the last manual override. Margin work (a price increase, a discount cleanup, a new segment) cannot start until the team can tell an intentional discount from an accidental one. Trace a top customer, a low-margin high-volume order, a reseller order, and a recent override from the contract or price list through to the invoice.

The integration reserve itself is usually built from the system inventory up: ERP, identity, data import, and a PMO line. That misses how the business runs. The five buckets that blow the reserve are capacity backfill when the acquired team cannot absorb integration on top of daily operations, data remediation dressed up as a simple migration, temporary middleware that becomes permanent, security and compliance rework that expands once shared admins and missing audit trails are visible, and leadership time spent unblocking decisions the model treated as free. Keep those buckets separate before close so the reserve names the risk it is actually holding.

Customer and order data after close

Customer data quality is the layer under every revenue and service report. Pull the same top customers from the CRM, billing, support, product analytics, and finance. Duplicate accounts hide concentration. Contract reality does not match the system. Entitlements disagree across the application, billing, and the contract. Segmentation that sales used informally breaks the new operating cadence. The data does not need to be perfect before close. The buyer does need to know which system owns the customer master, how parent and child accounts work, which identifier joins CRM to billing and product, and who corrects a bad record.

The customer portal is where that mess becomes a customer promise. Identity is often not one customer. The portal does not match the contract, so custom discounts, entitlements, and renewal windows still live in PDFs. Support deflection is often support relocation: the form creates a manual queue, the status page needs an internal update, and the ticket category is too vague to route. Permissions do not match how the customer actually administers users, and portal analytics do not explain customer health. Walk five journeys before close: invoice review, support tracking, entitlement visibility, customer-admin user management, and a self-service request from an account with custom terms.

Order to cash is the machine those records have to survive. Quote, order, contract, invoice, collection, and the report can depend on a human review the deal team never walked. A growing book can hide that waste because new demand covers the gaps. Trace a standard new order, a renewal with a price change, a usage invoice, a credit, and a complex account from quote through collection. If invoicing depends on undocumented review, a later cutover is a cash-collection risk, not only a technical event.

Service entitlement is the operational question next to deferred revenue. Deferred revenue asks what has not been earned. Entitlements ask what is still owed: contracted package, support tier, product permissions, onboarding or migration obligations, and grandfathered terms, plus the system that records each one. Clean accounting and an unprovable support tier can sit in the same account. If the customer record cannot say what the customer bought, every support decision becomes a judgment call.

Inventory master data is the same problem in a warehouse. Duplicate part numbers hide real stock. Units of measure differ by site and break the operating plan. Obsolete stock hides behind active item codes. Product data does not match what was promised to the customer. ERP consolidation then takes longer than the migration plan because finance, operations, procurement, and sales have to decide which item survives, which description is standard, and how historical demand is preserved. Until that master is trustworthy, purchasing and working capital are both estimates.

Systems and cutover

System cutover risk is the chance operations break when the acquired company moves onto the buyer's platforms. Buyers price the data movement and miss the operating work inside it: data that is technically migrated but still needs a human to interpret it, permission models that break workflows on day one, reporting bridges nobody budgeted, and TSA deadlines that force a bad sequence. Choose the window before close. A date that collides with month-end close, payroll, billing, an inventory count, peak season, or a filing window makes the business absorb the switch and a high-stakes cycle together.

Timelines slip even when that window is right, and the dependency chain between finance, the general ledger, HR, and legal entity work is only one cause. The hidden capacity tax is the other: the integration plan assumes the target team can integrate and keep shipping the roadmap already in the backlog. Those are the same people. A knowledge-concentration map names who can modify each critical system. Any system with fewer than two qualified modifiers stalls when that person is out or leaves. Surface area is the third cause. If the customer data models do not match, integrate is not a short migration. It is a transform plus ongoing reconciliation, or two models kept alive on purpose. If the plan is already behind, re-baseline the active workstreams against the people doing the work before adding headcount.

Reporting cadence is how that slip shows up in the weekly meeting. The company can produce a monthly close and still fail a weekly flash. The pack waits on manual reconciliations, spreadsheet bridges, and one operator who knows how to make the numbers usable on deadline. Walk a recent weekly KPI pack and a month-end close on the actual systems. Mark where the data waits, where definitions drift, and which report needs a manual step before leadership will use it. If the thesis depends on faster decisions, tighter cash control, or synergy tracking, that speed is part of the operating model being funded.

Exception handling is the labor inside those waits. It is the manual work when a pricing override, a credit, an approval escalation, or a contract term does not fit the normal path. At the target's old volume it feels manageable. After close it becomes recurring headcount, which is where run-rate surprises stop being a theory. Sample real transactions in finance, support, and operations. Name who handled the exception, which system could not, how often it happens, and what breaks if those people are pulled into integration.

Workflow approval is the decision path under the exception. The documented process is often not the real one. A clean procurement flow in the ERP can still depend on a side conversation with finance. A credit can look automated while one sales-operations manager makes the call outside the system. A release can look governed by ticket status while the go or no-go is a review of customer commitments. Before signing, decide which workflows must be standardized early, which approvals can stay local for a while, where temporary operating support is needed, and which executives have decision rights on day one. Person-owned workflows are where delay clusters. Team-owned workflows can usually be stabilized with roles.

Data contracts are the definitions those workflows share. A field is a contract: meaning, source, owner, update timing, and the workflow that breaks if it is wrong. Six handoffs decide the first 100 days: customer identity, revenue status, renewal and contract dates, product usage, support tier and service promises, and roles, permissions, and account ownership. Classify each as trusted, usable with controls, or untrusted. Revenue status is the common argument. Sales may call an account active after signature, billing after invoice, finance after recognition, product after first use, and customer success after onboarding. All five can be reasonable. Only one can drive the combined dashboard. Deferred revenue asks what is still owed. Revenue status asks which customer state the business is allowed to trust.

Vendors and access

Vendor renewal surprises are contracts the buyer inherits too late. An auto-renewal can close before the integration team is ready to retire the platform and lock another full term. Seat minimums, tier thresholds, and named-user rules do not fall when headcount does, so the synergy in the model survives as an invoice. Data exit, archive, and professional-services obligations turn a shutdown into a project. Vendor-owned integrations, a billing sync or a nightly finance feed, rarely show on the systems diagram until turning the vendor off breaks a report. Before close, record the renewal date, the notice deadline, the auto-renewal mechanism, committed spend, reduction rights after a change of control, and the exit obligation for every material system.

Access control is the other inherited constraint. Permission debt is temporary admin access, shared logins, and contractor accounts that were never removed. Start with the systems that control money, customer trust, and reporting: ERP or accounting, CRM, billing, the data warehouse, HRIS and payroll, inventory or fulfillment, and support. For each, get the role list, privileged users, shared accounts, contractor accounts, service accounts, and recent permission changes. If only one legacy admin can pull revenue detail, or finance cannot separate who prepared a payment from who approved it, the first board cadence becomes screenshots and exports. The integration project will want elevated rights to keep moving. Write the temporary rule before that happens: who can have it, for how long, who approves it, how it is logged, and when it is removed.

Before close

The integration operating model is the decision system, not the Gantt chart. A project plan lists workstreams. An operating model names authority while the business is being combined: who decides when two systems disagree, who owns the customer-facing impact of a back-office change, who can approve a new exception, which exceptions are frozen, which system is the temporary source of truth for customer, billing, and revenue, and which reporting definition the board will use on day one. Without those answers, finance protects reporting, sales protects relationships, product protects velocity, and IT protects architecture. Each instinct is reasonable. Together they make a slow integration. The technology assessment asks what the buyer is buying. The operating model asks how the company will run while it changes. Answer it before close, when the answers are still commercial instead of political.

The integration reserve model turns those facts into a range before the thesis is locked. A round number set afterward estimates tasks (migrate users, connect ERP, consolidate reporting, retire tools) and misses the constraints that move cost. Four lines belong in the reserve, each with a low, expected, and high case. Data alignment is how many definitions of customer, revenue, SKU, and location have to be reconciled before operating reports can be trusted. Integration surface is each system-to-system dependency, sized by documentation and fragility. Access and security is shared admins, unmanaged service accounts, and offboarding that is not auditable. Team capacity is the same engineers owning both the critical systems and the committed roadmap. A system that is opaque, undocumented, business-critical, and has no credible owner is thesis risk. Put it in the investment memo, not a diligence appendix. A two-week version is enough to name the constraints: one week of evidence on systems, definitions, access exceptions, capacity, and vendor constraints, and a second week that writes the low, expected, and high cases plus a first-100-days dependency map.

Further reading in this cluster

The sections above hold the finance, customer-data, cutover, vendor, access, and pre-close topics that used to be separate posts. The guides below are the adjacent work this hub still points at:

• Pre-close diligence checklist: Technology Due Diligence Checklist for Mid-Market M&A. Day-one reporting, TSA dependency, ERP carve-out, and integration readiness now sit on that page.
• Technical debt: Technical Debt Management for Mid-Market. The post-close audit sequence now sits on that page.
• Knowledge concentration / CTO read: CTO Assessment for PE Portfolio Companies
• CEO frame on integration: Post-Merger Technology Integration: A CEO Guide
• AI-native delivery underlying all of it: AI-Native Software Delivery for Mid-Market: How Cracked Engineers + Claude Code Replace 50-FTE Engineering Orgs
• PE software for lean portcos / deal monitoring: Private Equity Software for Lean Teams