M&A Integration Playbook: A method for transforming an acquisition into an executable program

An acquisition does not end with the closing. In reality, it is often at this point that the most complex work begins : integrating a new entity into an existing group, without disrupting operations, without losing teams, without degrading the customer experience and without transforming the strategic ambition of the deal into an accumulation of poorly coordinated projects.

In many organizations, post-acquisition integration is still approached as a collection of separate projects: application migration, process harmonization, financial alignment, reporting consolidation, contract transfers, network connectivity, tool convergence, and data rationalization. All these are necessary. But taken separately, they do not constitute integration.

The real challenge of PMI -- Post-Merger Integration -- lies elsewhere: transforming an acquisition into an executable program . This means structuring decisions, prioritizing integration phases, organizing workstreams, clarifying responsibilities, measuring risks, building realistic scenarios, and managing execution over time → This is precisely the role of an M&A Integration Playbook for Business & IT.

This playbook is not a theoretical method: it must be structured enough to be reusable from one acquisition to another, but pragmatic enough to adapt to the size of the acquired entity, its level of operational dependence, its local constraints, its application landscape, its business challenges and the actual ability of the teams to integrate.

PMI: Execution Discipline

In practice, PMI is a transformational discipline. It connects the promise of the deal to operational reality.

Between the expected synergies and their realization, there is a very concrete area of complexity: processes that do not work in the same way, systems that do not carry the same data, teams that do not have the same practices, customers who must not see the difference, inherited contractual constraints, critical applications sometimes dependent on the vendor, infrastructures to secure, and decisions that must be made quickly, but not blindly.

An onboarding playbook helps avoid two common mistakes:

• The first is to believe that each acquisition is so specific that you have to start from scratch → Spoiler alert: this is false → Even if each context is different, the big questions always come back: what should be preserved, what should be integrated, what should be converged, what should be deferred, what should be financed, and in what order?

• The second mistake is to believe that a single integration model can be applied everywhere → This is also false → A small local acquisition, a multi-country entity, a highly autonomous company or a business dependent on a selling TSA do not require the same intensity of integration.

A good playbook should therefore create a stable framework, but allow for multiple trajectories.

A. First step: define the guiding principles of integration

Before analyzing applications, processes, or data, the intention of integration must be clarified.

This is an often underestimated step. Yet, it conditions everything else .

Without guiding principles, each workstream makes its own decisions, each team interprets the ambition of the deal differently, and integration quickly becomes fragmented.

The principles of integration must answer simple but structuring questions.

• What is the level of ambition for the first wave? Should we only secure operational continuity, undertake a partial convergence, or immediately launch a stronger transformation?

• Which areas need to converge rapidly on the group's platforms? Which areas need to coexist temporarily? Which local processes need to be preserved because they are critical, regulatory, or deeply embedded in the business?

• What are the group's strategic platforms? Which systems are considered targets? Which systems can remain in transition? Which systems should absolutely not be affected too soon?

• Which business operations must be protected at all costs during integration? Billing, customer service, production, logistics, procurement, field operations, management reporting, order management?

• What are the real obstacles? ? : budget, team capacity, vendor dependency, technical debt, contractual constraints, data complexity, projects already underway?

  
  

These principles are not mere slogans. They become decision-making criteria. They allow us to say, for example, that a financial department must produce consolidated reporting from the first wave, but that the complete convergence of accounting tools can be addressed in a later phase. Or that a local operational process must remain temporarily autonomous because replacing it too soon would create more risk than value.

The playbook begins with a simple idea: you don't decide on the systems first. You decide on the integration model first.

B. Definition of Workstreams

Once the principles are established, the integration must be broken down into workstreams.

A workstream is not simply a set of projects or an IT category. In a mature M&A playbook, the workstream is the primary unit for analysis and decision-making. It connects business capabilities, processes, teams, applications, data, dependencies, and integration impacts.

For each workstream, the goal is not just to list the applications → The goal is to break down the integration into areas clear enough to organize interviews, collect information, compare existing situations, identify gaps and prepare future integration decisions.

The breakdown of workstreams must be based on the guidelines (A) defined upstream. If operational continuity is critical, certain areas must be isolated for detailed analysis.

If a group platform, such as SAP, is the target path, the Finance, Procurement, and Master Data workstreams must incorporate this constraint from the outset. If certain local processes need to remain temporarily autonomous, the relevant workstreams must be explicitly identified.

• A Finance workstream , for example, is not limited to ERP or accounting tools. It covers invoicing, business rules, bank interfaces, reconciliations, closings, reporting, customer and supplier data, local and group responsibilities, as well as compliance constraints.

