A $280 million software acquisition closed in October. The integration consultant delivered a 94-page cutover plan in February. By April, the revenue bridge still showed $4.2 million in unrealized cross-sell, the CRM migration had missed three go-live dates, and the deal partner asked the operating team why deliverables with clear owners and RACI matrices were sitting in “90% complete” status for eight weeks. The answer: the consulting firm scoped the plan and left before anyone ran the first SQL script or flipped the DNS record.
Integration consultants produce frameworks, playbooks, and sequencing logic. Embedded operators write the migration script, test the API, train the user, and take the call at 6 a.m. when the cutover fails. The delta between those two is where synergy estimates turn into footnotes in the next board deck. This article explains where the handoff breaks, what execution ownership actually requires, and how PE firms evaluating an integration partner should distinguish scoping capability from delivery accountability.
What M&A Integration Consulting Typically Delivers
Integration consultants brought in during diligence or in the first 30 days post-close generally produce three artifacts: an integration management office structure, a dependency-mapped workstream plan, and a risk register with mitigation owners. The IMO defines governance (steering committee cadence, escalation paths, decision rights). The workstream plan names 8 to 12 streams (finance, IT, sales, marketing, supply chain, HR, legal, compliance) and assigns an owner, a timeline, and key milestones to each. The risk register catalogs integration dependencies (legacy contract terms that block consolidation, platform incompatibilities, regulatory approvals, customer notifications) and assigns someone to track mitigation.
These are necessary inputs. A $150 million portco acquisition with overlapping Salesforce instances, duplicate marketing automation platforms, conflicting revenue-recognition policies, and two sets of financial reporting standards cannot consolidate without a shared view of what needs to happen and in what order. The consulting output provides that shared view. It gives the deal team and the operating partners a single document to reference in steering meetings, a common language for dependency conversations, and a forcing function that surfaces hidden blockers early.
The limitation is that these artifacts describe work rather than perform it. A workstream plan that says “Migrate 47,000 customer records from HubSpot instance A to consolidated Salesforce instance by Week 16” is not the same thing as writing the ETL script, mapping the custom fields, running the test migration in sandbox, reconciling the error log, getting sales ops to validate sample records, and coordinating the cutover window with the CSM team. The consultant defines what migration success looks like and who is accountable. The embedded operator connects to the API, handles the edge cases, and stays on the call until the record count ties out.
Where Scoping Ends and Execution Starts
Most integration plans include a RACI matrix. Responsible, Accountable, Consulted, Informed. The matrix assigns every deliverable to an owner and makes dependencies visible. In principle, once the consultant hands off the plan, the “R” column tells you who does the work. In practice, the “R” is often a title (IT Director, VP Revenue Operations, Head of Finance) rather than a person with API access, database credentials, and the technical depth to execute the task.
Consider a common post-merger deliverable: consolidating two HubSpot instances into a single Salesforce org. The integration plan will assign this to “Revenue Operations” and break it into phases: audit data quality, map fields, migrate contacts, migrate deals, migrate historical activity, train users, sunset legacy instance. Each phase gets a two-week window and a owner name. What the plan does not include is the daily work that turns “migrate contacts” into a functioning Salesforce environment.
That daily work includes running a dedupe analysis across both HubSpot instances to identify 3,400 duplicate contact records before migration, writing a Python script that pulls contact data via HubSpot API and pushes it to Salesforce via SOAP API while respecting rate limits, mapping 14 custom HubSpot properties to standard and custom Salesforce fields, handling null values and picklist mismatches, running a 500-record test migration to a Salesforce sandbox, reconciling the error log (typically 40 to 60 records with malformed phone numbers, missing required fields, or invalid foreign keys), getting the VP of Sales to validate sample records, scheduling the production cutover during a low-activity weekend window, monitoring the migration in real time, and triaging the inevitable post-cutover issues (missing activities, broken email links, login problems, report discrepancies) that surface Monday morning.
Integration consultants typically exit before that list begins. They define what success looks like and assign accountability. The embedded operator writes the script, handles the exceptions, and takes the 6 a.m. call when the migration fails halfway through.
Why Dependency Maps Do Not Prevent Cutover Failures
A well-built dependency map is a directed acyclic graph. It shows that you cannot consolidate financial reporting (node 47) until you reconcile revenue-recognition policies (node 22), and you cannot reconcile revenue-recognition policies until you map product SKUs across both ERPs (node 8). The map prevents a common integration failure mode: starting work on node 47 only to discover in week 10 that node 8 is blocked because nobody assigned an owner.
What the dependency map does not prevent is execution failure on node 8 itself. Suppose node 8 (“Map product SKUs across both ERPs”) is assigned to the VP of Finance with a four-week delivery window. The task sounds straightforward: export the SKU list from ERP A, export the SKU list from ERP B, create a mapping table, load it into the target system. In practice, ERP A has 2,800 SKUs, ERP B has 3,100 SKUs, 1,400 SKUs exist in both systems but with different naming conventions, 600 SKUs in ERP B were created for one-time customer deals and are no longer active, 200 SKUs in ERP A map to bundles that do not exist as discrete line items in ERP B, and the revenue-recognition policy for software-plus-services bundles differs between the two legacy systems.
The VP of Finance can see the problem and escalate it. What the VP typically cannot do is write the SQL query that identifies inactive SKUs, build the deduplication logic, design the bundle-mapping rules, coordinate with RevOps to update the Salesforce product catalog, and validate that every invoice generated post-cutover ties back to a reconciled SKU. That requires someone with hands-on ERP access, SQL fluency, and enough system context to make judgment calls on edge cases. The dependency map told you the task exists and named an accountable executive. It did not put an engineer in the chair.
This is where scoping and execution separate. The consultant surfaces the dependency, assigns accountability, and moves to the next node. The embedded operator writes the query, handles the exceptions, and validates the output.
The Embedded Operating-Unit Model for Integration Work
An embedded operating unit is a multi-disciplinary technical team that joins the portfolio company for a defined period (typically 12 to 36 months) and takes full ownership of a set of value-creation workstreams. The model originated in the mid-2010s when a handful of PE-backed agencies realized that traditional consulting engagements (diagnose, recommend, exit) were leaving 60% to 70% of the identified value on the table because no one stayed to execute. Instead of handing the portco a playbook, the embedded unit becomes part of the org chart, reports to a C-suite owner (usually the CFO, COO, or CRO), and owns delivery through completion.
For M&A integration, the embedded unit typically owns three categories of work: technical consolidation (CRM, ERP, data warehouse, website, marketing automation, analytics), revenue operations (lead routing, pipeline hygiene, forecast accuracy, commission automation, territory design), and data infrastructure (unified reporting, KPI dashboards, board-package automation, data quality). These are the work streams where integration consultants produce the scoping document and then exit. The embedded unit picks up where the consultant stops and runs the work through go-live.
The structural difference is ownership of the cutover SLA. A consultant delivers a plan that says “CRM migration complete by Week 16.” An embedded unit commits to a cutover SLA: the Salesforce instance goes live on a specific date, with a defined user count, specific functionality enabled (lead assignment, opportunity stages, email integration, reporting), zero data loss, and a post-cutover support window. If the cutover fails, the embedded unit stays on the call until it succeeds. The consulting firm is already off the project.
A portfolio company that acquired two competitors in the same fiscal year used an embedded unit to manage the dual integration. The integration consultant built the IMO, mapped dependencies, and delivered the playbook in month two. The embedded unit took ownership of website consolidation (migrating three separate WordPress instances to a single headless architecture), CRM consolidation (moving 68,000 contacts and 12,000 opportunities from two Pipedrive instances into a unified HubSpot org), and financial reporting consolidation (reconciling three sets of books into a single QuickBooks Online instance with multi-entity reporting). The unit worked on-site two days a week for 14 months, reported to the CFO, and owned the cutover for each work stream. The website went live in month six with zero downtime. The CRM cutover happened over a three-day weekend in month nine with a 72-hour post-launch support window. Financial reporting consolidated in month 12, and the first board package generated from the unified system was delivered in month 13, two months ahead of the value-creation plan.
The deal partner credited the embedded model with preventing what would have been a $6 million to $8 million synergy shortfall. The integration consultant had surfaced the right dependencies and assigned clear owners, but every prior integration the firm had executed left 40% to 50% of technical work incomplete because no one stayed to handle the edge cases, validate the data, and manage the cutover. The embedded unit closed the gap.
When to Use a Consultant, When to Use an Embedded Unit, and When to Use Both
Integration consulting makes sense when the acquiring firm or the portfolio company has an experienced internal team that can execute the plan once it is scoped. If the portco has a strong IT director, a capable RevOps manager, and a finance lead who has run integrations before, the consultant adds value by surfacing dependencies the internal team might miss, providing a governance structure that keeps work streams aligned, and offering a tested playbook that accelerates time to value. The consultant does not need to write the SQL migration script because the IT director already knows how.
An embedded operating unit makes sense when the internal team lacks the technical depth, the integration capacity, or the multi-disciplinary range to execute the plan. A $90 million industrial portco that acquires a software business typically does not have in-house expertise in API-based CRM migrations, headless CMS architecture, or marketing-automation consolidation. The CFO knows what needs to happen but cannot write the Python script or configure the HubSpot workflow. The embedded unit brings the technical capability the internal team does not have and stays until the work is complete.
The two models are not exclusive. A PE firm executing a complex integration can use a consultant to build the IMO and map dependencies in the first 60 days, and then bring in an embedded unit to execute the technical work streams the consultant scoped. The consultant exits after delivering the playbook. The embedded unit stays through cutover. The consultant ensures nothing is missed in the scoping phase. The embedded unit ensures the scoped work actually gets done. Firms that treat integration consulting and embedded execution as substitutes tend to hit the failure mode described earlier: a great plan, clear owners, and 40% of the value left on the table because no one executed the last mile.
Business owners navigating complex operational transitions often benefit from perspectives shared across PE and growth networks like CEO Hangout, where similar integration challenges and execution gaps are discussed among peer operators.
What Execution Ownership Actually Requires
Execution ownership for a technical work stream requires four capabilities: hands-on technical depth (the ability to write the script, configure the system, or debug the error), system access and credentials (you cannot migrate a CRM if you do not have admin rights to both the source and the target), decision authority on edge cases (when you hit a data conflict or a mapping ambiguity, someone needs to make a call in real time without waiting for a steering-committee meeting), and accountability through go-live (if the cutover fails, the accountable party stays on the call until it succeeds).
Integration consultants typically provide zero, occasionally one, and never all four. A senior consultant may have technical depth from prior work, but they do not have credentials to the portco’s Salesforce instance, they are not empowered to make trade-off decisions on SKU mappings or territory assignments, and their contract ends at plan delivery, not at cutover. The embedded operating unit is hired specifically to provide all four. The unit gets onboarded to the portco’s systems, granted admin access to the tools being consolidated, embedded in the decision-making process (usually reporting to a C-suite owner who can approve trade-offs in real time), and contracted through cutover and post-launch stabilization.
Consider a real dependency that surfaced during a Q4 acquisition integration: the acquired company used a custom-built commission-calculation engine tied to Salesforce, and the acquirer used a third-party tool (Spiff) with different logic. The integration plan assigned “commission system consolidation” to the VP of Sales with a 12-week delivery window. By week eight, the VP had escalated three unresolved questions: do we migrate to Spiff and retrain the acquired sales team on new commission logic, do we extend the custom engine to cover the combined team, or do we run dual systems through year-end and consolidate in Q1? Each option had a different cost, risk, and timeline. The integration consultant’s plan did not answer the question because it could not: the answer required input from sales leadership (which commission structure drives the right behavior), finance (which option creates audit risk), IT (which option is technically feasible in the available window), and the deal partner (which option protects the revenue bridge).
The embedded unit facilitated the decision by building a working prototype of each option, running a cost-benefit analysis with real data (12-month commission payout by rep, system maintenance cost, training time, migration risk), and presenting a recommendation with trade-offs clearly stated. The decision was made in a 90-minute working session. The embedded unit then executed the chosen path (extend the custom engine, consolidate in Q1) and delivered the updated commission logic in week 11. The VP of Sales owned the decision. The embedded unit owned the execution.
Marketing leaders managing brand and lead-generation consolidation face similar scoping-versus-execution gaps, a topic explored in detail on platforms like Business Marketing World, where operators share consolidation playbooks and post-merger execution challenges.
How This Changes the Integration Timeline and the EBITDA Bridge
Integration consultants typically estimate integration timelines in quarters: the CRM consolidates in Q2, financial reporting unifies in Q3, the website migrates in Q4. These timelines assume that once the plan is delivered, the internal team executes each work stream on schedule. The assumption breaks when the internal team lacks capacity, technical depth, or decision authority. A CFO who is also managing the core business, closing the quarter, and preparing the board deck does not have 15 hours a week to supervise a CRM migration, debug API errors, and write data-validation scripts.
The result is slippage. CRM consolidation planned for Q2 happens in Q4. Website migration planned for Q3 gets pushed to Q1 of the following year. Financial reporting unification planned for Q3 is still “in progress” at the 18-month mark. Each delay pushes synergy realization further out, which compounds. If cross-sell depends on unified CRM data, and the CRM migration is six months late, the revenue bridge shows a $2 million to $4 million shortfall by year two. If financial reporting is still unconsolidated 18 months post-close, the portco is running dual systems, paying for duplicate licenses, and burning finance capacity on manual reconciliations instead of strategic work.
An embedded operating unit compresses the timeline by removing the execution bottleneck. Instead of waiting for the CFO to find time to supervise the CRM migration, the embedded unit takes full ownership and runs it in parallel with the rest of the business. The CFO stays involved in decision gates (which fields to map, how to handle duplicates, when to schedule the cutover) but does not write the migration script or reconcile the error log. A CRM consolidation that would take 9 to 12 months with an internal team executing part-time often completes in 3 to 4 months with an embedded unit running it full-time.
Faster integration timelines directly improve the EBITDA bridge. A portco that consolidates its CRM in month four instead of month twelve realizes six additional months of cross-sell, unified pipeline visibility, and sales-team productivity improvements. A portco that consolidates financial reporting in month six instead of month eighteen saves 12 months of duplicate software costs, external accounting fees, and internal reconciliation time. The value does not come from better scoping; it comes from faster execution. The scoping was already correct. The execution was late.
What to Ask When Evaluating an Integration Partner
PE firms and portco operators evaluating an integration partner should ask four questions that distinguish scoping capability from execution accountability. First: does the engagement end at plan delivery, or does the partner stay through cutover? If the contract ends when the playbook is delivered, you are buying scoping, not execution. Second: does the partner take ownership of a specific SLA (CRM go-live date, data-quality threshold, cutover success criteria), or do they deliver a plan with SLA recommendations that someone else owns? If the partner is not accountable for hitting the SLA, they are not the execution owner. Third: does the partner have hands-on technical capability (can they write the API integration, configure the CRM, build the data pipeline), or do they rely on the portco’s internal team to execute the technical work? If the partner cannot write the script, they are scoping, not building. Fourth: does the partner embed with the portco’s team for the duration of the integration, or do they deliver the plan and move to the next client? If they are not embedded, they are not available to handle the edge cases, late-breaking dependencies, and post-cutover issues that always surface.
A partner that can answer yes to all four questions is structured to deliver execution, not just scoping. A partner that answers no to one or more is providing integration consulting, which is valuable but not sufficient. The question is not whether integration consulting is useful; it is whether scoping alone closes the value-creation gap, or whether execution ownership is also required. For most mid-market PE integrations, the answer is that both are required, and conflating the two is where synergy estimates turn into board-deck footnotes.
Broader discussions of operational integration models, embedded partnerships, and post-acquisition execution can be found on Blogger Hangout, where content operators share lessons from complex consolidations and embedded-team structures.
Closing the Scoping-to-Execution Gap in M&A Integration
The scoping-to-execution gap is the space between a dependency-mapped integration plan and a functioning consolidated business. Integration consultants close the first half of that gap by building the plan, surfacing dependencies, assigning accountability, and providing governance structure. Embedded operating units close the second half by writing the migration script, configuring the system, managing the cutover, and staying on the call when something breaks. Both are necessary. Neither is sufficient alone.
PE firms that treat scoping and execution as substitutes tend to hit the same failure mode: a strong plan, clear RACI assignments, and 40% to 50% of the identified synergies unrealized because no one executed the last mile. Firms that distinguish the two and deploy both where appropriate compress integration timelines, reduce value leakage, and deliver the EBITDA bridge the deal model assumed. The integration consultant defines what success looks like. The embedded operator makes it happen.
DevriX operates as an embedded technical value-creation partner for PE-backed and mid-market companies executing post-acquisition integrations, system consolidations, and operational transformations. If your portfolio company is managing an M&A integration and needs execution ownership on CRM consolidation, data infrastructure, or website migrations, reach out at DevriX.com.
Common Integration Patterns That Require Both Scoping and Execution
Three integration scenarios consistently surface in mid-market PE deals where the scoping-to-execution distinction becomes operationally visible. First: CRM consolidation across two portfolio companies using different systems (HubSpot and Salesforce, or two separate HubSpot instances with overlapping customer records). The integration consultant maps data fields, identifies duplicate-customer logic, documents API dependencies, and defines the cutover sequence. The embedded operator writes the deduplication script, configures the unified CRM instance, runs the migration, validates data integrity, and stays available for the two weeks post-cutover when edge cases surface. Second: website consolidation where the acquirer is moving four acquired brands onto a single WordPress multisite instance to reduce hosting cost and centralize content management. The consultant defines the taxonomy, maps URL redirects, documents SEO risk, and assigns ownership for content migration. The operator builds the multisite architecture, migrates the content, implements the redirects, monitors search traffic post-launch, and fixes broken internal links that were not visible in the pre-launch audit. Third: ERP or financial-system integration where two companies are consolidating onto a single QuickBooks or NetSuite instance to support consolidated financial reporting. The consultant maps chart-of-accounts differences, documents inter-company transaction flows, and defines the reconciliation process. The operator configures the consolidated instance, migrates historical data, builds the reconciliation reports, and stays embedded through the first two monthly closes to handle data-quality issues that only surface under live conditions.
In all three scenarios, the scoping work is necessary but not sufficient. The plan does not execute itself. The API does not write itself. The edge case that surfaces three days after cutover does not resolve itself. The firm that deploys only the consultant delivers a strong plan and unclear accountability for the last mile. The firm that deploys only the operator without scoping work skips dependency mapping and increases integration risk. The firm that deploys both compresses the timeline, reduces value leakage, and delivers the synergy the deal model assumed.
Why Operating Partners Increasingly Distinguish Scoping from Execution
Operating partners managing multiple portfolio companies in a single fund are increasingly explicit about the scoping-versus-execution distinction because they have seen the same failure mode across multiple integrations: strong plans, clear accountability, and 40% of the synergy unrealized because no one stayed to execute the last mile. The operating partner who has managed five integrations in three years knows that the plan is not the outcome, that RACI charts do not ship code, and that the consultant who delivered the plan in month two is not available in month four when the CRM migration breaks. That operating partner asks the scoping firm upfront whether they execute or whether they hand off, and structures the engagement accordingly.
The shift is also driven by shorter value-creation timelines. When a PE firm held a portfolio company for five to seven years, a six-month integration delay was recoverable. When the target hold period is three to four years and the exit multiple depends on demonstrating EBITDA improvement in year two, a six-month delay is material. Operating partners with shorter timelines cannot afford to deploy a consultant for three months, wait for the portco team to execute the plan over the next six months, and discover in month nine that 40% of the plan was not implemented because the portco team lacked capacity or technical capability. The compressed timeline requires execution ownership from the start, not a handoff to an under-resourced internal team.
The distinction also reflects the professionalization of PE value creation as a discipline. Ten years ago, value creation was informal, ad hoc, and driven by deal partners who occasionally involved operating advisors. Today, most mid-market and larger PE firms have dedicated operating partners, value-creation playbooks, and repeatable integration processes. As the discipline has matured, the vocabulary has become more precise. Operating partners no longer conflate planning and execution, because they have learned that the two require different capabilities, different contract structures, and different accountability models.
Final Takeaway: Match the Partner Type to the Work Required
Integration consulting and embedded execution are both legitimate models serving different needs. Integration consultants are the right partner when the need is scoping, dependency mapping, governance structure, and plan delivery. Embedded operating units are the right partner when the need is hands-on execution, technical build, cutover ownership, and post-launch support. The mistake is not choosing one over the other; the mistake is conflating them, expecting the consultant to execute, or expecting the operator to deliver the governance structure the consultant would have built.
The PE firm or operating partner managing the integration should match the partner type to the work required, recognizing that most mid-market integrations require both. Scoping without execution delivers a plan but no outcome. Execution without scoping increases risk and extends timelines. Both deployed together compress the integration, reduce value leakage, and deliver the EBITDA improvement the deal model assumed. That is the difference between integration advisory and integration delivery, and it is the difference that determines whether the synergy estimate becomes a realized result or a board-deck footnote.
How DevriX Structures the Embedded Model for PE-Backed Integrations
DevriX’s embedded operating-unit model, built over twelve years serving mid-market companies, structures integration work around three phases: diagnostic, build, and stabilization. The diagnostic phase runs four to six weeks and maps the technical estate, data flows, vendor dependencies, and migration sequence. The output is a sequenced execution plan with identified risk points, resource requirements, and timeline assumptions. This phase replaces the traditional three-month consulting engagement with a compressed technical assessment that moves directly into build.
The build phase executes the migration plan with dedicated engineering capacity assigned to the portfolio company. This is not staff augmentation or project-based contracting; it is an embedded unit operating as an extension of the portco’s internal team, reporting to the CTO or operating partner, and accountable for delivery milestones tied to the value-creation plan. The team owns cutover, handles technical debt that surfaces during migration, and adapts the plan when the inherited estate differs from the diligence assumption. The build phase typically runs six to nine months for a mid-market integration involving CRM consolidation, website migration, and data platform work.
The stabilization phase begins after cutover and runs three to six months. The embedded team remains engaged to handle post-launch issues, tune performance, train the internal team, and document the new technical architecture. This phase prevents the common failure mode where the migration completes but the portco team cannot operate or maintain the new platform, leading to either a reversion to legacy systems or an extended dependency on expensive outside support. Stabilization ends when the internal team can operate independently, when documentation is complete, and when the operating partner confirms that the technical work has delivered the expected EBITDA impact.
This three-phase structure differs from both traditional consulting and project-based agency work. It is longer than a consulting engagement, because it includes execution and stabilization. It is more accountable than agency project work, because the embedded unit reports directly to the operating partner and is measured against the value-creation plan, not a project scope. The model works for PE-backed integrations because it matches the operating partner’s need for speed, accountability, and outcome ownership in a compressed timeline.
When Integration Consulting Remains the Right Choice
Integration consulting remains the appropriate model when the portfolio company has strong internal technical capacity and needs external help only for planning, governance design, or specialized diligence. A $200 million software portco with an experienced CTO, a 15-person engineering team, and mature DevOps practices does not need an embedded operating unit to execute a standard CRM migration. That portco needs a consultant to validate the migration approach, identify risks the internal team may have missed, and provide governance oversight during execution. The internal team handles the build; the consultant provides the structure.
Consulting is also the right model when the integration involves multiple workstreams across finance, operations, supply chain, and technology, and the PE firm needs a single advisor to coordinate across all workstreams and report rollup progress to the board. A multi-site manufacturing integration with ERP consolidation, procurement rationalization, and plant closures requires cross-functional coordination that an embedded technical unit cannot provide. The consultant owns the program management layer; specialized operators handle execution within each workstream.
Finally, consulting is appropriate when the operating partner needs an independent assessment of a plan proposed by the portco management team or an incumbent vendor. If the portco CTO proposes a custom-built integration platform and the operating partner wants a second opinion before approving a $2 million budget, the right partner is a consultant who can assess the proposal, benchmark against standard approaches, and recommend a go or no-go decision. The consultant provides independent judgment; execution comes later if the decision is go.
The pattern across these scenarios is that internal capacity exists, the need is judgment or coordination rather than hands-on build, and the operating partner is comfortable owning execution accountability. When any of those conditions does not hold, the embedded model becomes the better fit. Most mid-market PE integrations fall into the latter category, which is why the embedded model has become the default for operators managing value creation in compressed timelines.
