Closing the deal changes ownership. It does not automatically create one company.

Post-acquisition integration requires leadership across the operating model, governance, processes, systems, data, people, service delivery and local realities — all moving toward one coherent future state.

The short answer

An Executive Sponsor should hold ultimate accountability for the integration outcome.

A clearly empowered Integration Lead, Integration Management Office or Transformation PMO should orchestrate the integration across functions and workstreams.

And the future-state business decisions must remain owned by the functional leaders who will operate the combined organization.

Technology, data, HR, finance and specialist implementation partners then deliver within that governance.

These are not competing roles. They are different layers of accountability inside the same transformation.

Implementation partners can deliver workstreams. The business must own the integrated operating model.

The deal is closed. The integration is not.

A transaction can close on a specific legal date.

Operational integration cannot.

Once ownership changes, the organization still has to reconcile two or more operating realities.

Each acquired business may bring its own:

• customer and supplier structures;
• product and service definitions;
• contracts and recurring billing logic;
• ERP, CRM, finance and service-management platforms;
• data definitions and hierarchies;
• reporting conventions;
• approval processes;
• local compliance requirements;
• support models;
• management practices;
• knowledge repositories;
• organizational habits;
• language and culture.

None of those layers exists in isolation.

A change to customer master data can affect CRM, contracts, billing, service delivery and reporting.

A new ERP may expose differences in process ownership that acquisitions had temporarily hidden.

A common service-management platform may require teams to agree on support levels, escalation logic and responsibilities before the technology itself can create value.

Post-acquisition integration therefore needs one leadership system capable of seeing the whole operating reality.

Integration is not a collection of migration projects

Many integrations are organized as parallel workstreams:

Finance

Reporting, accounting, invoicing, controls and corporate financial processes.

HR & Organization

People, roles, reporting lines, policies, workplace and organizational structures.

Systems

ERP, CRM, service management, collaboration platforms and specialist applications.

Data

Customers, products, contracts, suppliers, hierarchies, identities and master-data standards.

Commercial & Operations

Sales processes, service delivery, planning, procurement, customer experience and operating procedures.

Human Readiness

Communication, onboarding, learning, local support, adoption and new ways of working.

Those workstreams are necessary.

But managing each one successfully does not automatically produce an integrated company.

If they operate independently, the organization can end up with:

• a finance integration;
• an HR integration;
• a CRM migration;
• an ERP deployment;
• a data-cleaning project;
• a service-management implementation;
• and a change programme;

without one coherent operating model connecting them.

That is why integration leadership cannot simply coordinate activities.

It must govern the dependencies and decisions between them.

Why post-acquisition integration cannot be owned by IT alone

Technology is one of the most visible integration workstreams because acquired companies often operate different ERP, CRM, finance, service-management and collaboration environments.

But systems do not decide how the combined business should operate.

Before technology can be harmonized, someone must decide:

• What should the future commercial process be?
• How should customers and organizational hierarchies be represented?
• Which product and service definitions become standard?
• Who owns master data?
• How should contracts and recurring relationships be governed?
• Which local differences are genuinely required?
• Which differences are simply historical habits?
• How should finance, sales, operations and service delivery connect?
• What should remain from the acquired businesses?
• What should change?
• How will employees learn and adopt the future state?

Those are business decisions enabled by technology.

They are not technology decisions with business consequences.

IT should lead the relevant technology workstreams.

It should not be expected to own the full post-acquisition operating model.

A five-accountability model for post-acquisition integration

Effective integration governance does not require every decision to sit with one person.

It requires each layer of accountability to be explicit.

1. Executive Sponsor

The Executive Sponsor holds ultimate accountability for the integration outcome.

This role should provide strategic direction, resolve major cross-functional conflicts, protect priorities and ensure that integration decisions remain connected to the business case for the acquisition.

The sponsor should not become the programme manager.

The role is to provide authority, escalation and direction when the organization cannot resolve competing priorities at working level.

2. Integration Lead / Transformation PMO

The Integration Lead converts strategic intent into an executable transformation system.

Depending on the scale and complexity of the acquisition, this may be an individual Integration Lead, an Integration Management Office, or a client-side Transformation PMO.

The role typically connects:

• the integrated transformation roadmap;
• dependencies between workstreams;
• governance and decision cadence;
• risks and escalations;
• operating-model decisions;
• data and systems sequencing;
• partner coordination;
• functional ownership;
• business readiness;
• local requirements;
• deployment;
• stabilization.

This is not simply administrative PMO work.

It is the layer that prevents each workstream from optimizing locally while the company remains fragmented globally.

3. Functional Business Owners

Integration decisions need named owners inside the functions that will operate the future state.

Sales, finance, operations, customer service, HR, procurement, product and other functions must own the decisions that define how their part of the combined organization will work.

They are responsible for answering questions such as:

• What becomes standard?
• What remains local?
• Which process changes?
• Which acquired capability should be preserved?
• Which legacy practice should disappear?
• Which data definition becomes authoritative?
• Who owns the process after integration?
• Who decides when the future state is acceptable?

