Contents
“Because the tables had filled up.”
That was the explanation I heard for replacing an ERP system when I took over as IT director. The new system had already been running for several months. I had not been involved in the decision.
So I will not judge whether the migration was the right decision. But I found it hard to let that explanation pass.
I started checking. In the configuration of the new, on-premises system, I found no scheduled database maintenance jobs. I also looked at the configuration of the previous ERP, which a few people still used for reference. The situation was similar.
Does that mean a lack of maintenance caused the problems? I don’t know. The work might have been carried out another way, and databases perform some tasks automatically. Nor did I have a complete picture of the reasons behind the earlier migration.
What I increasingly wanted to ask was: what exactly had “filled up”? Disk space? Had performance become a constraint? Had the system reached its limits for further development? Or was the problem in how it was managed?
Each answer would lead to a slightly different discussion. Not every answer would lead to replacing the ERP.
Those checks did not establish whether the migration had been necessary. I will not pretend to know how that story ended. A more useful question remained: how do we distinguish a genuine system limitation from a problem that merely shows up in the system?
Where the problem is felt, and where it starts
I have seen a similar trap many times, on a smaller scale.
Someone would propose an improvement to a particular part of the system. The idea sounded sensible. We could commission the change, test it, close the ticket and happily record another success.
Sometimes, instead, I suggested taking a few steps back. Where had the need come from? What had happened earlier in the process? What needed to change in how the company worked, beyond what appeared on screen?
After a few conversations, it sometimes became clear that the change belonged somewhere else entirely. Or that the proposed solution would merely make the problem easier to live with, without removing its cause.
That does not mean the user described the need badly. They often know best where they feel the problem. They do not have to know where it starts.
So before I say “we’ll do it” or “it can’t be done”, I want to understand what we are actually trying to fix.
That suggestion was not always popular. Someone had come with a ready-made idea and expected a decision, while I was proposing more questions. It is easy to mistake that step back for a delay. It is harder to recognise that implementing the wrong fix quickly is no great achievement.
Replacement can be the right answer too
I have no intention of defending every old system simply because it still produces invoices in the morning.
Genuine technical limitations, lack of support, significant security risks, integration difficulties or excessive maintenance costs can make migration a sensible decision. Sometimes the whole system really does need replacing.
But it is worth knowing why. What is the obstacle? What evidence do we have? Which options have we compared? What will the company gain in return for taking on the risks of change?
If there are several possible explanations for a problem, each pointing to a different investment, choosing a supplier is not yet the most important decision. First, we need to establish which explanation stands up to the facts. The greatest value of the first stage of a project may turn out to be what we decide not to do.
If we mistake the symptom for the cause, we can end up buying a very expensive answer to the wrong question.
Sources and technical notes
- Microsoft Learn, Object Specifications and Limitations — Business Central — technical limits for objects and data; this does not diagnose the case described here.
- Microsoft Learn, Maintain Indexes Optimally to Improve Performance and Reduce Resource Utilization — not all index maintenance needs to run on a fixed schedule; the need should be assessed through measurement.
- Microsoft Learn, Update Statistics — SQL Server — SQL Server performs some optimisation tasks automatically.
