The first page of "post-merger integration playbook" is McKinsey, Bain, BCG, PwC, and a long tail of consultants selling roughly the same artifact: a multi-workstream PMI program built for a Fortune 500 swallowing another Fortune 500. A program management office. A clean room. An IMO lead reporting to a steering committee.
That is not the deal in front of you.
The deal in front of you is a $20M target getting folded into a $60M platform. The senior team is eleven people. Three of them ran diligence and are about to run the integration on top of their day jobs. There is no IMO. There is one ops lead and one CFO who already does too much. Lift the F500 playbook as-is and you spend eight weeks staffing a program office instead of running the business you just bought.
We are not PMI consultants. We build the data pipelines and sourcing infrastructure firms hand off at close, so we sit a layer below the deal team. The version of integration that matters at this size is not an org chart. It is whether the seller's sourcing motion, CRM, and contact graph survive the handoff intact, or quietly stop working in the first quarter.
Here are the patterns to watch for.
The staffing reality
In an F500 PMI, day one starts with a dedicated integration team that is its own org chart. In yours, the integration team is the people who closed the deal plus whoever can be borrowed back from operations for a few hours a week. The CFO owns finance integration because there is no separate FP&A lead. The head of growth owns the commercial side because the VP Sales role at the platform is the same person you just inherited. Nobody is full-time on integration. Everybody is half-time on integration.
This changes every assumption the consulting playbooks bake in. You cannot run twelve workstreams in parallel. You can run two, maybe three, well. Pick them on day one and write down which ones you are deferring. Show the deferral list to the board so nobody is surprised when AP is still on two systems in September.
The 100-day plan at this size is a sequencing exercise, not a project plan.
The first hundred days
Skip the swim-lane chart. Three things have to happen, in this order.
The first thirty days are about not breaking the seller's business. The seller had a working motion that produced the $20M you just paid for. Most of that motion lives in the heads of two or three people who now have new email addresses and a vesting question. Keep them. Pay them. Do not touch their CRM yet. Do not consolidate their tools yet. The failure mode to watch for is the buyer ripping out the seller's stack in the first month, losing pipeline visibility for whatever stretch it takes to rebuild, and rebuilding what was already working.
The middle thirty days are about one financial close on the combined entity, not chart-of-accounts harmonization or a unified ERP. The CFO needs a defensible monthly P&L that rolls both businesses together so the board, the lender, and the operator team see the combined picture. At this deal size, that close is usually a mapping spreadsheet between two accounting systems. Treat it that way. Full ERP consolidation, if it happens, is an eighteen-month project, not a hundred-day one.
The last thirty days are about the data layer the next deal will need. This is the part everyone defers, and the part that determines whether the platform can buy three more companies in two years without integration cost growing linearly. More on this below, because it sits adjacent to what we actually build.
Where the data stack breaks
The data infrastructure underneath the business (sourcing pipeline, CRM, deal-room, contact data) is where the integration tends to leak. There are three places to watch.
The CRM is the first. The seller had one. The buyer had one. They are different. Nobody wants to migrate, so the team runs both in parallel. Six weeks later there are two definitions of "active opportunity," two definitions of "qualified," and the weekly pipeline review is a debate about whose numbers to trust. The default move is to pick one CRM and migrate the other into it. That works for the records. It does not work for the seller's institutional memory, which lived in disqualification notes and custom fields nobody documented.
The sourcing stack is the second. The seller had a way of finding the next ten targets. Maybe it was a contractor in another time zone running secretary-of-state filings. Maybe it was a six-figure data subscription nobody renewed in time. Whatever it was, it usually stops running within the first month or two of close, and the platform's existing motion does not speak the seller's vertical. The sourcing pipeline for the vertical you just bought goes quiet while everyone is busy with integration, and the next deal in that vertical slips.
The deal-room and the contact graph are the third. The seller's deal-room is a shared Dropbox folder. The contact list is in three places, including one person's iPhone. Rebuilding from the outside later costs more than capturing it cleanly in the first ninety days.
The data stack at this deal size
The playbooks treat the data stack as an IT workstream. At LMM scale it is closer to the asset you just bought than a back-office cleanup.
The $20M business is worth $20M because it had a working motion for finding customers in a vertical the platform did not previously reach. That motion lives in a sourcing pipeline, a CRM, an outreach cadence, and a set of disqualification heuristics that live half in a tool and half in someone's head. Treat those as systems to consolidate and the value walks out the door with the people who knew how the systems were stitched together.
The alternative is to treat the data layer as the integration. Re-run the seller's sourcing motion on infrastructure the platform owns, in the first hundred days, before the institutional memory leaves. Capture the disqualification logic into something the platform controls. Get the seller's pipeline into a system that survives the next deal too, so when the platform buys company three and four, the integration cost does not start from zero each time.
F500 assumptions at LMM scale
The McKinsey/Bain/BCG playbook is not wrong. It is built for a different problem. At F500 scale the buyer has full-time integration staff, redundant systems on each side, and a mandate to harmonize an operating model across many business units. The cost of running an IMO is rounding error against the synergy thesis. So is the seller's institutional memory, because the seller had thousands of people and most of it was documented.
At a $20M into $60M platform, every one of those assumptions inverts. There is no spare integration headcount. There are no redundant systems. There is one of each, it is the seller's, and the people who know how it works are about to vest. The synergy thesis is not a model output, it is a sourcing motion in someone's head. Running a full workstream grid costs more than the deal is trying to capture, and the things the playbook treats as deferrable side projects are the actual asset.
So month one is not about an IMO. It is about three things the buyer does the week after close: lock the two people who run the seller's sourcing motion into a retention package that outlasts the integration, build a thirty-day shadow of the seller's pipeline into infrastructure the platform owns, and write the disqualification heuristics down in a format that survives the seller's next departure. Do those three things and the platform carries a real sourcing capability into deal two and deal three, instead of restarting from a contractor and a spreadsheet each time. Skip them for an org chart and a steering committee, and you bought a vertical you can no longer operate.