• A Customer Service workstream is not limited to CRM. It covers contact channels, processing workflows, customer engagements, ticketing tools, customer knowledge, operational roles, escalations, service contracts, after-sales service, and the ability to maintain service quality during integration waves.

• A Warehouse & Stock Management workstream is not limited to a WMS or a stock tool. It covers physical warehouses, depots, local practices, receiving rules, picking, inventories, discrepancies, scans, outbound flows, teams, interfaces, stock data and dependencies with sales, logistics and finance.

For each workstream, the playbook must define:

• Business and IT Owners

• Area covered

• Elements outside the scope

• Relevant job skills (functions)

• Known applications and dependencies

• Interfaces/Dependencies with other workstreams

• Key stakeholders to mobilize

• Important interviews and workshops to be conducted

• Documents to collect

• Expected deliverables, if needed

This structure creates a common language between business units, IT, enterprise architecture, delivery teams, and program sponsors.

It also ensures that each area of integration will be analyzed with the right level of granularity, without reducing integration to a simple application migration.

C. Workstream Analysis

Once the workstreams are defined, the analysis can begin. The goal is not yet to choose a target solution, decide on a migration, or build a roadmap. At this stage, the primary objective is to understand how the two organizations currently operate within the same scope.

Each workstream must therefore compare two realities: that of the acquired company and that of the acquiring group.

This comparison should not be limited to applications. It must cover business processes, workflows, operational rules, organization, roles, responsibilities, tools used, data, interfaces, external partners, field constraints, and critical dependencies.

The challenge is to document the "way of working" on both sides. How do the teams actually work? Which processes and steps are automated, manual, or bypassed? What tools are officially used, and what files or local practices actually support daily operations? What are the business rules? What are the points of friction, operational risks, specific rules, or hidden dependencies?

• In a Finance workstream, the analysis should not only look at the ERP. It should compare billing processes, closing rules, management control, customer and supplier repositories, banking interfaces, reports used by management and dependencies with other areas, such as Sales, Procurement or Data.

• In a Transport Operations workstream, the analysis must go beyond the TMS. It must include dispatch rules, routes, driver constraints, depots, customer slots, proofs of delivery, customer portals, operational exceptions, and local practices that enable the service to function on a daily basis.

  
  

This analysis then allows for the production of a factual gap analysis . The gaps can be related to processes, workflows, applications, data, organization, skills, interfaces, or operational dependencies. Some gaps will be minor. Others can become major risks for integration: lack of a clear system of record, unreliable data, dependency on a local file, undocumented interface, non-standardized critical process, or activity heavily dependent on a local actor.

The expected outcome of the Workstream Analysis (C) is therefore not yet an integration decision. It is a shared understanding of the gaps, risks, dependencies, and open questions.

These findings will then serve as a basis for building integration scenarios, evaluating possible options and deciding on the most pragmatic path.

D. Formalizing the As-IS Architecture: Building a Living Baseline of Existing Systems

In parallel with the analysis of workstreams, The As-Is architecture must be formalized progressively . It should not be considered a one-time deliverable document; information is rarely complete from the outset. Data is scattered, systems are not always documented, workflows are sometimes known only to a few people, and some actual processes do not correspond to the official documentation, if it even exists.

This is why the As-Is Architecture must be treated as a living baseline . It is built as the workstreams collect new information, discover dependencies, clarify the systems used and objectify the differences between the two organizations.

This baseline structures the information collected. It formalizes the capabilities and business processes, the application landscape by domain, the flows and integrations, the infrastructures and environments, the key data and reference systems, the external partners, the contracts - if necessary - , the tools, the critical files and the business or IT projects already launched.

Architecture plays a crucial role in this context: transforming dispersed knowledge into a reusable architectural foundation. Without this formalization, each workstream can produce its own findings, but the program risks losing the overall view (the big picture) . With a consolidated As-Is baseline, teams can more clearly see which systems support which processes, which data is critical, which flows are structuring, which ongoing projects might constrain integration, and which local choices might have a group impact.

For example, discovering a file used to calculate customer margins, a local interface between the TMS and invoicing, or a customer portal essential for proof of delivery can change the interpretation of the integration scenario. This type of information enriches the As-Is, but can also lead to reopening an analysis, challenging a hypothesis/scenario, or adjusting a convergence option.

Formalizing the As-Is framework doesn't freeze the existing system. It makes it usable. It creates a common basis for integration scenarios, the target architecture, risk assessment, and roadmap development. It allows decisions to be made based on facts, not intuition.

