Merging SAP systems after M&A: from as-is picture to template

After a merger or acquisition, two or more SAP systems suddenly sit side by side — together with a synergy promise that depends on bringing them together. The classic answer: workshops with key users from both sides, months of discovery, and in the end the decision is often made not by the facts but by whoever argues loudest.

The underlying problem: unfamiliar systems are hard to compare. Each brings its own, usually outdated documentation — in different depth, structure and terminology. And at least one of the systems was built by nobody on your team.

There is a more structured way. Four steps, from as-is picture to a rolled-out template.

Step 1: Build a feature map per system

Before anything gets compared, every system needs the same grid: a feature map — business areas, capabilities and features, each distinguishing standard from custom development, and each backed by real usage.

The crucial point is not the map itself but that both systems are measured with the same yardstick. Only when “billing” means the same thing in system A as in system B do two inventories become a basis for comparison.

Step 2: Identify the processes

The feature map shows what is implemented. The second layer shows how people actually work with it: the real end-to-end processes, reconstructed from each system’s document flows — with all variants and their frequencies.

In an M&A context this is the step that delivers surprises. Two companies can run the same modules and still work completely differently: highly automated on one side, manual workarounds on the other — none of which appear in any handbook.

Step 3: Decide the template

Now both systems sit side by side in the same structure — and the template decision turns from a power question into a factual one. Per capability you can answer:

1. Which side is closer to standard? Less distance means less migration effort and less maintenance in the target picture.
2. Where is the volume? A process that carries 90% of the documents weighs more than a rarely used variant — no matter which side it comes from.
3. Which custom developments are attached? Every deviation you adopt wants to be maintained in the template. Unused customization is the easiest synergy win: it is not migrated, it is retired.

The best template is not the bigger partner’s system. It is the combination of the processes that demonstrably work — decided per capability, not wholesale.

Step 4: Roll out the template

The rollout becomes plannable because the gaps per site are visible up front: where does a unit already work close to the template, where does it deviate strongly, where do local custom developments hang on processes that no longer exist in the target picture? The comparison turns into a rollout sequence with justified effort estimates — instead of a bet.

And after every rollout step you can measure against reality: the document data shows whether the unit actually works in the template or whether old habits live on.

Why facts count double here

M&A projects run under time pressure and are politically charged. The question “which system leads?” is always also a status question — and that is exactly why it needs an answer that is not negotiable. A shared, data-based view of both systems takes the edge off the debate: you stop arguing about memories and start deciding on numbers.

---

This is exactly what Conjola is built for: every inherited system becomes its own landscape within the same tenant and is re-documented individually from its real document data — processes, features and custom code in the same grid. The systems can be placed side by side; overlaps and deviations become visible. The template decision is yours — but it rests on facts.