When it comes to SAP system integration during mergers or acquisitions, there’s a persistent myth that a “lift and shift” approach—simply transferring one system into another—is a cost-effective and fast method to merge the system of the acquired company into that of the main company, while getting around potential push back from the business since “all processes will stay exactly the same”.

The reality? It’s a high-risk gamble with serious technical, financial and customer service implications.

Still, we understand why this “shortcut” is tempting. As we explain in “Blind Spot Ahead: The Iceberg That Sinks SAP Projects and Businesses“, business leaders face strong and entirely rational pressures to default to “lift & shift”:

• C-level executives want to shield business teams from being sidetracked by SAP projects.

• Business stakeholders want continuity: “ensure the system works exactly like the old one.”

• System Integrators have a clear commercial incentive to propose the simplest possible project. A basic “lift and shift” allows them to present a more attractive price to you, the client, making it far easier to win the work, even if it quietly ignores major integration risks.

And honestly? That logic is understandable.

But here’s the reality:

Some parts of SAP cannot simply be lifted and moved into another SAP system.

It’s not just risky—it’s often structurally unworkable. If you skip over these foundational differences, you don’t just risk inefficiency—you risk embedding systemic failures that may only surface after go-live, when they’re most expensive to fix.

Here are some of the non-negotiables—the areas that demand special attention—without blowing up cost or timeline.

The Pitfalls of “Lift and Shift”

1. Client-Level Settings: The Invisible Wall

Some SAP settings operate at the client level, meaning they affect the entire system, not just individual modules or companies.

Document number ranges and financial reporting hierarchies are an example, but also operational elements like: what do you want the system to do if an Available-to-Promise check reveals not all material is available when you create the SAP Delivery? Do you want a warning? Or do you want the system to block the Delivery creation?

We have witnessed the latter with a client where one company only wanted a “warning” as blocking entire deliveries in their business was not practical, but in the other business, they used to have a “block” to avoid creating plenty of deliveries with zero stock.

And SAP makes you choose: it’s either the one or the other. So when they merged the two aforementioned businesses, they went for the setting in the main company – a “warning” – creating mayhem in business that was merged in, as suddenly plenty of orders were put into delivery with no stock available – overloading the 3PL and logistics teams and causing huge supply chain disruption.

So, you can’t run two versions of these settings side-by-side. Merging companies with different configurations often results in forcibly aligning one business to the other’s operational model, regardless of fit. Overlapping security roles and authorisation profiles only compound the challenge.

We’ve seen cases where a business was merged into another’s system under the promise of “everything will work just like before,” only to discover at go-live that these foundational configuration elements weren’t migrated, and they now have to work with the acquiring company’s rules.

Because the project was framed as a lift and shift, and assumed “no change,” these elements were never run through UAT—and nobody noticed until it was too late.

Failure to address these discrepancies during planning leads to breakdowns that only surface post-migration, when remediation is far costlier and harder to implement.

2. Duplicated and Misaligned Data: A Ticking Time Bomb

Another common pitfall is moving data without harmonisation.

Typical examples are duplicates in customer, vendor or material master data or clashing units of measure.

SAP is German—it’s highly dependent on clean, standardised data. Without it, reporting breaks, planning becomes unreliable, and decision-making slows down.

One company found itself with the same materials planned in kilograms internally, while 3PL partners still managed them in cans or pieces, just like before the migration to the new system. This discrepancy didn’t just disrupt planning; it broke the ATP logic, stopped inbound/outbound movements, and caused invoice errors. Ultimately, service levels dropped so severely that customers started switching to competitors—and revenue fell structurally.

Another client did not consolidate their vendor master records but continued to order from the same vendor using different accounts.

It was only when they noticed that they do not qualify for the volume rebates, they realised that they were using the same vendor twice and should have harmonised data.

3. SAP Enhancements Collide: Two Worlds, One Problem

Over time, businesses heavily customise SAP to suit their operations.

When two systems merge, these (by definition, non-standard) enhancements often collide. In some cases, we have seen enhancements contradict or even overwrite each other, causing a divergence in the solution in one or both businesses.

We have seen enhancements that were designed and written to work on a global level suddenly have to work only on a certain business area.

Also, merging like this creates a Frankenstein system where the problems are even harder to troubleshoot, audit, and maintain.

Customisations intended to solve problems end up duplicating effort or introducing more problems.

One client for instance realised after go-live that they moved to a completely different logic on how to determine batch numbers in logistics. One system always reads the first 10 digits. The other system read the last 10 digits… Needless to say the batch management was all over the place and all interfaces started failing.

In the end, you are not maintaining dual solutions in a single system, but 2.5 solutions on the account that you have to juggle both solutions when wanting to make a single change.

As complexity builds, support becomes more difficult. And the initial rationale for the merger—efficiency, synergy, scale—starts to unravel.

Strategic Integration Practices for SAP

Avoiding these traps doesn’t mean rebuilding everything from scratch. It means knowing where to dig—and where a “good enough” solution truly is good enough.

Detailed Business Model Comparison

Engage an experienced SAP Enterprise Architect early. They’ll compare business models in depth, identify typical conflict points for your industry, and present simple, clear options with trade-offs. This helps the business make smart decisions early—before they’re locked in.

Rigorous Documentation and Testing

As explained in our ‘Blind Spot‘ article, it’s vital to thoroughly document existing processes, interfaces, and system solutions. Use that baseline to perform gap analysis and build test scripts for key scenarios well before go-live.

Define the To-Be Landscape Upfront

Clarify the target architecture early. Knowing where you’re going prevents scope creep, mid-project pivots, and nasty go-live surprises.

Harmonise Data Structures

Align master data definitions, KPIs, and units of measure before integration. This foundational work ensures the merged organisation can report, plan, and operate smoothly from Day 1.

Comprehensive Regression Testing

Don’t just test what’s new—protect what’s working. Regression testing ensures the core business stays intact even as new elements are added.

Conclusion: Avoid the Sh**, Keep the Shift

At AB Advisors, we’re not here to tell you that a lift and shift is wrong. We understand the pressure to move fast, keep the business stable, and avoid long, expensive pre-merger programs. In fact, you can do a lift and shift—just not blindly.

That’s exactly where we come in.

We help you execute a lift and shift the smart way: by avoiding the traps that derail so many SAP mergers, while keeping the effort lean and pragmatic.

Here’s how:

• We bring senior SAP experts who know from experience where critical clashes typically occur. No scattergun diagnostics—just focused attention on the few areas that really matter.

• We guide you in identifying the tasks where lifting and shifting them as-is takes just as much effort as doing them properly. In those cases, getting it right the first time avoids rework, delays, and extra cost—so you don’t fix the same thing twice.

• We come with a suite of tools, accelerators, and hard-won shortcuts built from real SAP merger projects—not theory. These allow us to make even tedious or complex tasks faster, lighter, and more predictable.

In short: you can get through your SAP merger cleanly with a lift and shift approach—without suffering from the typical shortcomings of that approach.

If you’re planning, preparing for, or working through a system merger, bring us your questions. We’ll share what we’ve seen, what works, and how you can move forward with clarity, confidence, and control.

Reach out to us – and help you make your SAP merger swift, without too many frills, but also without the pitfalls and business risk.