Small Business and Enterprise

Mergers and Acquisitions: Integrating Systems

General considerations for combining systems and teams after a merger or acquisition, including sequencing, data, access and people, and why not everything should merge.

On this page
  1. Integration is a set of decisions, not one project
  2. Start with an inventory
  3. What tends to come first
  4. Merging systems versus living with two
  5. Data deserves special care
  6. The people dimension
  7. Timelines and expectations
  8. Governance during integration
  9. Summary of the main trade-offs

Integration is a set of decisions, not one project

When two organizations combine, there is often an expectation that their systems will “become one”. In practice, post-merger integration is a series of separate decisions about what to merge, what to keep running side by side for a while, and what to retire. The right answer varies by function and by the reason for the deal.

A company buying a competitor to absorb its customers may want deep integration. A company acquiring a business in a different field, run as a separate brand, may reasonably leave most systems alone and connect only finance and security. Starting from the purpose of the deal helps keep the scope realistic. This article is general information and does not replace advice from advisers who know the specific transaction.

Start with an inventory

Before deciding anything, it helps to know what exists. A useful inventory covers:

  • applications and who uses them
  • where data lives and how it moves between systems
  • user accounts and who has access to what
  • contracts, licences and renewal dates
  • hardware, networks and hosting arrangements
  • documented and undocumented processes that depend on particular systems or individuals

The undocumented items often matter most. In smaller acquired companies, a single person may know how invoicing, backups or a custom spreadsheet works. Identifying such dependencies early reduces the risk of losing key knowledge when people leave, as sometimes happens after a deal.

A current state assessment of the acquired business is a sensible early step, and it should be done with the cooperation of the people who run the systems day to day.

What tends to come first

Priorities depend on the situation, but several areas commonly need attention early:

Security and access. Connecting two networks or sharing accounts without review can expose both organizations to the weaknesses of the other. Reviewing the acquired company’s security position before opening broad connections is generally prudent, and qualified security professionals should be involved. Identity and access management also needs thought: who from each side needs access to what, and how will leavers and movers be handled during the transition?

Financial reporting. The combined entity usually needs a consistent way to consolidate results. Reporting often relies on mapping accounts between two charts of accounts, which takes careful work. The financial close process may need to run in parallel for a period.

Legal and regulatory obligations. Retention, privacy and sector rules may apply to data held by either party. Specialist advice is important here, as obligations depend on location and industry.

Customer-facing continuity. Customers and suppliers should ideally not notice disruption in billing, support or ordering.

Merging systems versus living with two

It is tempting to consolidate everything quickly to achieve savings. But system consolidation is expensive and carries risk, and benefits are not guaranteed. Options for any given function usually include:

  1. Keep both and connect only what is necessary, such as consolidated reporting.
  2. Migrate one into the other, retiring the second after a transition.
  3. Replace both with a new system chosen for the combined organization.
  4. Defer the decision until the organization understands the combined needs better.

Keeping both is sometimes dismissed as untidy, yet it can be the most sensible option when systems are tied to different products or when one platform is near the end of its life anyway. Replacing both is attractive in theory but means two groups of people learning new tools while also adjusting to a new organization.

Data deserves special care

Data migration after a deal is rarely straightforward. Customer, product and supplier records may use different formats, identifiers and definitions. The same customer may appear in both systems under slightly different names, and master data management approaches can help to reconcile them. Data quality issues that were tolerable inside a single company can become visible when records are merged.

A cautious approach includes agreeing definitions first, testing a small sample, validating results, keeping a rollback plan and keeping the old data available until the new set has been trusted for some time.

The people dimension

Systems are used by people, and a merger is stressful for them. Staff may worry about their jobs, their roles or their way of working. Tool changes introduced during this period can be read as signs that “our way” is losing. Some practical points:

  • Explain the reasons for each decision, including why something is being kept.
  • Involve people from both organizations when choosing between systems, rather than defaulting to the acquirer’s tools.
  • Provide training and a clear place to ask questions.
  • Be honest about what is not yet decided.

An organizational change management approach, along with a clear change communication plan, helps with this, though no plan removes the uncertainty of a merger.

Timelines and expectations

Integration usually takes longer and costs more than early plans suggest, which is a reason for caution when committing to savings. It is generally wise to treat any figures in a deal case as estimates, to stage the work, and to review progress at checkpoints. Phasing the integration allows lessons from early steps to inform later ones.

Governance during integration

Someone needs authority to make trade-offs: for example, whether to delay a cutover to protect the year-end close. A small integration team with a clear sponsor, a list of decisions and regular reviews with both organizations tends to work better than ad hoc choices. Be wary of letting temporary arrangements become permanent without anyone deciding that they should.

Summary of the main trade-offs

Faster integration may bring earlier consistency and lower running costs but increases the risk of disruption and staff disengagement. Slower integration reduces disruption but prolongs duplicated costs and complexity. The balance depends on the business, and it is reasonable to adjust it as the work proceeds.

The complete guide to small business and enterprise

Centralization for Small Businesses and Large Enterprises
Read the guide

Keep exploring

Guides from other topics

All topics →