Zero-Trust Architecture — Why We Don't Touch Your ERP

Half a Billion Euros on Software That Never Worked

Lidl

Spent €580 million on an SAP implementation. Seven years of work, hundreds of consultants, countless hours of workshops, data migrations and testing. Then the project was scrapped. All of it. Because the system didn’t fit the way Lidl manages inventory. And instead of changing the system, they tried to change Lidl.

Birmingham City Council

Budgeted £46 million for Oracle Cloud ERP. Final bill: £114 million.

Gartner estimates that 70% of ERP implementations will fail to achieve their intended business goals by 2027. Panorama Consulting is blunt: only 23% of implementations are considered successful.

These figures don’t concern small companies with garage-built systems. They concern the largest organisations in the world, with IT budgets running to tens of millions, and teams of the best specialists. And yet — failure after failure.

Why are we writing about this in an article on Zero-Trust architecture? Because the answer to these failures is the starting point of our philosophy.

Where the Term Comes From and What It Really Means

Zero Trust was born in cybersecurity. The idea is simple and uncompromising: trust nobody. Don’t trust a user who is on the corporate network — they may not be who they claim. Don’t trust a device that was secure yesterday — it may have been compromised today. Verify every access. Every one. Every time.

The Zero Trust cybersecurity market reached $22–34 billion in 2024 (Grand View Research: $34.5 billion, Kings Research: $19.3 billion). CAGR is 16–17%. More than half of Fortune 500 companies are deploying or planning to deploy Zero Trust. This is not a trend. It’s a response to a reality in which 57% of security incidents in 2022 were cyberattacks (IT Governance).

But at QA10, we took that principle — “never trust, always verify” — and applied it to something different. To system integration.

Zero Trust the QA10 Way: Don’t Touch What Works

Your ERP works. Maybe not perfectly. Maybe it’s too slow, maybe the interface has a Windows XP feel, maybe reports have to be pulled manually. But it works. Your people know this system. Processes are encoded in it — not just in an IT sense, but in an organisational sense. Someone knows that invoices from supplier X follow a different path than from supplier Y, because an exception was agreed three years ago that was never documented but everyone knows about.

Now imagine replacing that system with a new one. All those informal paths, those quasi-errors that in practice are workarounds — they vanish. Data must be migrated. Formats don’t match. 49% of organisations experience data migration problems during ERP deployments — and these are not problems visible at the planning stage. They surface on the third day after go-live, when it turns out that a thousand records of historical prices have disappeared into the void.

Our philosophy is the opposite. We don’t replace. We build on top.

Zero-Trust architecture at QA10 means: we build an intelligence layer over your existing systems. The ERP stays. The WMS stays. The CRM stays. Our layer reads data from them, analyses it, automates processes — but does not change a single line of code in your software. We operate alongside, not inside.

Why? Because we don’t trust that replacing the system will go smoothly. The data says it won’t. 55–75% of ERP implementations fail. This is not pessimism — it’s engineering prudence.

What This Looks Like in Practice

Take a concrete scenario. A manufacturing company with 200 employees. An ERP from eight years ago — it works, but doesn’t communicate with the warehouse management system. Inventory levels have to be manually verified every morning. Twice a month, someone dispatches goods that aren’t physically on the shelf because the system balance hasn’t updated in time.

Traditional approach: replace the ERP, integrate with the WMS, migrate the data. Cost? From several hundred thousand to several million PLN. Time? 9–18 months in an optimistic scenario. Risk? See the statistics above.

QA10’s Zero-Trust approach: we build an intermediate layer. Our system reads balances from the ERP and the WMS simultaneously, compares them in real time, flags discrepancies and — where business rules allow — corrects them automatically. The ERP continues to work as before. The WMS continues to work as before. No user has to retrain. No data is migrated. And the problem of dispatching non-existent stock disappears on day one.

This is the essence of Zero-Trust in our interpretation: the core system is not “trusted” — it is monitored, verified and supplemented from outside. Just as in cybersecurity you don’t trust a user on the network, we don’t trust that the ERP gives you the full picture. We verify it with data from other sources. Continuously.

Three Reasons Why Building on Top Beats Replacement

First — time. Building on top of an existing system takes weeks. Replacing an ERP takes months, often years. During that time, business doesn’t stand still — markets shift, clients leave, competitors deploy what you’re still planning.

Second — risk. An overlay layer doesn’t touch source data. The worst that can happen is that the new layer doesn’t work — but the old system keeps running. When replacing an ERP, the worst that can happen is considerably worse. Lidl can confirm.

Third — people. Changing a system means retraining every user. This is not a conference room presentation. It’s weeks of frustration, a productivity dip, resistance — because someone who has known where to click for five years suddenly has to learn it all over again. An overlay layer minimises this disruption. Users see new features, but the foundation on which they work remains the same.

When Replacing a System Makes Sense — Because Sometimes It Does

We would be dishonest if we claimed that building on top is the answer to everything. It isn’t.

If your ERP is so old that the vendor has ended technical support — no overlay will change the fact that you’re working on a ticking time bomb. If the system architecture makes extracting data in any format impossible — there’s nothing for us to read. If the organisation is undergoing a fundamental change in business model — a new system may be the only path forward.

But these situations are rarer than the IT industry — which lives on implementations — would suggest. In the majority of cases we see — and we work with manufacturing, logistics and service companies — existing systems are sufficient as a foundation. They need an intelligent overlay, not replacement.

Zero-Trust as a Way of Thinking, Not Just a Technology

There is something deeper in the Zero-Trust philosophy that goes beyond IT architecture. It is a way of thinking about complexity.

Large IT implementations fail not because technology lets us down. Forbes states that 54% of technology disruptions stem from poor governance, and only 3% from technical issues. Systems don’t break. People make poor decisions about project scope, timelines, and how much change an organisation can absorb at once.

Zero-Trust says: don’t try to change everything at once. Don’t assume a large-scale replacement will go smoothly. Build incrementally. Verify at every step. Give people time to adapt. Test each new layer in isolation before connecting it to the rest.

This is not the caution of someone who fears change. It’s the caution of an engineer who knows what a lack of caution costs. €580 million is a compelling case study.

And that is precisely why every RPA deployment, every automation in the QA10 architecture, every process mining module and every TRL 9 project — all of it happens within the overlay paradigm. We don’t touch what works. We read, verify, supplement.