You want to change one field on a sales order form. Maybe add an approval step, or a report your controller has been asking for since Q1. On NetSuite, that request doesn't go to your team, it goes to SuiteScript, a proprietary scripting layer that, in del.ai's understanding, only a certified developer can touch, so the request routes to your Alliance Partner instead, and then you wait. ERP customization on NetSuite isn't a technical ceiling, it's an access architecture, and understanding that difference changes how you plan the next five years of running the system. I run del.ai, an Odoo migration company, so I have a commercial stake in how you read what follows: the comparison below is one I'm selling against.
Here is the pattern, and if you've run finance or operations on NetSuite for more than a year, you already recognize it. A field needs to change. A workflow needs a new step. A report needs a column nobody thought to ask for at go-live. None of that runs through your own team, because, in del.ai's understanding, SuiteScript, the layer that implements the change, requires a certified developer to touch it. So the request goes out as an email or a ticket to your Alliance Partner, and a quote comes back, usually priced in hours against your existing retainer. Then it queues, because that developer has other clients on the same retainer model, each with their own quotes sitting in the same queue.
What should take an afternoon, in del.ai's understanding, typically takes two to six weeks in practice, not because the change is hard, but because it has to clear someone else's calendar first. And this isn't a one-time migration cost you absorb and move past. It repeats every time your business changes, and for most operating companies that's constant. A new customer needs a different invoicing format, a new compliance requirement lands, a new approval threshold follows a board request. Each one restarts the same cycle. You're not paying once for flexibility, you're paying per request, indefinitely, for as long as you run the system.
That's the shape of the problem this article works through: what the SuiteScript model costs across a year, why the gate exists structurally rather than by any single partner's choice, and what changes once your team can make the same class of change directly.
NetSuite SuiteScript customization doesn't carry its own price tag, it draws on cost layers you're already paying for. The license runs $30,000 to $50,000 a year and buys the base modules, not the right to modify them. The layer that absorbs customization cost is the Alliance Partner retainer, $30,000 to $100,000 a year, because SuiteScript changes require a certified developer, and that developer bills hourly against your account. SuiteApps add another $20,000 to $50,000 a year for third-party connectors such as Avalara or Celigo, several of which exist because native customization can't reach that far on its own. So a one-field workflow change doesn't cost a fixed dollar amount, it costs partner hours, and partner hours are priced inside a retainer you renew every year whether you use ten hours of it or ninety. The size of the change stopped mattering; the size of the retainer never did.
Source: del.ai cost model, 2026
The reason this matters for a customization conversation specifically, rather than the general NetSuite cost conversation, is that customization draws from one layer disproportionately: the partner retainer. Your license fee is fixed regardless of how many changes you request this year. Your SuiteApp spend is fixed too, mostly, since it's paying for standing connectors rather than one-off work. It's the retainer that flexes with how often your business asks for something new, and that retainer is priced in partner hours, not in the value or difficulty of the change itself.
This is why a small change and a large one can land at similar cost. Adding one approval step and rebuilding an entire quoting workflow both go through the same intake: a quote, a queue, a certified developer's calendar. The pricing model doesn't distinguish; the billing structure does the same thing to both.
It would be easy to read the pattern above as an Alliance Partner problem, something a better partner or a tougher contract negotiation would fix. It isn't. The gate sits one level up, in how Oracle licenses the platform itself.
SuiteScript is not a general-purpose extension surface anyone with engineering skill can open. It's a proprietary scripting environment, and in del.ai's understanding, touching it in a supported way is typically restricted to a NetSuite-certified developer, a credential Oracle administers through its own certification program. Certified developers are concentrated inside Alliance Partner firms, because that's where the training investment and the certification maintenance happen at scale. So when your business needs a SuiteScript change, you aren't choosing between a good partner and a bad one, you're choosing between partners who all draw from the same certified-developer pool, because there's no common path around it that stays inside NetSuite's supported model.
That's a meaningfully different claim than saying NetSuite can't be customized, and it's worth being precise about the distinction. NetSuite can absolutely be customized. The specific mechanism is: a SuiteScript change has to be written and deployed by someone Oracle has certified, and that person's calendar and billing sit inside a retainer arrangement priced per year. A retainer priced per year costs you more the more often you need to use it, which is a fact about how the arrangement is structured, not a claim about what any individual partner intends or earns. The structure would produce the same wait time and the same queue behavior no matter which specific firm holds your retainer. In del.ai's understanding, the certification requirement is what creates the gate, not the firm sitting behind it.
This is the part of the cost stack that a contract renegotiation doesn't touch. You can shop Alliance Partners for a better hourly rate. In del.ai's understanding, you can't shop your way out of needing one.
Owning your ERP's schema and code directly changes who can make a change, not only speed, but who has it. For qualifying migrations within the signed scope document, a del.ai migration is scoped to leave you on Odoo Community, the LGPL open-source edition, with no per-seat license and full ORM and schema access on a repository your own team controls. Extension work is contracted to run through Claude Code against that repository, operated by your team, not routed through a vendor's change-request queue. This differs from a low-code tool bolted onto a licensed product: there's no separate customization layer to license or seat-gate, because the schema itself is yours to read and modify. A field, workflow, or report change becomes a pull request your team opens and merges inside your own release process, instead of a SOW that has to clear someone else's calendar first. The gate moves from a vendor's certification requirement to whatever review process you choose to run internally.
Source: del.ai migration methodology, 2026
It's worth being specific about what this is not. Odoo Enterprise ships its own low-code customization tool as a paid feature, gated behind Enterprise's per-seat license. Del.ai doesn't deploy Enterprise, and doesn't sell access to that tool. What del.ai deploys is Odoo Community, the free, LGPL-licensed edition, with source-level access to the actual schema and ORM underneath it. (Odoo's own source repository publishes the license: LGPLv3, no per-seat fee.) The customization mechanism isn't a UI layer that abstracts the code away from you, it's the code itself, readable and editable by your own team through Claude Code, which reads your repository, your data model, and your existing workflows before it writes anything.
That distinction is the whole point of the model. A low-code tool still sits between you and the schema, and still gates what you can do to whatever the tool's designers anticipated. Direct schema and ORM access has no such ceiling: if Python and PostgreSQL can express it, your team can build it, without asking a vendor's permission or paying a vendor's hourly rate to get it built.
Not everything a buyer worries about losing in a migration is a customization. It's worth separating two things people tend to talk about as one.
Configuration is adjusting what a platform already does within its existing data model: changing a field's label, reordering a workflow's approval steps, turning a report filter on or off. None of that touches the schema or the underlying logic; it's using controls the system already ships with. Customization is different in kind, not degree: it means extending the schema itself, adding new logic the platform didn't ship with, building something that wasn't there before.
Checked module by module against a live Odoo instance, most of what looks like a NetSuite feature gap turns out to be a configuration difference rather than a genuine capability loss. The system already does the thing; it needs to be set up the way your team is used to. A smaller set of cases are real gaps, where NetSuite's behavior depends on schema or logic Odoo doesn't ship natively, and those get named specifically, before a scope is signed, on what amounts to a short disqualifier list: rebuild it as a custom extension, drop it if it isn't load-bearing, or stay on NetSuite for that particular function if none of the above works.
We don't promise full parity, and no honest migration vendor should. What we do is name the specific gaps before you sign anything, so the cases that need a real answer get one in the scoping conversation, not six months after cutover when it's expensive to discover.
Picture this as a modeled scenario, not a result del.ai has observed, since del.ai has zero completed migrations to date. A manufacturer six months past go-live needs a new approval step on purchase orders over $10,000. On the NetSuite path, that request goes to the Alliance Partner as a change order, gets quoted against the existing retainer, and queues behind whatever else that partner's calendar holds that month, typically landing, in del.ai's understanding, two to six weeks out. On the modeled del.ai path, for qualifying migrations within the signed scope document, the same request is scoped as a same-day change: the client's team opens Claude Code against their Odoo Community repository, writes the approval rule into the existing workflow logic, tests it, and merges it, no SOW, no partner queue. The migration itself is priced at ~$50k, with hosting from ~$2k a month; neither figure moves when a workflow changes, because there's no vendor left standing between the request and the fix.
Source: del.ai cost model, 2026
Lay the two paths next to each other and the difference isn't speed for its own sake, it's where the decision sits. On the NetSuite path, the decision to make the change and the ability to make it live in two different places: your team decides, the partner executes, and the gap between those two moments is where the wait happens. On the modeled del.ai path, the decision and the ability to act collapse into the same team, because the schema, the code, and the people who understand your business rules are no longer separated by a procurement step.
None of this describes something del.ai has shipped and measured. It describes the mechanism the migration is designed to produce, and the reason it's designed that way is structural: once your team is working directly against an owned repository, there's no certification gate left to route the request through.
This isn't the right frame for every NetSuite customer. It's built for a specific one: mid-market companies spending $120,000 or more a year on NetSuite, who are already carrying an Alliance Partner retainer for the ordinary flow of workflow and field changes, and who are tired of every change to the system running through someone else's calendar.
If that's not your situation, the SuiteScript model may be the right tradeoff for where you are. Plenty of companies value having a certified partner own that surface area so their internal team doesn't have to. This argument is for the companies where that tradeoff has stopped paying off, where the retainer keeps renewing and the queue keeps being the bottleneck.
There's one more piece of this worth closing on, because it's the same argument in a different form: what happens if del.ai isn't around in five years. The code your team customizes is LGPL Odoo, the same code you'd keep running if del.ai disappeared tomorrow. Nothing about the customization story depends on del.ai staying in business, because the schema access and the ownership were never ours to revoke in the first place. That's not a side benefit of the model, it's the same point the rest of this article has been making: customization stopped being a vendor transaction the moment the code became yours.
Built for mid-market companies on NetSuite spending $120k+/yr who are already paying an Alliance Partner retainer every time a workflow or field needs to change.
30 minutes. Bring your last three SuiteScript change requests and we'll walk through what each one cost, and what the same request looks like once your team owns the schema directly. No pitch. You'll leave with the real math for your own stack.
Sources
1. Odoo S.A., "Licenses," Odoo 17.0 documentation, 2026, Community edition licensed LGPLv3. ↗