Upgrade or replace your ERP: a decision guide for manufacturers and distributors

An upgrade quote, an add-on proposal, and a demo of a new ERP are different projects. They cost different amounts, interrupt the plant or warehouse in different places, and fail for different reasons. This guide is for owners, presidents, CFOs, and operations leaders at mid-market manufacturers and distributors, and it does not recommend a product or quote a fee.

If orders stall between departments, start with the handoffs. Your ERP is not the only problem separates a policy gap, a data gap, and a limit in the product, so a replacement does not carry an ownership problem forward.

The short version

Upgrade the ERP you have when the product still matches how you take orders, make or buy, stock, and ship, and a supported version plus cleaner use of what you already own would remove the pain you can name. Extend it when those core transactions are sound and the gap is one workflow, one report, or one connection to another system. Replace it when the product cannot represent the work, the vendor will not support it through the life of the next investment, or staying costs more than a total cost you can defend. Decide before any demo, and treat a move to the cloud as a hosting question separate from which product should run the business.

Compare upgrade, extend, and replace

A cheaper upgrade is the wrong project when lot trace, multi-warehouse allocation, or outside processing still will not fit, and a replacement is the wrong project when configuration plus a named data owner would have done the work.

Warning signs

Treat these as reasons to open the decision, not as proof that the product has to go.

• Support has ended, or will not cover the years you still need. An unsupported application, database, or operating system is an availability and security problem.
• The upgrade quote is a reimplementation: conversion, retraining, and custom code written again. Score it against a replacement, because either way you are funding a project.
• A workbook, pricing sheet, or ship list is trusted over the ERP. The spreadsheet that runs the plant helps you decide whether that file should stay, gain controls, or be retired.
• A transaction still does not fit after configuration, such as make-to-order stored as stock, lot history a customer cannot get, landed cost that misses freight, or allocations fixed by hand each morning. Confirm the feature is actually missing.
• Only a few people can finish an order, a receipt, or the close, which may be a training gap or a product that no longer matches the work.
• A renewal started the conversation. Questions to ask before another three-year term cover usage, service, price changes, and exit. A discount for signing this month skips that comparison.

Slow reports and untrained modules are usually cleanup on the system you have, not a case for replacement.

What to measure before you decide

Version and support. Record what you run, what the vendor still supports, and when support ends for the application, the database, and the operating system. Mark which customizations and integrations an upgrade keeps.

Which record wins. For one week, list side files that correct the ERP and whether the next step uses the ERP figure or the file. The one people believe is the system of record for that fact.

One live transaction. Walk an order, job, return, or receipt through to the invoice. Note retyping, waits, and rules a supervisor had to interpret. Follow the method in the handoffs article, and keep the notes as requirements if you select a product or as a configuration list if you stay.

Restore, spend, and names. Date the last restore that someone checked, list who has administrative access, total a year of software and hosting invoices, and estimate workaround hours. Name who a project would pull off the floor, out of the warehouse, or away from the close, and say so if a move, an acquisition, or year-end already has them.

Code still running. Ask whether each modification is still required. Unexplained code stalls an upgrade, and copying it forward as a requirement stalls a replacement.

Which path the facts support

Upgrade when you would buy this product again and the pain is version, setup, data, or training. Start with capabilities you already pay for and do not use, such as available-to-promise, lot control, and reports finance rebuilds by hand. Get a written list of versions you may skip, customizations to rebuild, and add-ons that will not move. If that path is a new implementation on the same product, score a replacement beside it. Test on a copy of live data with the people who enter, receive, and close, and cut over outside peak shipping.

Extend when the record is sound and the gap is one boundary, such as EDI, labels, order status, a quality hold, shop-floor capture, or planning. Write the missing transaction, the owner of each fact, and who answers a failed interface. Stay on a field the ERP already stores, and do not add a second item, price, or quantity master. If the workaround remains on the review date, stop, because more integrations added so the first one will work are a replacement under another name.

Replace when essential transactions will not fit, when support will not last and the upgrade is not a product you would choose, or when a recovery, security, or customer requirement cannot be met here. A tested restore or a rule about where data sits can be that requirement, and a wish to be in the cloud is not. A new warehouse, a move to engineer-to-order, kitting inside a distributorship, or a close that lives in a workbook can justify replacement once someone who knows the product confirms the limit. Write those facts before a request for proposal, or the new system will be configured to match the old workarounds.

Cloud, hosted, or on-premises

Who runs the servers is separate from which product you use. You can upgrade on your own machines, extend a hosted system, replace one on-premises product with another, or move the current product to the vendor’s cloud when that path exists.

In every column, ask where data sits, who administers it, how you receive a copy, and what a restore requires.

An ERP selection checklist

Use this when replacement is the decision, or when the upgrade quote is a reimplementation and deserves the same test.

1. Requirements from real workflows. From the transactions you walked, write what the system must do, should do, and will not be asked to do, including partial receipts, prices that change by customer and quantity, scrap and rework, a return that restocks some quantity and scraps the rest, and a promise date that moves after material was allocated. Flag unsettled policy, because software can route an approval and still cannot name the accountable manager.

