Discover 10 signs it's time for a NetSuite reimplementation. A guide for long-term customers seeking system optimisation and business process improvement.
Reimplementation is the option nobody wants to consider, and that reluctance is usually correct. Rebuilding a NetSuite account is expensive, disruptive and rarely the right answer to a specific problem.
It is occasionally the right answer to a structural one. Where the foundations were set badly, no amount of incremental improvement reaches them, and businesses that keep paying for adjustments to a fundamentally wrong configuration eventually spend more than a rebuild would have cost.
This article sets out the signals that distinguish a structural problem from a fixable one, what reimplementation actually involves, and why the honest answer is usually something less drastic.
This is the clearest structural signal and the hardest to fix incrementally.
NetSuite separates the account from the analytical dimensions, meaning subsidiary, department, class and location. Where that structure was designed properly, analysis can slice across any combination without the chart of accounts having anticipated it.
Where analytical detail was instead pushed into the account code, producing hundreds of accounts distinguishing revenue by region and product and channel, the structure answers the questions it was designed for and nothing else.
The test is whether you can produce margin by product within a region for a given period without exporting anything. Where you cannot, and where the reason is the structure rather than a missing report, you have hit a foundation problem.
Changing this after go live is possible and unpleasant, because it affects every historical transaction and every report built on top. It is the single most common reason businesses genuinely need a rebuild rather than a repair.
Related and equally structural.
Businesses that implemented as a single entity and have since added subsidiaries sometimes find the original configuration makes that awkward. Businesses that implemented several entities and have since consolidated find the reverse.
The specific difficulties are around consolidation, intercompany transactions, currency handling and whether reporting can be produced at the levels the business now manages.
Some of this is fixable through configuration. Where the underlying subsidiary structure was set up in a way that does not reflect the legal or operational reality, it is generally not, because subsidiaries carry historical transactions and cannot simply be reorganised.
The question worth asking is whether the structure reflects how the business is actually run and reported today, or how it was run when the system was configured.
A different kind of structural problem, arising from accumulation rather than from original design.
The symptoms are recognisable. Nobody can explain what a given script or workflow does or why it exists. There are customisations nobody will remove because nobody is sure they are unused. Changing one business rule requires changing several objects, and somebody always misses one. Releases are approached as a risk to survive rather than an opportunity.
This is genuinely serious because it means the system has stopped being adaptable, which is the entire reason for having a platform rather than a fixed application.
The important distinction is that this is frequently fixable without a rebuild. A deliberate programme of reviewing every customisation, establishing what it does, removing what is unnecessary and documenting what remains is considerably cheaper than reimplementation, and it addresses the actual problem.
Reimplementation only becomes the answer where the accumulation is so extensive that untangling it costs more than starting again, which is a high bar.
Where significant parts of the operation run on spreadsheets, email and informal process despite the system being available, something is wrong. The question is what.
Sometimes the configuration genuinely does not fit how the business works, which usually traces back to inadequate discovery during the original implementation. That is a structural problem in the sense that the design was wrong.
Frequently, though, the cause is different and cheaper to fix. People were never trained properly. A report was never built so somebody built a spreadsheet. Permissions prevent somebody seeing what they need. A process is awkward because of a configuration decision nobody has revisited.
The diagnostic step is to take the largest workarounds and establish why each exists. Where the answer is that the system cannot do it, that is a design problem. Where the answer is that nobody built it or nobody was shown, that is considerably cheaper.
Reporting is the most common source of dissatisfaction with a NetSuite investment and the least common reason for a rebuild.
The reason is that reporting is almost always under built rather than impossible. During implementation the priority is transactions flowing correctly, reporting is delivered to a minimum standard, and the intention to return to it does not survive the project closing.
People then meet their needs with exports, and the spreadsheet becomes the trusted version. That feels like a system limitation and is generally a gap.
The test is whether the underlying data supports the question. Where it does and the report simply does not exist, this is a report writing exercise rather than anything structural. Where the data genuinely cannot answer it, you are back at the dimensional structure question.
Businesses that conclude they need a rebuild because reporting is poor are usually wrong, and the correct response returns most of the value for a fraction of the cost.
Businesses change more than their systems do, and the gap accumulates.
A business that has moved from wholesale to direct to consumer, added manufacturing, expanded internationally or shifted to a subscription model may find its configuration reflects the earlier shape.
Departments that were restructured years ago still appear in every dropdown. Approval limits predate several pay reviews. Item categories reflect a product range that has changed. Locations exist for sites that closed.
Most of this is configuration housekeeping rather than a structural problem, and it is fixable by somebody with the time and the mandate to do it.
It becomes structural only where the fundamental transaction flows no longer suit the business, for instance where an inventory business became a services business and the whole revenue model changed. That is rare and it is real when it happens.
Occasionally the problem is not the configuration but what is in it.
Duplicate customers with transactions attached to both. Items created inconsistently over years with no naming convention. Historical transactions coded to dimensions that were later repurposed. Balances that have been adjusted rather than reconciled for long enough that nobody knows what is actually correct.
Data can usually be cleaned in place, and it is a genuine project rather than an afternoon.
The threshold for reimplementation is where cleaning in place would take longer than migrating a cleansed subset into a fresh account, which occurs mainly where the volume is large and the quality is poor throughout rather than in patches.
Even then, the honest comparison includes the fact that a rebuild requires migrating the same data, so the cleansing happens either way.
NetSuite is a cloud platform and updates twice a year, so version lock in the traditional sense does not apply the way it does to on premise software.
What does happen is that heavily customised accounts adopt new functionality slowly, because each new feature has to be assessed against existing customisations. Businesses in this position frequently end up maintaining a custom solution to a problem Oracle solved natively two releases ago, at their own expense.
The signal worth watching is whether release notes are read at all, and whether anything from a release has been adopted in the past two years. Where the answer is no, the account is drifting further from standard every cycle.
This is a reason to review and reduce customisation rather than to rebuild. Rebuilding without changing the practices that produced the accumulation simply restarts the same process.
Some accounts were never completed rather than having degraded.
Modules licensed and never configured. Phase two that never arrived. Processes that went live in a temporary state and stayed there. Integrations that were meant to be automated and are still manual.
This is common and it is not usually a rebuild. It is unfinished work, and finishing it is what implementation rescue exists for.
The distinction is whether the foundations are sound. Where the chart of accounts, dimensional structure and transaction flows are correct and the problem is that the build stopped early, completing it is straightforward. Where the foundations themselves were set badly, completing on top of them compounds the problem.
The least technical signal and one of the most predictive.
Where no one is responsible for the account, small problems accumulate, requests queue, workarounds proliferate and the configuration drifts from the business.
An account in that state can look like it needs a rebuild when it actually needs an owner. Six months of consistent attention from somebody competent frequently resolves what appeared to be a systemic failure.
The test worth applying before considering anything larger is whether the account has had sustained ownership. Where it has not, that is the thing to fix first, and the answer to what happens after that is usually different from the answer before.
Whether that capability sits internally with a defined administrator or externally through managed services matters less than that it exists.
A financial signal rather than a technical one.
Where the annual cost of maintaining, changing and working around the system is rising rather than falling, and where each change costs more than the last because of what it has to work around, the trajectory itself is the finding.
The useful exercise is to count what the current arrangement costs across a year. External consulting, internal time on workarounds, reporting assembled manually, release testing, and the cost of changes that were needed and not made because they were too expensive.
Compare that against a rebuild including its disruption, and against a remediation programme.
Most businesses that do this properly find remediation is the better economics. Some find it is not, and those are the ones for whom reimplementation is genuinely correct.
It is worth being clear about the scale, because it is frequently underestimated.
A rebuild is a full implementation. Discovery, design, configuration, data migration, testing, training and cutover, with the same demands on internal people as the original project.
The differences are that you know the platform, which helps, and that you are migrating from a system with more complexity than the one you originally migrated from, which does not. Historical data, customisations that need reproducing or deliberately abandoning, and integrations that have to be rebuilt.
There is also an organisational cost. People who lived through one implementation are less enthusiastic about a second, and the change management is harder rather than easier.
None of that makes it wrong. It makes it a decision that deserves the same rigour as the original one.
The step that resolves most of this is an independent assessment of the current state.
What is actually configured, what is customised and why, what is used and what is not, where the workarounds are and what each exists to compensate for, and whether the foundational structures are sound.
That assessment is uncomfortable and it is the only sound basis for deciding. It separates the structural problems, which are few, from the accumulated ones, which are many and cheaper to fix.
The common finding is that some reconfiguration is needed, some customisations should be removed, some reporting should be built, some of the problem is training, and the foundations are adequate.
Where that is the finding, remediation returns most of the value for a fraction of the cost and disruption.
Reimplementation is occasionally right and is usually the wrong conclusion drawn from real symptoms.
The signals that genuinely point to it are foundational, meaning a dimensional structure that cannot answer your questions, an entity structure that does not match the business, or accumulation so extensive that untangling costs more than starting again.
Everything else, including poor reporting, workarounds, unfinished implementation and drifting configuration, is remediation work.
Our piece on maximising the value of a NetSuite investment covers that remediation, and implementation rescue covers the situation where the original build never finished properly.
If you are weighing this up and would like an independent view of what your account actually needs, get in touch.
