This perspective was originally published September 1, 2026. For current release milestones, see the updated planning guide.
Go shopping for an ERP today and you'll find a recurring theme as you scroll through endless sponsored product pages and curated content reviews.
"Eight better ERP systems than NetSuite"
"Top NetSuite competitors for 2026"
"Silicon Valley's newest NetSuite killer".
You'd think NetSuite instances were being hunted into extinction based on the number of articles written about the platform's imminent demise.
In case you're worried about this being an Oracle NetSuite cheerleading piece, I can assure you it's not. We've managed hundreds of implementations and projects on and for NetSuite and are well aware of the limitations and frustrations around installing, let alone operating an instance.
We wrote this to help instance owners review how and why NetSuite got to where it is, quirks and all. Then, most importantly we'll explore how current instance owners can successfully adapt to NetSuite's pivot to AI, without worrying about disrupting operations or burning it all down in the name of first principles.
How customers dug NetSuite's moat
NetSuite was founded in 1998 and was one of the first SaaS business applications and one of the few cloud-first ERPs of its time. And while its architecture was key to its meteoric rise to prominence, it isn't what dug the moat that protects it today.
What made NetSuite different from comparable systems was the decision to give its customers a development platform to customize and complete the “last mile” of their business processes. SuiteScript for code. SuiteFlow for workflow logic. SuiteBuilder for custom records and fields. Saved searches, scripted records, user event triggers, a marketplace of certified SuiteApps.
While legacy giants required software engineers to write code in their proprietary language, NetSuite encouraged owners to use (semi-proprietary) SuiteScript, based on JavaScript, to tweak and tune, configure and customize their instances.
And so they did.
Proprietary business logic, contractually mandated conditional fields for specific customers, multi-level approval routing for expenses, a scheduled script that reconciles historical ledger sequences that nobody owns or knows where it started.
Recently, we mapped more than 5,000 customizations in a single instance. That number isn't just a measure of technical debt; it's also a measure of accumulated institutional decision-making, most of it undocumented, misunderstood, and precisely what makes the system unreplaceable.
This is the Oracle NetSuite moat. Built by customers, for customers, one script at a time. Often, in the moment to patch or plaster over an issue, and more often than not, forgot to keep the blueprints of the work being done.
Why NetSuite customers stay
Oracle NetSuite doesn't publish current retention figures. The last number that circulated widely was 92%, reported around 2015 when NetSuite crossed $741 million in revenue with roughly 30,000 organizations on the platform. That was 10 years and 14,000+ or so customers ago.
I suspect most of the NetSuite killers prefer to focus on new ERP users, rather than replacement contracts, especially for older instances. Primarily because the replacement thesis assumes a buyer's main concern is optimizing for velocity. Someone who feels the drag of daily operations and will happily trade disruption of their business process for a faster horse.
In reality, admins that are most frustrated with software performance are usually not the financial buyer. That decision sits with a CxO or a VP of business systems, and the payoff structure they face is asymmetric. A migration that goes well produces a system that works, initially as good as, and then eventually better than, the old system. A migration that goes badly produces a failed audit, a quarter of manual workarounds, and then a LinkedIn post about being Open to Work.
The asymmetry
Nobody at that level gets promoted for successfully replacing a slow ERP that was already working. Plenty of people have been fired for trying. That's why “do nothing” has been such an attractive option for the majority of admins; they're going to be forced to face some difficult choices in the very foreseeable future.
Ready or not, AI is coming to your instance
Native AI agent capabilities are expected in Oracle NetSuite later this year. Recent deprecations like SOAP web services, legacy authentication methods, and pre-2.1 SuiteScript remove the surfaces that agents could not reliably operate through and replace them with ones they can.
The best thing a business can do right now is immediately start compiling your knowledge resources. You can categorize them into what we call “The 3 Big Knows”. These are the immediate pieces of information you need to gather as quickly as possible to inform your strategy.
- Know what you have. Not a rough sense of it, a full inventory: every script, feature, bundle, workflow, custom record, saved search, and how they're all used. Everything that is in the account, whether active or not.
- Know how it runs. Which scripts execute under which SuiteScript runtime, which ones carry the ambiguous 2.x annotation and are therefore not on 2.1 at all, and which will break when the runtime moves.
- Know if it stays. Which customizations serve a live business process, which duplicate something the platform now does natively, and which are scar tissue from a problem that stopped existing in 2021.
These have value whether the AI you use eventually arrives from Oracle NetSuite, from a third party, or from your own team. This isn't just work for AI, it's good housekeeping. It's the prerequisite for AI work. We can't imagine operating on an instance without it.
Why we built Turbobase
Whether you choose to use a platform like Turbobase, an external agency, or an internal team, make sure it's a complete accounting of your entire system. How you go through that initial discovery process isn't as important as making sure it's a comprehensive view, compiled in the shortest amount of time possible.
The benefit of using Turbobase is that a single administrator or consultant has the additional capacity to manage this work themselves. They can diagnose failures, track customizations, identify which are safe to retire, then build automation that used to sit in their backlog. They even have the tools to author apps in and outside of SuiteScript.
The inventory is only the first step. On the client instance mentioned earlier, we used Turbobase to surface those 5000+ customizations in less than a day. Years of different teams, processes, and integrations laid out in hours, along with what each one was actually doing. A critical starting point, which allowed us to build a single source of operational truth we refer to as a Knowledge Base.
Your Knowledge Base updates as you go, so the record of what changed stops being a separate job somebody has to remember to do.
The part most people have backwards
Both sides treat the accumulated complexity as the crux. The startups point at the mess and call it the reason to start over. The incumbents point at the same mess and call it the reason you can't.
The real question
The “hair-ball” was never the question. The question is whether anyone can read it. A company that understands what's inside its instance can make either choice well, replace or extend, and defend the decision afterward. A company that doesn't is guessing in both directions.
The NetSuite killers aren't wrong that these systems are messy. What they're missing is that every instance, whether it's one of theirs or NetSuite's, is born fresh, clean and full of promise. They haven't operated accounts long enough to truly understand what these “messes” are made of. It isn't bad architecture. It's twenty years of answers to questions nobody wrote down, and replacing the system that holds them does not recover them. It just relocates the not-knowing.