This is also why not all workstreams progress at the same pace. Some areas can quickly clarify their processes and applications. Others, more operational or more dependent on local data, require more workshops, field observations, or validations.

We must accept this reality: integration is not a one-speed process. Each workstream matures progressively, while contributing to a common As-Is baseline.

E. Definition & Validation of Integration Scenarios

Once the workstream analysis has begun and the As-Is baseline has been progressively enriched, the program can enter a decisive stage: the definition and validation of integration scenarios.

This step is not about immediately drawing up an ideal target. It is about transforming the findings from the analysis into concrete, comparable, and arbitrable integration options . Each workstream must therefore move from an understanding of the current situation to a possible trajectory : what should be kept, converged, made to coexist, transformed, migrated, standardized, or deferred?

The logic remains guided by the guidelines defined beforehand . The scenarios are not built in a vacuum. They must respond to the ambition of integration, the priorities of business continuity, budget and capacity constraints, the group's strategic platforms, dependencies with ongoing programs and the sequencing by waves.

In each workstream, several candidate scenarios can be built → A scenario can cover the entire workstream, but it can also concern a specific subject within the domain: a tool, a process, an interface, a data repository, an organization or an operational rule.

• In a Transport Operations workstream, scenarios may involve the temporary maintenance of the local TMS, coexistence with a group platform, a gradual migration by region, or the standardization of dispatch rules without immediately changing the tool.

• In a Finance workstream, scenarios may involve the convergence of reporting, alignment with a group SAP program, the temporary maintenance of a local ERP, or the implementation of transitional interfaces to secure invoicing and closing.

The goal is not to multiply theoretical options, but rather to build a limited number of realistic and actionable scenarios , each clearly describing the business, IT, and operational impacts. Each scenario must indicate its implications for processes, applications, data, interfaces, teams, dependencies, costs, risks, and implementation phases.

These scenarios are then evaluated using a common methodology. The evaluation must compare their functional coverage, their ability to maintain business continuity, their technical feasibility, their organizational impact, their integration complexity, their dependence on other workstreams, their time-to-value, their cost, and their level of risk. This step is essential because a technically appealing scenario may be too risky for operations, too costly for the targeted phase, or incompatible with an existing transformation program . Conversely, a transitional scenario may appear less ambitious but be much more relevant if it protects the business, reduces risk, and prepares for gradual convergence.

A good integration scenario is therefore not necessarily the most ambitious. It is the one that places the right level of change at the right time, for the right scope, with the right level of risk accepted.

The validation of the overall scenario of a workstream (constituted/consolidated from the different scenarios analyzed) must be done with the business and IT stakeholders of the workstream → this scenario does not yet describe the entire detailed target architecture, but it sets the structuring decisions: trajectory of convergence or coexistence, scope to stabilize, subjects to transform, dependencies to address, priorities per wave and business or IT activities to launch.

It is at this point that the workstream shifts from an analytical approach to a decision-making approach. Findings are no longer mere observations; they become integration choices.

The next step, the formalization of the target architecture, will detail this chosen scenario: target applications, flows, data, processes, reference systems, infrastructures and operational model.

F. Formalize Target Architecture: turning validated scenarios into a coherent integration target

Once the integration scenarios have been defined and validated by workstream, the program enters a critical formalization step: building the target architecture.

At this stage, the objective is no longer to compare multiple options. That work has already been done during scenario definition and assessment. The objective is now to translate the selected scenarios into a clear, readable and coherent target that can guide the next phases of the program.

Each workstream comes with its validated scenario. Finance may have selected a progressive convergence toward the group platform. Transport Operations may have chosen a temporary coexistence of local operational tools. Data may have defined a trajectory to consolidate key reference data. Procurement may depend on a broader group transformation program already underway. Taken separately, each of these choices may be relevant. The role of Step F is to verify that, together, they form a coherent integration target.

The target architecture is therefore not a simple collection of local decisions. It consolidates the trajectories selected by each workstream and translates them into an overall view: target applications, systems temporarily maintained, integration flows, reference data, systems of record, target processes, operational responsibilities, technical dependencies, infrastructure constraints and interactions between domains.

This formalization helps answer structuring questions. Which applications become target systems? Which tools remain in temporary coexistence? Which flows need to be created, adapted or removed? Which data must be controlled as a priority? Which system owns customer, supplier, vehicle, contract or invoice data? Which processes need to be standardized? Which processes can remain local during a transition period? Which dependencies must be secured before any switch-over?

In the case of a transport acquisition, this step may, for example, formalize that the local TMS remains in use temporarily to protect field operations, while group reporting, finance, master data and certain integration flows need to converge more quickly. It may also clarify that a future SAP trajectory imposes governance rules on supplier data, procurement, finance and interfaces with operational tools.

