Customising NetSuite without breaking your upgrades

Searching for NetSuite development usually means one of two things: you have a requirement the standard product does not seem to meet, or you have inherited an account full of scripts nobody understands. Either way, the useful question is not "who can code this?" but "what is the lightest way to meet the need, and what will it cost us to keep it working?"

This page sets out the options in the order we would try them, explains what customisation means for upgrades, and gives UK finance directors and IT managers a practical way to assess a developer or an integrator.

The customisation ladder: from configuration to code

NetSuite customisation sits on the SuiteCloud platform, which brings together several layers. It helps to treat them as rungs on a ladder and to step up only when the rung below cannot do the job.

Rung one: configuration and no-code tools

Before anything is built, a surprising amount can be achieved by setting up the account properly. The platform offers no-code personalisation of fields, forms, records and templates. Typical examples in a UK business:

• adding a field for a customer purchase order number or a project reference, and placing it on the sales order and invoice forms;
• giving the credit control team a simplified form with only the fields they use;
• creating a custom record to hold something the standard product does not track, such as equipment on hire or site access permits;
• adapting document templates so that quotes and invoices carry the wording your accountant and your customers expect.

These changes are made through the account's own tools and need no programming. Importantly, customisations built with the no-code tools of the platform are migrated automatically when NetSuite is upgraded. That single fact is the strongest argument for staying on this rung wherever possible.

Rung two: workflows with SuiteFlow

SuiteFlow is the workflow engine. According to Oracle's documentation, it is suited to no-code automation: default field values, complex approval routing, approval reminders, lead nurturing, actions on related records and the processing of saved searches.

For many UK mid-sized companies, this covers the awkward process requirements that prompt a "we need custom development" conversation. A purchase approval route that depends on the amount and the cost centre, or a reminder when a supplier invoice has been awaiting approval for too long, can often be modelled as a workflow rather than written as a script. Workflows are visible to an administrator, which makes them far easier to hand over than code.

Rung three: existing extensions

Before commissioning anything, check whether a SuiteApp already exists. SuiteApps are distributable packages built on the platform, and many common needs, from specialist reporting to sector features, are already covered by one. Buying or subscribing to an extension is rarely free, but it spreads the maintenance burden across a vendor and its other customers, and that is often worth more than the licence fee. Your integrator should be able to tell you which extensions they have seen working well and which they would avoid, without having any commercial relationship that biases the answer. Our service does not favour any publisher or product; the point of introducing you to an integrator is to give you an independent view.

Rung four: SuiteScript and bespoke modules

When the need is genuinely specific, development is the right answer. SuiteScript is the platform's scripting language, based on JavaScript, and it exists in versions 1.x and 2.x. Oracle's documentation states that it is required for custom server-side queries, web service calls, scripted portlets and bespoke applications.

A bespoke NetSuite module is typically a group of scripts, custom records, workflows and forms that together deliver a function the standard product lacks. Think of a tailored job costing screen for a contractor, a specialised returns process for a retailer, or a rules engine for pricing that reflects your contract terms. Built well, it feels like a native part of the system. Built badly, it is a liability.

The development toolkit

The tooling around SuiteScript has matured, and a competent team will use it. According to the SuiteCloud documentation, the platform includes:

The documentation also lists the SuiteCloud Developer Assistant, an AI coding assistant built into VS Code, and the AI Connector Service, which uses the Model Context Protocol (MCP) for secure AI integration. These can speed up routine coding, but they do not replace design judgement or testing. A script written quickly is still a script someone must maintain.

For a buyer, the practical meaning is this: ask whether your developer works with a framework and a proper deployment route, or edits scripts directly in the production account. The first approach leaves a trail; the second leaves a mystery.

Integrations are development too

Many requests labelled customisation are really integration work: connecting NetSuite to a web shop, a payment provider, a bank feed, a CRM or a payroll bureau. Our page on NetSuite integrations and connectors covers the options in detail, but one point deserves emphasis here because it affects code written today.

REST web services in SuiteTalk offer record operations (create, read, update, delete), access to metadata, filtering of collections, record actions and transformations, asynchronous processing, and the running of SuiteAnalytics workbook datasets and SuiteQL queries, all without deploying a script, unlike RESTlets.

