Which problems typically occur in an ERP transition?

The typical problems of an ERP transition are rarely technical. Almost always it is the same five patterns: data quality is underestimated, the legacy system is rebuilt inside the new one, nobody truly owns the project, testing happens too late and too little, and the go-live follows the calendar instead of measurable criteria. Knowing these five patterns means spotting them early and correcting course before a problem becomes a crisis.

Problem 1: Data quality is underestimated

The new system takes over the old system's data, and with it every duplicate, every outdated price list and every ambiguous master record. The transition does not make bad data better, it makes it more visible. That is why cleansing master data belongs before the migration, not after it. In our experience, postponing it to „after go-live“ means postponing it to never.

Problem 2: The legacy system gets rebuilt

Every customisation of the legacy system once had a reason. Many of those reasons are long gone, yet the customisations live on because nobody remembers what they were for. Carrying them over unexamined means paying for the transition twice: once for the migration and once for rebuilding ballast. The better question per customisation is not „how do we rebuild this“ but „which business depends on it“. Frequently the standard of the new system covers the real need.

Problem 3: Ownership is not at the table

An ERP transition is a business project, not an IT project. When scope questions stay open for weeks because nobody is allowed to decide, the project backs up and the implementation partner keeps working on whatever happens to be there. In DGP projects, the first thing clarified is who decides and how fast: clear decision paths are the cheapest accelerator a transition can have. How to set this up is covered in the answer on project governance.

Problem 4: Testing happens too late and too kindly

A test run shortly before go-live, with selected data and benevolent testers, finds exactly the errors it is meant to find: none. A transition becomes reliable through at least two complete migration runs with real data and through tests done by the people who will work with the system later. Every error found before go-live is cheap. The same error afterwards costs deliveries, invoices and trust.

Problem 5: The go-live follows the calendar

„We go live on the first, that is what we communicated“ is not a go-live condition, it is a hope. A date holds when it hangs on measurable criteria: migration runs error-free, key processes rehearsed, users trained, fallback plan in place. If one of these is missing, a postponed go-live is the cheaper decision, uncomfortable as it is.

How to tell early that the transition is tipping

Three early signals almost always appear first: open decisions pile up, the implementation partner stops asking questions, and your own people talk about the project in the third person. If you observe one of them, you do not need a restart but an honest assessment of where things stand. The warning signs in detail and the way back are covered in the related answers.