Replacing an ERP: the process, the duration and what happens to the data

Key takeaways

• The effort follows the processes and the data, barely the number of users. Two companies of the same size can differ several-fold.
• Data migration is almost always the underestimated item — and how much history comes across is a deliberate cost decision.
• A test migration with real data, signed off by the departments, is the most effective protection against a failed go-live.
• Projects rarely fail on technology. They fail on unclear scope, an inability to decide, and involving users too late.
• Moving within one product line — from Dynamics NAV to Business Central, say — is considerably more predictable than changing vendor.

When a change is due — and when it is not

Not every irritation justifies a migration project. A system that runs close to standard, is maintained and carries the processes does not get better by being new. Four reasons, on the other hand, reliably support a change:

If none of these apply, the honest counter-check is worth doing: could the actual problem be solved by tidying up inside the existing system? Often the answer is yes — and then tidying up is the considerably cheaper measure.

• Vendor support is ending and security updates stop arriving
• The system blocks initiatives the business needs — cloud operation, automation, modern interfaces
• Customisations have grown to the point where updates are risky and changes are expensive
• Statutory requirements can no longer be met cleanly, e-invoicing being the current example

The process in five phases

The sequence is the same in almost every project; what differs is the depth of each phase. Skip one and you will do it later under worse conditions.

• Inventory: which processes run how today, which customisations and interfaces exist, and which of them anyone still uses
• Target design: what the standard should absorb, what stays custom, what is dropped entirely — this is where the effort is actually decided
• Build and configure: setup, extensions, interfaces, permissions, reports
• Test migration and sign-off: real data in a test environment, checked by the people who work with it every day
• Go-live and aftercare: the production cutover and the weeks afterwards when the last special cases surface

Data migration: which data genuinely has to come across

The question is usually asked too late and then answered reflexively with everything. That is expensive and rarely necessary. A deliberate split into three groups works better.

Master data always comes across: customers, suppliers, items, accounts, prices. It is the core and at the same time the best opportunity to tidy up — dormant records, duplicates and items that have not existed for years do not need to enter the new system.

Open transactions have to come too: unpaid invoices, open purchase and sales orders, stock. Without them the system cannot work on day one.

History is the real decision. Closed documents from earlier years can be migrated, carried over in condensed form, or left in the old system or an archive. For enquiries and audits, read access to the archive is almost always enough, and the migration effort drops noticeably. Commercial and tax retention obligations are unaffected by this and should be agreed with your tax adviser.

How long it takes and what drives the duration

A number without context would be dishonest, because the range is enormous. What can be said honestly is what the duration depends on — and it is almost never the number of users.

Moving within one product line, from Dynamics NAV to Business Central for instance, is considerably more predictable than changing vendor: the data model and the vocabulary stay related, users recognise their workflows, and established tooling exists for the data transfer. Moving to an unfamiliar system means rethinking every process.

• The number and depth of customisations in the old system — usually the biggest driver
• The number and type of interfaces, especially legacy file-based connections
• How much history should be carried over, and in what depth
• Availability of the departments for testing and decisions
• The number of legal entities and sites moving with it

Why projects actually fail

Across many projects the failure patterns repeat — and technology is rarely among them. The most common are: a scope that was never written down and therefore grows through the project; a decision structure in which nobody is allowed to settle process questions; users who see the new system for the first time in training week; and a test phase that gets cut because the go-live date has already been announced.

All four are management questions, not IT questions. The single most effective lever is the test migration with real data, genuinely worked through and formally signed off by the departments. Time saved there is paid back after go-live with interest.

Frequently asked questions

How long does replacing an ERP take in a mid-sized company?

The range is too wide for a blanket figure. The answer only becomes reliable after an inventory, because duration follows the depth of customisation, the number of interfaces and the scope of the data transfer — not company size. A system running close to standard is a manageable project; a special-purpose solution grown over fifteen years is considerably more.

Do we have to carry over all data from the old system?

No, and it is usually not sensible either. Master data and open transactions have to come across. For history you can choose between migrating, carrying it over in condensed form, and archiving. For enquiries, read access to an archive is almost always enough and the effort drops sharply. Retention obligations are unaffected.

Can we keep working normally during the switch?

Largely yes. Build, test migration and sign-off run in parallel with day-to-day operations in the old system. Only the production cutover itself needs a window in which no postings are made — usually a weekend. What costs time is not downtime but the departments' involvement in the test phase; that should be planned for rather than expected on the side.

What is the difference between replacing and introducing an ERP?

With an introduction there is no predecessor system to carry data and processes over from — but equally no grown structure to orient yourself by. A replacement brings data migration, interfaces and established workflows that have to be superseded. The replacement is technically more demanding, the introduction organisationally.

Is moving to the cloud worthwhile as part of the switch?

Often yes, because every customisation is being touched during the switch anyway — the cheapest moment to make them cloud-ready. Cloud operation removes server management, update effort and infrastructure cost; in return, direct database intervention and special routes are no longer available. Whether it fits is decided by your customisations and interfaces, not by a general cloud strategy.