Innuevation Request Access
← All posts · Migration & Implementation

When to Stay: The Honest Case for Optimizing Your Current ERP Before Migrating

Adam Arends · March 17, 2026 ·
erp-strategy optimization migration-decision CFO

Not every company that’s frustrated with its ERP needs a new one. Sometimes the tool is fine and the process is broken. Sometimes the implementation is under-configured rather than the software under-capable. Selling a migration to a company that doesn’t need one is the same conflict of interest as the implementation partner who over-scopes everything. Here’s the decision framework.


This is a piece arguing against migration, written by a company that builds ERP software. Take that for what it’s worth — we think the credibility of being honest about when migration is the wrong call matters more than the marginal customer we might lose by saying it.

The optimization case

Many companies that believe they’ve outgrown their ERP have actually under-implemented it. NetSuite is a capable platform for mid-market finance. But a NetSuite instance configured by an implementation partner who was managing scope and timeline pressures may be using only a fraction of the available functionality. Revenue recognition is off. Multi-subsidiary isn’t enabled. The saved searches that would replace those Monday-morning spreadsheets have never been built. The system can do more than it’s doing; the implementation just didn’t get there.

Before concluding that the system needs to be replaced, the question worth asking is: what is this system capable of that it isn’t currently doing for us? A focused optimization engagement — typically 60–90 days with a qualified partner — can sometimes close the gap between what the system is doing and what it can do, at a fraction of the cost of migration.1

Signs that optimization is the right answer

Optimization is likely the right answer when the system limitations being complained about are features that exist in the current system but aren’t configured. When the pain is primarily about data quality or process discipline rather than missing capability. When the business processes themselves are the problem — inconsistent, poorly documented, not followed — and a new system would inherit the same process problems in a new interface.

It’s also the right answer when the company doesn’t have the organizational bandwidth to absorb a migration right now. A migration done under resource pressure, with inadequate testing time and inadequate change management, produces worse outcomes than a well-run optimization of the current system with a planned migration 12–18 months later.

Signs that migration is actually necessary

Migration is necessary when the system genuinely can’t do what the business needs it to do, and the gap isn’t a configuration issue. Multi-entity consolidation that the platform doesn’t support at any price point. Revenue recognition complexity that exceeds the platform’s native capability. Transaction volumes that exceed what the architecture can handle at acceptable performance levels. Regulatory requirements that the system can’t satisfy.

Migration is also necessary when the system has been so heavily customized that it’s no longer maintainable — when the customization layer has accumulated to the point where changes break things unpredictably, upgrades require major projects, and the original implementation partner is the only one who understands how it works. At that point, the current system is a liability rather than an asset, and migration is the path to a stable foundation.

The honest framework

The decision framework is straightforward when applied honestly:

First: what specifically is the current system failing to do? Name the capability, not the feeling. “Our close takes too long” is a feeling. “We can’t automate the intercompany eliminations because the platform doesn’t support it” is a capability gap.

Second: is that capability gap in the platform or in the configuration? Call the vendor, call a second implementation partner, look at what the platform actually supports before concluding it can’t do what you need.

Third: if it’s a genuine platform gap, what is the cost and timeline of migration versus the cost of living with the gap? Migration is rarely less than 12 months and rarely less than $100,000 for a mid-market company. If the gap costs $20,000 a year in labor and the migration costs $150,000, the migration pays off in year eight. That math deserves to be done explicitly before the decision is made.


Sources

Footnotes

  1. Forrester Research. ERP Optimization vs. Replacement: A Decision Framework. 2022. Guidance on assessing platform capability gaps versus configuration gaps. https://www.forrester.com/report/erp-optimization-vs-replacement

Innuevation ERP

The architecture this article describes is built and running.

The Universal Ledger is live. The first external tester is operating on real company data. If you're evaluating the seed round or want to understand the platform, the investor portal has the full picture.

← Back to all posts

Adam Arends · March 17, 2026