Without functional ownership, integration programmes accumulate unresolved decisions and push ambiguity downstream into systems configuration.

4. Technology, Data & Specialist Delivery Leads

ERP specialists, system integrators, data teams, finance specialists, HR teams and other partners play essential delivery roles.

They should own the quality of the work they are contracted or assigned to deliver.

But those workstreams must operate inside business governance.

A systems integrator should not be forced to decide the future commercial operating model.

A data migration team should not have to infer customer identity rules from inconsistent source records.

A software vendor should not become the default owner of business adoption.

Clear integration governance allows specialist partners to do their best work without inheriting decisions that belong to the business.

5. Human Readiness & Local Adoption Owners

Integration changes more than systems.

Employees may be adapting simultaneously to:

• a new company;
• different leadership;
• new reporting lines;
• new tools;
• new processes;
• new controls;
• new terminology;
• different approval models;
• new workplaces;
• another corporate language;
• new expectations about ownership and accountability.

Human readiness should therefore be designed into the integration programme from the beginning.

Communication, learning, knowledge, local context and support are not launch activities.

They are operating capabilities.

Two leadership systems. One integration programme.

Functional leaders should own the future-state decisions inside their areas.

The Integration Lead should make sure those decisions form one coherent operating model rather than several independent functional solutions.

Executive sponsorship gives the integration system enough authority to resolve conflicts when local optimization and enterprise integration pull in different directions.

What should the Integration Lead actually own?

A strong Integration Lead does not need to personally design every process or configure every system.

The role is to create the environment in which the right decisions are made by the right people at the right time.

That typically means owning the integration architecture across six dimensions.

1. One integrated roadmap

Individual workstreams can maintain their own delivery plans.

Leadership still needs one integrated view of the transformation.

Finance may depend on master-data decisions.

CRM may depend on customer hierarchy.

Billing may depend on contract normalization.

Training may depend on configuration.

Local deployment may depend on legal or operational readiness.

The integration roadmap makes those dependencies visible.

2. One decision system

Complex integrations generate decisions faster than steering committees can absorb them.

Decision rights, owners, escalation thresholds and governance cadence should therefore be explicit.

The objective is not more governance.

It is faster, clearer governance.

3. One operating-model direction

The combined organization needs a clear view of the intended future state.

That does not mean forcing identical processes everywhere.

It means deliberately distinguishing between:

• corporate standards;
• genuine local requirements;
• valuable acquired capabilities;
• temporary transition arrangements;
• historical variation that no longer creates value.

Without that distinction, “integration” often becomes a negotiation between inherited practices rather than a design of the future organization.

4. One dependency model

Integration delays frequently appear inside one workstream but originate somewhere else.

A CRM migration may be blocked by unresolved customer hierarchy decisions.

Billing may be blocked by contract normalization.

Service-management deployment may be blocked by unclear support levels and escalation logic.

Finance integration may depend on operational data that has not yet been standardized.

The Integration Lead makes those dependencies visible before they become surprises.

5. One readiness view

Technical completion is not the same as business readiness.

The programme should know whether:

• processes are sufficiently defined;
• decisions are made;
• data is ready;
• owners are clear;
• key users are prepared;
• local teams understand what changes;
• knowledge is available;
• support pathways exist;
• leaders are aligned.

Readiness should therefore be governed rather than assumed.

6. One stabilization path

Integration does not end at system go-live.

The first operating cycles reveal where the future-state design works, where local realities were underestimated and where teams still need support.

Stabilization should therefore be part of the integration plan.

It is where design meets operating reality.

Data is often where integration reality appears first

Two organizations may not merely have different databases.

They may have different interpretations of the business.

The same customer may exist under different names or structures.

One company may treat an individual property as the customer while another recognizes a group or parent company as the primary account.

Product definitions may reflect different commercial histories.

Contracts may encode different recurring logic.

Financial relationships may not map cleanly to the future operating model.

That is why master-data integration is rarely just a technical cleansing exercise.

It becomes a set of enterprise-design questions:

• What is the governed business identity?
• Which hierarchy becomes authoritative?
• How are duplicate relationships resolved?
• Which product architecture supports the future model?
• How do contracts connect to customers, services and billing?
• Who owns each critical data definition?
• Which historical references need to remain traceable?

Data governance is therefore part of post-acquisition operating-model governance.

When corporate standardization meets local reality

One of the hardest integration decisions is determining where the combined organization should standardize and where local variation is genuinely required.

The wrong extremes are easy to recognize.

At one extreme, every acquired company keeps its historical way of working and the group never gains operational leverage.

At the other, the corporate model is imposed without understanding local fiscal, legal, contractual, customer or operational requirements.

Effective integration makes the distinction deliberately.

Corporate standards should define the common operating logic where consistency creates value.

Local requirements should be designed into that model where they are genuinely necessary.

Localization is not a failure of standardization.

Poorly governed exceptions are.

Human integration is not a final-stage communication plan

Organizations often underestimate how much simultaneous change an acquisition creates for employees.

A person may understand the new software and still be unclear about who approves a decision.

They may understand the new process but not know where to find support.