Enterprise architecture plays a central role here. It enables the program to move from a workstream-by-workstream logic to an integrated view. It identifies potential inconsistencies between validated scenarios, makes cross-domain dependencies visible and prevents each domain from building its own target without considering the others.

For example, a Finance decision may depend on customer master data managed by Sales or Customer Service. A Procurement decision may depend on alignment with SAP. A Transport Operations decision may require an integration flow with invoicing or reporting. A Data decision may reveal that the system of record is unclear or that a critical data object is created in several systems. The target architecture exists precisely to make these links visible before moving into roadmap planning.

This step must therefore produce a target that is structured enough to guide execution, but not yet a detailed roadmap → this comes next where the target is translated into projects, waves, budgets, resources and execution governance.

The expected deliverables of this step typically include a consolidated target architecture, a map of target and transitional applications, a view of the flows and integrations to be implemented, an identification of systems of record, a view of target processes where needed, and a summary of major dependencies between workstreams.

The value of this step is to secure global coherence before planning. It avoids building a roadmap on fragmented decisions. It also ensures that the scenarios validated by business and IT can realistically coexist within a common, progressive and executable target.

In summary, Step F turns validated scenarios into an integration architecture. It does not decide on behalf of the workstreams; it consolidates, structures and makes executable the target that will serve as the foundation for the roadmap.

G. Building the Roadmap: Transforming the target into a portfolio of executable projects

Once the target architecture is formalized, the program has a consolidated view of the integration target. The scenarios selected by workstream have been validated, the main business and IT decisions are known, the target and transitional applications are identified, the structuring flows are clarified, the major dependencies are visible, and the activities necessary for integration have begun to be defined.

This target only becomes executable when it is transformed into a portfolio of projects → moving from an integration target to an operational and activatable roadmap , built around projects, initiatives, dependencies, waves, budgets, resources and governance.

At this stage, the objective is to build the execution plan: what needs to be launched, in what order, with which teams, what budget, what dependencies and what management?

The first step is to consolidate all the previously identified business and IT activities. Some come directly from the validated scenarios : temporarily maintaining a tool, creating an interface, harmonizing a process, migrating reporting, training teams, securing a critical activity, or implementing local governance. Others come from the formalized target architecture : technical dependencies, data prerequisites, infrastructure constraints, reference systems to clarify, flows to build, or platforms to align.

These activities should not remain scattered across workstreams. They should be grouped into coherent projects or initiatives. This is where the program builds its catalog of integration projects.

A project can encompass several activities from multiple workstreams. For example, a supplier repository project might involve Procurement, Finance, Data, and IT.

• A consolidated reporting project may depend on operational tools, Finance management rules, data quality and the analytical platform.

• An interface between a transport tool and billing can involve Operations, Finance, Data, Architecture and IT Run.

The roadmap is therefore not simply a projection of workstreams over time. Workstreams are units of analysis and decision-making; projects are units of execution.

A workstream can produce multiple projects. A project can span multiple workstreams.

A dependency may necessitate grouping several topics into a single initiative. Conversely, a topic that is too broad may need to be broken down into several projects to be manageable.

The project catalogue must then be qualified. Each initiative must be described with its objective, scope, deliverables, dependencies, prerequisites, risks, sponsors, business and IT contributors, estimated effort, indicative budget and contribution to integration objectives.

This qualification allows you to move from a list of stocks to a manageable portfolio.

Once the catalog is built, the projects must be prioritized. They do not all have the same urgency, value, or risk. Prioritization must take into account business criticality, operational continuity, technical dependencies, expected value, contribution to synergies, feasibility, effort, cost, team capacity, and constraints of existing programs.

• A project to secure access or minimum reporting may be a priority because it conditions visibility and continuity.

• An application migration may be deferred if it depends on a group program, insufficient data quality, or a high operational risk.

• A standardization project can be positioned in a later phase if it first requires stabilization of local processes.

Prioritization should then feed into the wave-based sequencing. The logic of waves allows for structuring execution without overloading the organization.

• A first wave (Wave) can aim for stabilization, visibility and security.

• A second wave can bring about the controlled convergence of processes, data, repositories and tools.

• A third wave can bring deeper transformation, rationalization, optimization, and modernization.

It is also essential to produce a budget estimate and a capacity estimate. A roadmap that does not take available resources into account quickly becomes unrealistic and impractical.

Therefore, it is necessary to estimate the costs associated with business, IT, data, architecture, change management, delivery, support, and program management. It is also necessary to identify external needs: integrators, software publishers, technical partners, data experts, specialized consultants, or vendor support.

