Rebuild the ERP from scratch, or build on what you have? Decision criteria

As a company grows, its systems tire too; and at some point the sentence appears: “let's scrap this and build from scratch.” Often that is a more expensive decision than needed. The right question is not “new or old,” but “what works, and what is actually broken?”

Look through these criteria:

Does it work, or do we just dislike it? A system can be ugly, old or unpleasant, but if it does the job, you build on it rather than throw it away. Disliking and being broken are different things.

Is the data trustworthy? Is the problem in the system itself, or in the inconsistency of the data inside it? Under most “let's replace the ERP” requests lies the absence of a single definition layer — “revenue,” “cost,” “waste” mean different things on different screens. That is fixed by correcting the definition, not by replacing the system.

What does the cost of change buy? Building from scratch is not only software; it is habit, training and transition risk. Is that cost matched by something concrete to be gained?

Is a piece-by-piece path possible? Often, instead of changing everything overnight, it is enough to build the single most painful job on top of, or beside, the current system. One job starts working; the rest stays in place.

Miletus's default is clear: we don't throw away what already works, we build on it; we rebuild a system only when it is genuinely broken. The decision is made not by instinct but by the answers to these questions — that is, by measurement. Best of all is to see which path brings value with a short, fixed-scope diagnostic, before entering the big project.