The SOAP web services, on the other hand, are on their way out. The 2025.2 WSDL is the last SOAP endpoint planned, only that endpoint will be supported from version 2027.1, and SOAP will no longer be available after version 2028.2. Oracle recommends REST with OAuth 2.0 for any new integration. If your account still depends on a SOAP connector, whether bought in or written years ago, put its replacement into your plan now rather than discovering the deadline from a failed overnight job.

What customisation means for NetSuite updates

NetSuite is a cloud service that is upgraded on a regular schedule, so the question "will this survive an upgrade?" is a fair one. The honest answer depends on the rung.

• No-code customisations are migrated automatically during upgrades, according to Oracle.
• Workflows generally travel well, but should still be checked, because a changed standard behaviour can interact with a rule you wrote.
• Scripts are the area needing discipline. They rely on records, fields and behaviour that may change, so each release should be previewed in a sandbox with your scripts running against realistic data.

Our guide to NetSuite versions and editions explains how releases reach your account. The practical advice is simple: keep a sandbox, keep a regression checklist for every scripted process, and have somebody named responsible for running it ahead of each release.

Good practice: stay close to standard

The best-run NetSuite accounts in the UK share a few habits. None of them is exciting, and all of them save money.

Challenge the requirement first

A request for a change often describes a symptom. "We need a script to split invoices" may really mean "our customer wants to see project and cost centre separately", which a saved search or a form change might solve. Ask the user what outcome they need before agreeing the solution. During the implementation phase, this challenge is cheapest, because nothing has been built.

Prefer the standard process, even if it feels unfamiliar

Staff sometimes ask for the new system to replicate the old one exactly. That instinct turns a project into a chain of customisations. Where a standard process is workable, adopting it is cheaper to run and easier to train. Where it is not, document why. The common ERP project mistakes we describe elsewhere include precisely this over-customisation trap.

Document every customisation

For each script, workflow and custom record, keep a short note: what business need it serves, who asked for it, what it touches, how it was tested, and who owns it. Without this, the account depends on one person's memory, and a change of contractor becomes a risk.

Test in a sandbox, deploy deliberately

Develop and test in a sandbox account, then move changes through a controlled route rather than editing production. Keep the deployment record. If the developer proposes working directly in production "just this once", treat that as a warning sign.

Respect statutory processes

Some areas of a UK account are best left close to the vendor's standard, or to a specialist extension, because compliance rules change. Digital VAT reporting under Making Tax Digital is the obvious case; see our guide to Making Tax Digital and ERP. Payroll submissions to HMRC under RTI are another; our page on payroll software and RTI explains what to look for. A heavily customised statutory process is one that your team, not Oracle, will have to correct when the rules move.

Plan for ownership

Custom work needs a long-term owner. Agree whether your own administrator, your integrator or a separate support provider will maintain it, and check how that fits with your support and maintenance arrangements.

How to evaluate a NetSuite developer or integrator

Whether you are choosing a freelancer, a small specialist or a larger integrator, the same questions apply. We do not name providers; the service is a free introduction to an integrator suited to your project, and you remain free to compare.

1. How do you decide between configuration, an extension and code? A good answer describes the ladder above and gives examples of when they chose the simpler option.
2. Which tools do you use for deployment? Look for a framework-based route, a sandbox and some form of version control, not live edits.
3. Can I see documentation from a previous engagement? Names can be removed. What matters is whether the documentation is clear enough for someone else to use.
4. How do you test, and who signs off? Expect a test plan tied to business scenarios, with your staff involved.
5. What happens at each release? They should describe previewing releases and rerunning tests.
6. How do you handle integrations? Ask which web service they would use today and why. The right answer for a new build is REST.
7. Who owns the code? Make sure you hold the source and the documentation, not just a working account.
8. What would you not build? Someone who never advises against development is selling hours, not solving problems.

For a wider view, read our advice on choosing a NetSuite partner. If you already suspect a legacy account has gone wrong, an independent audit or project rescue is usually the first step, before any new development.

A practical way to scope a customisation request

When a department asks for a change, a short, consistent routine keeps things under control:

Applying this to every request, including small ones, stops the slow build-up of unexplained scripts that makes an account expensive to own.

Next steps

If you are planning a NetSuite project, or reviewing an existing account, start by listing the requirements that seem to need development and testing each against the ladder. You will probably find that fewer need code than expected, and that those which do are clearer to specify. To be introduced to an integrator who works in this disciplined way, see how our matching service works.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.