2. A short list. Compare two or three products built for your mix of discrete manufacturing, process manufacturing, or distribution, and for the number of sites and warehouses you run. Leave out global templates that assume a staff you do not have.

3. One script for every demo. Send it ahead with data that resembles yours: a rush order against allocation, a quality hold that stops a shipment, and the month-end view of variances and open orders. Score every step, including work finished in a spreadsheet, and treat a happy-path tour as incomplete.

4. References you call. Talk to a similar company and to the operations owner, not only the sponsor. Ask what left the spreadsheets, what stayed, what the partner underestimated, how the first close went, and whether they would hire that partner again.

5. Total cost on one page. Include software, the partner, internal time, data cleanup, integrations, training, hosting, support after go-live, the overlap of two systems, and the cost of staying. Use ranges a controller can trace to a quote or to named hours, and reject a payback built on an undefined gain.

6. The partner, scored apart from the product. Ask who configures the system and whether they gave the demo, what is fixed fee versus hourly, and whether cleanup, integrations, and training are inside the price. Take a reference at your scale, name who covers the first two months after go-live, and keep the right to bid a partner the vendor did not send.

7. Exit terms before you have a favorite. Confirm price changes, renewal, and a data export another system could load, using the renewal questions linked above, and have counsel read the agreement.

8. A cutover you can staff. Name the week, the people pulled off their jobs, what must finish in the old system, and what starts in the new one. Stay off peak shipping and the financial close. Compare new figures with the reports people trust, and name who decides which number is right.

Common mistakes

• Booking demos before scenarios exist, so the vendor’s vocabulary becomes the requirements.
• Treating the incumbent quote as the only path when the upgrade is really a reimplementation.
• Taking requirements from a feature grid that shippers, buyers, and accountants never tried on a live order.
• Letting the partner write the requirements and the acceptance script, then accepting whatever was easy to configure.
• Buying what a much larger company runs, without asking what a firm your size turned off or left in a spreadsheet.
• Comparing subscription prices and ignoring internal time, a missed peak week, and a close that does not tie.
• Rebuilding every workaround in custom code instead of judging each one as standard function, configuration, an add-on, or a habit to stop.
• Using the vendor’s quarter-end as go-live during inventory, peak season, or the audit.
• Converting duplicates, dead items, and unapproved prices, with nobody named to delete them or to control new items, customers, and vendors.
• Replacing the ERP to repair a handoff, which only stores an unowned promise date in a cleaner field.

How EdgePoint approaches it

A fractional CIO engagement can hold this decision with operations and finance. That includes the measurements, the comparison of upgrade, extend, and replace, the checklist when replacement is the path, and oversight of a partner you choose. The work can be a defined selection rather than an open-ended retainer. Scope and fees are agreed in writing before paid work begins. Starting points are on the pricing page. An initial conversation is free and is separate from paid work.

If an upgrade quote, a renewal, or a replacement demo is already on the table, start a conversation and bring the quote. The first pass is which of the three paths the facts support.

Frequently asked questions

Should we upgrade our ERP or replace it?

Upgrade when the product still matches how you take orders, make or buy, stock, and ship, and a supported version would remove the pain you can name. Replace when the product cannot represent essential transactions, the vendor will not support it through the life of the next investment, or the upgrade would be a reimplementation without a better fit. If the core transactions are sound and the gap is one workflow or one connection to another system, extend the ERP you have instead of treating replacement as the default.

When is an integration or add-on a better answer than a new ERP?

An integration or add-on is the better answer when you can name the missing workflow, the system that should own each fact, and a person who will handle failures. A shipping connection, a quality hold, a customer portal, or a planning step can be added without replacing the record of orders, inventory, and invoices. Stop adding tools when the workarounds have become the real system of record, or when the ERP cannot represent a transaction the business now depends on.

What should an ERP selection checklist include?

Include requirements taken from real orders, jobs, receipts, and returns, including the exceptions. Use the same scripted scenarios in every demo. Call references at companies of a similar size and process, and include the person who owns operations. Build a total cost that covers software, the implementation partner, internal time, data cleanup, integrations, training, hosting, and the cost of staying. Score the partner who will configure the system separately from the product.

Does moving an ERP to the cloud mean we are replacing it?

Moving to the cloud is a hosting decision, and it is a replacement only when the product changes. Some vendors offer the product you already use as a cloud or hosted service, which can be an upgrade or a migration. A different product is a replacement even when the sales process calls it a move to the cloud. Decide which product fits the work, then decide who should run the servers.

What should we measure before an ERP decision?

Measure support status and how far you are from a supported version, which record people trust when the ERP and a spreadsheet disagree, which integrations and customizations are still in use, and whether you can restore the database. Name the managers who would have to leave their regular work to run a project. Walk one real order, job, or return across departments before you score vendors. If that walk shows a handoff nobody owns, settle the ownership question before you assume a new ERP will remove the rework.