Budget planning should ideally be done by project , by phase, and by area of implementation . This allows for a balance between ambition and actual capacity. It also prevents launching too many critical projects simultaneously, all of which require the same teams.

The roadmap needs to be broken down at several levels.

1. The first level is the overall integration roadmap . It provides the overview: major waves, key milestones, structural dependencies, project sequence and transformation trajectory.

2. The second level corresponds to sub-roadmaps by execution area → These areas do not always correspond exactly to the initial workstreams . They may be structured around broad areas such as Business Operations, Finance, Data & Reporting, IT & Security, Procurement, Customer, HR, Change Management or Platforms.

3. The third level consists of project sheets . Each sheet describes the objective, scope, activities, deliverables, dependencies, resources, budget, schedule, risks, and success criteria.

   
   

The expected deliverables of the roadmapping are therefore:

1. Catalogue of projects and initiatives

2. Prioritizing projects

3. Budget estimate

4. Resource estimation and FTE

5. Overall integration roadmap

6. Sub-roadmaps by execution domain

7. Project sheets

8. Dependency mapping

9. Governance model to guide execution.

H. Governance & Execution of SMEs: End-to-End Management

An M&A playbook cannot function with a single methodology. It requires a governance mechanism capable of maintaining the framework, coordinating stakeholders, ensuring sound decision-making, and ensuring alignment between business decisions, IT choices, and operational execution.

The sponsor plays a crucial role , but it's not enough. They champion the integration ambition, validate the structural guidelines, and arbitrate major decisions. However, the successful execution of the PMI requires more comprehensive governance: a steering committee, a PMI Office, workstream owners, an architecture function, delivery managers, and business liaisons capable of driving analyses, decisions, and projects forward at the right pace.

This governance must be active from the beginning of the framework. It comes into play when integration guidelines are defined, when workstreams are structured, when As-Is analyses start, when scenarios are evaluated, when the target architecture is consolidated, and when the roadmap is built.

The integration steering committee must bring together business and IT decision-makers capable of arbitrating cross-functional issues: level of ambition, convergence or coexistence, budget, team capacity, priorities per phase, acceptable risks, critical dependencies, and decisions that extend beyond the scope of a single workstream. Its role is to maintain overall consistency and prevent each area from making decisions in isolation.

The PMI Office plays a crucial operational role . It organizes the work schedule, consolidates workstream inputs, tracks open decisions, risks, dependencies, workloads, milestones, arbitration points, and deliverable progress. It ensures the framework moves forward, the right stakeholders are engaged, decisions are documented, and critical issues are escalated to the appropriate level.

Workstream owners are responsible for their domain. They coordinate interviews, validate the scope, contribute to the analysis of both As-Is, identify gaps, prepare scenarios, assess impacts, and formulate business and IT requirements. They are essential because they bridge the gap between the framework and operational reality.

Enterprise architecture plays a cross-functional role in ensuring consistency . It structures the as-is environment, aids in workstream analysis, defines, analyzes, and challenges scenarios, consolidates the target architecture, identifies dependencies between domains, helps build the roadmap and develop the budget, and prevents local decisions from creating complexity at the group level. It also acts as a design authority, not to slow down decisions, but to ensure that choices remain consistent, documented, and executable.

Delivery managers gradually take over as validated scenarios and target architecture begin to transform into projects. They help to qualify initiatives, estimate effort, build execution plans, and prepare future delivery waves.

Without this governance, the framework risks remaining a theoretical model. With it, it becomes an execution system: guidelines become decisions, workstreams become driven analyses, scenarios become arbitrated choices, the target architecture becomes a consolidated target, and the roadmap becomes a portfolio of truly executable projects.

Conclusion: the deal creates the opportunity, the playbook creates the execution

An acquisition can create a strategic opportunity. But this opportunity only becomes real if the integration is structured, prioritized, and executed.

The role of an M&A Integration Playbook for Business & IT is to transform an acquisition into a controlled trajectory. It doesn't replace management decisions; it makes them visible. It doesn't eliminate complexity; it organizes it. It doesn't claim that all acquisitions are identical; it provides a framework for comparing, sizing, and managing them.

In environments where acquisitions are multiplying, this type of playbook becomes a strategic asset . It allows capitalizing on previous integrations, reducing improvisation, clarifying responsibilities, securing operations, accelerating arbitration, and transforming expected synergies into concrete actions.

The issue is therefore not simply about integrating into a company. The issue is about building a repeatable capacity for integration.

Because in M&A, the transaction defines the ambition. But only execution transforms that ambition into value.