They may receive corporate documentation but struggle to apply it in their local operating context.

They may technically have access to the required systems but lack the confidence or practical knowledge to use them consistently.

Human readiness therefore needs to connect:

Communication → Context → Learning → Support → Adoption → Operating Discipline

The objective is not simply to tell people what is changing.

It is to make the future state operable.

When should post-acquisition integration leadership begin?

Ideally, before the transaction closes.

Not because every future-state decision should be made before Day 1.

But because leadership should already understand:

• the integration thesis;
• the critical operating-model choices;
• major systems and data dependencies;
• immediate continuity risks;
• which capabilities must be preserved;
• what requires early standardization;
• who will own functional decisions;
• how integration governance will operate.

After closing, the organization can then move from transaction logic into transformation logic without losing momentum.

If the acquisition has already closed, leadership should still establish this governance as early as possible.

The later the integrated operating model is clarified, the more likely individual workstreams are to create their own interpretations of the future state.

Post-acquisition integration leadership is therefore not a Day 1 activity. It is a lifecycle responsibility.

Evidence: integrating seven operating histories into one shared reality

Guruti's work with Septeo Hospitality Spain & Portugal provides a public example of this challenge.

The integration involved seven legal entities across Spain and Portugal, each bringing different operating histories, systems, data structures, commercial processes, service models and local practices.

The transformation extended beyond a common ERP backbone.

It required work across:

• customer identity and master data;
• organizational hierarchies;
• product and contract architecture;
• enterprise systems;
• finance-connected processes;
• CRM and commercial ways of working;
• service-management models;
• digital workplace;
• onboarding and learning;
• cross-border communication;
• human adoption.

The lesson was not that one platform could make seven businesses identical.

It was that integration required the organization to progressively define one operating reality around shared information, governance, processes and capabilities.

See the Septeo Hospitality Iberia Business Case →

What good post-acquisition integration governance looks like

A practical governance model should make five questions easy to answer.

Who is accountable for the total integration outcome?

There should be one Executive Sponsor.

Who coordinates the integration system day to day?

There should be one clearly empowered Integration Lead, Integration Management Office or Transformation PMO.

Who owns future-state business decisions?

Named functional leaders should own processes, policies and operating rules.

Who delivers specialist work?

Technology, data, finance, HR and implementation partners should own their defined workstreams.

Who decides whether the organization is ready to move?

Business readiness should be visible and governed, not assumed from technical completion.

When those answers are unclear, integration tends to fragment into separate projects.

When they are explicit, individual workstreams can move independently without losing the shared transformation objective.

Where Guruti fits

Guruti works on the business-transformation side of post-acquisition integration, connecting executive direction, operating models, Transformation PMO, enterprise systems, data, processes, governance and human readiness.

The role can include:

• integration architecture;
• operating-model alignment;
• Transformation PMO;
• cross-functional governance;
• enterprise-systems transformation;
• business requirements;
• master-data readiness;
• implementation-partner coordination;
• organizational readiness;
• adoption;
• stabilization.

Guruti does not need to replace systems integrators, technology vendors or specialist functional partners.

The objective is to provide the connecting layer between strategy and the multiple workstreams that must collectively produce one operating organization.

The deal creates ownership. Integration creates one operating reality.

Explore M&A Integration & Operational Scaling →

Explore Fractional CxO & Transformation PMO →

Explore Enterprise Systems, Integration, Data & AI →

Explore Human Readiness, Change & Adoption →

Septeo Hospitality Iberia — Business Case →

Twelve questions to ask before the next integration steering committee

1. Who is accountable for the total post-acquisition integration outcome?
2. Is there one integrated roadmap across business, systems, data and people?
3. Who owns the future operating model?
4. Which acquired capabilities should be preserved rather than standardized away?
5. Who decides whether a local difference is necessary or simply inherited?
6. Are customer, product, contract and hierarchy definitions governed?
7. Are systems decisions connected to business-process decisions?
8. Can functional leaders resolve cross-company conflicts quickly enough?
9. Is human readiness being measured beyond communication and training?
10. Are implementation partners operating inside clear business governance?
11. Who owns stabilization after major migrations or go-lives?
12. Can leadership explain what the combined organization should be able to do differently once integration is complete?

If several of these questions do not have clear owners, the organization may be running multiple projects rather than one integration programme.

That distinction matters.

Executive FAQ

Final perspective

Post-acquisition integration should not be framed as a contest between corporate standardization and acquired-company autonomy.

Both have value.

The acquiring organization brings scale, governance, platforms and common capabilities.

The acquired businesses bring customers, products, expertise, relationships and operating knowledge.

The challenge is deciding what the combined organization should become — and creating the leadership system capable of making that future state real.

That requires more than project coordination.

It requires Strategy → Systems → Execution.

From Strategy to Measurable Impact.

Is your integration being managed as one transformation — or as several disconnected workstreams?

Guruti helps leadership teams connect operating-model decisions, Transformation PMO, enterprise systems, data, governance and human readiness across complex post-acquisition integration programmes.

Explore M&A Integration & Operational Scaling

Book a Strategy Session