ERP slowdown: where the real cause lives

In more than 30 years working with data, I have watched the same story play out more times than I can count. A company runs an ERP that has been customized, year after year, to fit exactly how the business works. On day one it runs beautifully, and then, slowly, it begins to get slower. A report that used to take seconds starts taking minutes, and the screen that once loaded instantly begins to spin. No one can point to the moment it happened, because there was never a single moment when it broke, it simply crept up on everyone over time. 

It doesn’t really matter which ERP it happens to be, whether SAP, Microsoft Dynamics, Oracle, or a platform built specifically for your industry. Under the hood they all behave in much the same way, and they tend to hit the very same wall eventually. The system that everyone blames is rarely the system actually at fault. 

Here is why this matters more in 2026 than it ever has before. Almost everything on this year’s roadmap runs on that same data underneath it, because AI-assisted planning, real-time analytics, and the move to cloud all draw from the same well. The spending bears this out, with Gartner forecasting that 62% of cloud ERP spending will go to AI-enabled solutions by 2027, up from just 14% in 2024 (Gartner, 2025). Every one of those ambitions will only ever be as fast as the layer that feeds it. You can buy the most advanced tools on the market, but if the foundation underneath them is slow, then they will be slow too. The risk is already visible in the numbers, with Gartner forecasting that organizations will abandon 60% of AI projects through 2026 wherever those projects are not supported by AI-ready data (Gartner, 2025). 

It helps to remember when most of these systems were first designed. The ERP running your business was, in all likelihood, built long before today’s AI ever existed. It was made to record transactions and produce reports for people to read, rather than to feed models that reason over your data on their own. We are now asking a foundation built for one job to take on a very different one, and the strain shows up right where you would expect, underneath, in the data. 

Why is the slowdown almost always in the database, not the application? 

When an ERP feels sluggish, the natural instinct is to look straight at the application. People reach for a new version, more memory, or a faster server. Sometimes that approach does buy you a little bit of time but the real cause usually sits one layer below, down in the data itself. 

Every recommendation an AI module makes, every dashboard that refreshes, and every automated workflow has to do the same quiet work first. It has to find the right data, combine it together, and hand back an answer. When the tables underneath have grown well past anything they were ever designed for, and the indexing has not kept pace, that work takes longer and longer to finish. The application waits for the data, the user waits for the application, and the intelligence you layered on top inherits every bit of that delay. 

This is the part that genuinely surprises people. The impressive new feature is almost never the real bottleneck, while the unglamorous data layer sitting underneath it usually is. Empirical research backs this up, with a study of 110 industry experts finding that big data management and data contextualization rank among the strongest factors shaping how responsively an ERP handles its data (Bandara et al., Information Systems Frontiers, 2023). 

What happens when the foundation can’t keep up? 

The failure here is rarely dramatic in the way that people expect. There is no outage, and there is no alarm that suddenly goes off. What happens instead is far quieter, and in some ways it is actually worse. 

The planner who waits too long for an answer starts pulling the numbers into a spreadsheet and deciding by hand. The AI module you paid good money for slowly becomes little more than decoration. The analytics team, tired of stale figures, builds its own extracts off to the side, and before long there are three versions of the truth circulating in three different meetings. Nobody ever decided to stop trusting the system, they simply and quietly stopped relying on it. 

That is the real cost of the whole problem. It is not a line on an invoice, but a set of capabilities the business has quietly written off, and a leadership team making decisions on numbers that are already hours out of date. 

A fast data layer isn’t magic, it is carefully maintained 

The good news here, is that none of this is mysterious or beyond your reach. A responsive data layer is not a matter of luck or simply having a bigger budget to spend. It is the direct result of a few important things being looked after properly over time. 

The data itself has to be accurate and consistent, so that the systems reading it can trust whatever they find. The indexing and partitioning have to match how the application actually reads the data today, not how someone pictured it working when the system first went live years ago. And the customizations that have piled up over time, the ones everyone is a little afraid to touch, need to be properly understood and documented rather than simply inherited and feared. None of that work is exotic in the slightest, it is careful and deliberate engineering. It is exactly the kind of thing that gets skipped when everyone is busy, and exactly the kind of thing that quietly decides whether your 2026 plans fly or stall. 

How do you fix it? Start by measuring, not guessing 

If there is one thing I tell clients before they bolt anything new onto an aging platform, it is simply this. You have to measure the system first, because a platform that has never been profiled cannot be tuned with any real confidence, and a system carrying years of growth and customization rarely behaves the way that anyone assumes it does. 

In practice, that means working through a few concrete and deliberate steps: 

• Look at the heaviest reports and planning jobs across a real business cycle, rather than a quiet afternoon, and find exactly where they slow down. 
• Check the quality of the data right at the source, because the gaps that live there are what degrade everything else built on top of it. 
• Map the customizations and the connections between systems, then retire whatever no longer earns its place and document everything that stays. 
• Set a clear baseline now, so that when the AI or analytics work goes live you can prove what it changed instead of merely guessing. 

With a packaged ERP there is one constraint that shapes all of this work. You usually cannot rewrite the vendor’s application, and your freedom to change the underlying structure is often quite limited too. So the work has to happen with the levers you control down at the database layer. If you are running on SQL Server, Query Store is one of the most useful tools you have for exactly this purpose. It shows you which queries are slow and how they have behaved over time, and it lets you lock in a good execution plan without touching a single line of the vendor’s own code. On a system you are not allowed to rebuild, that is about as close as it gets to taking the wheel.

Why getting ahead of ERP slowdown beats waiting

The companies that spend 2026 feeling frustrated will be the ones that bought intelligence and then forgot to feed it properly. The ones that genuinely pull ahead will have looked one layer down and dealt with the foundation while it was still a choice, rather than an emergency. That is the whole difference between them, and it comes down to whether the ground underneath an ambition can carry the weight. 

If you are planning something ambitious with your data this year, and most of us certainly are, then it is well worth looking down before you start building up.  

Is your data layer ready to carry your 2026 ambitions?