When the ERP Vendor Says Upgrade, Start With What You Actually Use

The deadline came from the vendor, and so did the budget

Pressure of this kind rarely arrives as a threat. It arrives as a recommendation. Theirs was straightforward. The current environment was approaching the end of its useful life, and the vendor’s cloud platform was the natural next step. Attached to that recommendation was a number. It was large enough to reshape the client’s technology budget for several years.

• The proposed platform was priced well above what the business was already spending to run its current ERP
• The recommendation carried a timeline, which compressed the window for any serious evaluation
• Nobody inside the business held a current list of which ERP features were genuinely in use
• Integrations between the ERP and surrounding systems had accumulated over years and were thinly documented
• The entire cost case rested on the vendor’s own description of what the new platform would deliver

That last point mattered most. A vendor recommendation is not a requirements document. It is a sales position. Sometimes the vendor is right. Often enough, actually. You just cannot know until you know what you are actually running today.

An upgrade question is really a usage question

Every ERP replacement decision reduces to one comparison. What does this business genuinely need the system to do, and which options can do it? Most evaluations skip the first half. They compare feature lists instead. That is a mistake. Feature lists always favor the more expensive product, because the more expensive product carries more features nobody asked for.

• Licensed modules and used modules are rarely the same set, and the gap is usually wider than anyone inside the business expects
• Workflows live in the habits of the people doing the work, not in vendor documentation
• Integrations are the expensive part of any migration, and they are almost never fully inventoried before a quote gets signed
• Reporting requirements tend to be specific, small in number, and satisfiable on more than one platform
• Compliance and audit obligations are real constraints, but they narrow the field far less often than people assume

Evidence exists. Zylo’s license utilization data from the 2026 SaaS Management Index shows license utilization across the organizations it tracks sitting at 54% in 2025, improved from 47% the year before. Close to half of what companies pay for still goes unused. An ERP seat is not a SaaS seat. The comparison is imperfect. The pattern holds anyway, and the money involved is considerably bigger. Working out where a business actually sits on that curve is the kind of question our IT consulting services exist to answer.

How we built the evidence before anyone talked price

Our engagement ran as four connected workstreams. None began with a product.

1. We inventoried what was actually being used

We went module by module through the existing environment and separated three categories. What the business paid for. What it had configured. What people opened in a normal working month. Those three lists were not the same list. They never are. The gap between licensed and used is the single most useful number in an ERP evaluation, and almost nobody has it on hand when a vendor quote lands on the desk.

2. We mapped workflows and integrations, not modules

Module names describe how software is packaged. They do not describe how work gets done. So we traced the actual paths instead, following a transaction from where it enters the business to where it lands in the financials, recording every system it touched along the way. That is where the integrations surfaced. Some were formal connectors. Others were not. One was a scheduled export feeding a spreadsheet somebody built years ago. Both kinds cost real money to rebuild, and only one of them had ever appeared on an inventory.

3. We measured the proposed cloud platform against the real list

With a requirements list built from observed usage rather than from a wish list, the vendor proposal became testable. Some of what it offered was genuinely valuable. Credit where it is due. Some duplicated capability the client already owned elsewhere, including tooling inside its existing Microsoft 365 environment. And a meaningful share of the premium was attached to functionality the business had no plan to use. Panorama Consulting’s 2026 ERP Report found that more than a quarter of organizations exceeded their project budgets, with additional technology needs cited as the leading cause. That is what an unexamined requirements list produces later.

4. We evaluated alternatives against the same scorecard

Only then did we widen the field. That requirements list gave us a fixed standard, so every option got measured the same way, including the option of staying put and investing in the current environment. Some alternatives covered the confirmed requirements at materially lower total cost. Others did not. We said that plainly too. Finding the cheapest product was never the point. It was to make sure the price the client paid bought something the client had a use for.

The biggest win was that the decision stopped being the vendor’s to make

The outcome was a decision the client could defend to a board, to an auditor, or to itself in three years. It was evidence, not trust.

• The business now holds a documented list of the ERP features, workflows, and integrations it actually depends on
• The proposed cloud platform was assessed against that list rather than against its own marketing
• Alternative platforms were evaluated on the same criteria, so the comparison stayed consistent instead of anecdotal
• The client avoided spending on capability it had no operational need for
• The path it selected fits both the current budget and the direction the business is heading over the next several years

Worth being precise here. Avoiding unnecessary spend is not the same as avoiding change. The client still made a deliberate move. It just made the move it needed, on a timeline it chose, at a price it could justify. Every engagement we publish is listed on our client case studies page.

What other businesses can learn

Three lessons carry over. They apply to any business being pushed toward an expensive platform decision.

• Build the requirements list before you read the proposal. Once a quote is in front of you it frames every conversation that follows, and you end up negotiating on the vendor’s terms rather than your own.
• Measure usage, do not survey opinion. Ask a department head which modules matter and you will get an honest answer that reflects habit rather than data. Pull the actual usage instead.
• Price the integrations, not just the licenses. Subscription cost is the visible number. Rebuilding the connections between systems is where migration budgets quietly go, and it is the line item most often missing from a first estimate.

An end-of-support date is a real constraint, not a blank check

None of this means deadlines are invented. They are not. Microsoft announced the end of support for Dynamics GP, and Microsoft’s published lifecycle policy sets product support ending on 31 December 2029 with security updates continuing through 30 April 2031. SAP has published comparable dates for its own older ERP releases. Those are genuine planning constraints, and running business systems past them carries real risk, which is why CISA lists unsupported software as a bad practice rather than a tolerable cost saving. Our cybersecurity team treats unsupported line-of-business software the same way it treats an unpatched server.

A deadline tells you when to act. Not what to buy. Those are separate questions, and vendors have an obvious interest in letting them blur together. Several years of runway is enough time to run a proper evaluation, which is precisely why the evaluation should start early rather than in the last quarter before support lapses. That same discipline applies to the cloud migration decisions that usually follow, and to the day to day support an ERP needs once it is live.

Explore the full evaluation

The complete case study covers the work in more depth. It includes the following.

• The full method for separating licensed capability from configured capability from genuinely used capability
• The workflow and integration mapping approach, and how undocumented exports were surfaced
• The scorecard used to measure the proposed cloud platform against observed requirements
• How alternative ERP platforms were evaluated on identical criteria, including the option of staying put
• The cost model that supported the final recommendation and how it was presented to the client

Download the complete case study to see the full evaluation, or contact Uprite to discuss what an independent review of your own ERP roadmap would look like.