NetSuite is Changing in 3 Places at Once: SuiteScript 2.1, the End of SOAP for integrations, and NetSuite Next

NetSuite is changing in three places at once, and the impact reaches well beyond integrations: SuiteScript 2.1 is becoming the standard scripting runtime, SOAP web services will be switched off for good with the 2028.2 release, and the NetSuite you log into is getting a new look and a new AI brain under the name NetSuite Next.

If you run NetSuite and anything talks to it, whether that is your ecommerce store, your CRM, your WMS, a bank feed or a stack of custom scripts, this post is for you. I wrote it the way I would explain it to a client over a call: what is changing, what it means for your integrations and the rest of your scripts, what to do first, and why Oracle is doing all of this in the first place.

Here is the route we will take:

1. SuiteScript 2.1. What changed in the platform’s scripting layer, and why it matters for every script in your account, from integrations to business rules and custom screens.
2. The end of SOAP for integrations. The dates, the technical architecture on each side, and how to move to REST in a sensible order.
3. NetSuite Next. The new navigation, the new dashboards, and the honest answer to “why is this happening?”

A quick note on tone. None of this is a reason to panic, because the deadlines are real but not tomorrow. All of it is a reason to start. The teams that begin their inventory now will migrate calmly, and the teams that wait for 2028 will do it in a rush, over budget, with the business watching.

1. SuiteScript 2.1: the change reaches every script in your account, not just your integrations

SuiteScript is how NetSuite gets customized, so when NetSuite changes the scripting runtime, the change reaches every script in your account, whether it connects to another system or never leaves NetSuite.

Here is the short version of what happened. SuiteScript 2.0 runs on the ECMAScript 5.1 language level. SuiteScript 2.1 keeps the 2.0 API but adds support for the ES2019 language level, on a different runtime engine. It shipped back in 2020.1, and 2.0 and 2.1 scripts can run side by side in the same account. SuiteScript 1.0 sits on the old Rhino engine, which is widely described as deprecated. The direction is obvious: modern language, modern runtime, fewer legacy engines to maintain.

Scripts do far more than integrations

Integrations are only one use of SuiteScript. Most accounts also run a large amount of script that never talks to an outside system, and all of it is in scope.

• Integrations into NetSuite: RESTlets and Suitelets receive payloads from your store, your CRM or your middleware, and Map/Reduce or scheduled scripts process them.
• Integrations out of NetSuite: user event and scheduled scripts push records to external systems, usually through N/https, and often with retry logic someone wrote years ago.
• Business rules: user event scripts validate records, set default values, calculate commissions and enforce approval rules.
• Automation: scheduled and Map/Reduce scripts run period-end jobs, mass updates, data cleanup and reminders.
• Screens and forms: client scripts control what users see and can enter on a form, and Suitelets sit behind custom pages and forms.
• Inside bundles: the SuiteApps and connectors you installed also ship scripts, and they have their own versions and their own upgrade schedules.

The risk is rarely the big, obvious syntax change. It is the small behavior differences. Oracle’s own 2.0 versus 2.1 differences page lists examples: a trailing comma in a JSON string is accepted in 2.0 but throws an error in 2.1, and the default format of a converted date string changes from long to short. Those quiet differences can break any script, not only integration scripts. A partner system sends slightly sloppy JSON that 2.0 forgave. A user event script formats a date string that suddenly looks different, and a commission calculation or an approval rule goes wrong. Nothing crashes in testing, and then a Friday batch fails.

What to review, touchpoint by touchpoint

Where I would start

1. Inventory. The script list in your account shows the API version of every script. Sort it, then mark which ones touch an integration and which ones carry core business rules. Both go first.
2. Change the version and test in a sandbox. For 2.x scripts the move is usually a change to the @NApiVersion tag plus testing, and the real work is the testing. Use production-shaped data, not tidy sample records.
3. Treat 1.0 scripts as rewrites, not edits. They are the ones with the longest runway of neglect and the most hidden business logic.
4. Plan it together with the SOAP work in the next section. Your integration scripts are involved in both changes, and finding them once is cheaper than finding them twice.

2. The end of SOAP for integrations: the dates, the architecture and the move to REST API

SOAP web services will be removed from NetSuite with the 2028.2 release, and every SOAP integration still running at that point will stop working. Oracle states this plainly in its SOAP Removal Plans FAQ, and the replacement it names is SuiteTalk REST web services.

The dates that matter

SOAP is not going away in one day. It closes in stages, and the early stages already affect what you are allowed to build.

The early stages limit what you can build. Only the last one switches existing integrations off.

Two rules sit behind the stages. Each SOAP endpoint is supported for three years after its release, and with every new NetSuite release the oldest endpoint is switched off. The 2025.2 endpoint is the last one Oracle plans to ship, so it also has the longest life, through 2028.2. If any of your integrations still point at an older WSDL version, moving them to 2025.2 is the cheap first step. Be clear with your team about what that is, though: it buys time, and it is not a destination.

SOAP and REST, side by side

The two are different in kind, not just in format. SOAP is a contract-first, operation-based design: you download a WSDL and its schemas, generate client code, and call named operations such as add, update, search and getList. REST is resource-based: records live at URLs, and plain HTTP verbs act on them.

Three things this means in practice

• Lighter and friendlier to modern tools. A JSON call is smaller and simpler than an XML envelope, and nearly every modern middleware platform, low-code tool and AI agent framework speaks REST natively. SOAP is the odd one out now.
• Not always one to one. A SOAP search or getList usually becomes a SuiteQL query or a filtered record call. A SOAP upsert usually becomes a PUT using an external ID. Some operations have no clean equivalent yet. Oracle’s own FAQ tracks gaps such as legacy tax support, so check the upgrade guide for the exact operations you use.
• A better security story. OAuth 2.0 uses short-lived access tokens, which is a more defensible position than long-lived credentials sitting in a config file. That matters more than it sounds, and I come back to it in the last section.

One more point that catches people out. If a partner application connects to NetSuite over SOAP on your behalf, Oracle’s advice is to ask that partner for a REST-based version. You may not own the code, but you do own the deadline.

Moving to REST: what to do now, in order

Since 2026.1, Oracle’s position is that all new integrations should use REST web services with OAuth 2.0, and from 2027.1 you will not be able to build new SOAP integrations at all. So the question is no longer whether to migrate. It is how to do it without breaking the order-to-cash flow that your finance team depends on.

This is the sequence I would follow.

1. Find every SOAP caller. This is the step people underestimate, because the integration that nobody remembers is the one that fails in 2028. Check your integration records and token usage, ask each department what is connected to NetSuite, and list every partner application. If your account has Application Performance Management, it includes a SOAP Web Services Analysis page with an API version usage portlet that shows what is still calling SOAP and on which endpoint version.
2. Lock in runway. Move anything on an older WSDL up to the 2025.2 endpoint. It is usually a smaller change than a full migration, and it gives you support through 2028.2 while you plan properly.
3. Map each SOAP operation to its REST equivalent. Use Oracle’s SOAP to REST upgrade guide as the reference. In most integrations the mapping is predictable: reads become record GETs or SuiteQL queries, creates become POSTs, updates become PATCHes, and upserts become PUTs keyed on an external ID. Flag anything with no clean equivalent now, not in month six.
4. Set up OAuth 2.0 properly. Create the integration record, give the integration role only the permissions it needs, and plan how secrets and certificates are stored and rotated. This is also the moment to retire shared logins and old credentials.
5. Rebuild and test in a sandbox with real data. Pay attention to the things that differ in practice: pagination on large result sets, concurrency and rate limits, error response shapes, date and time zone handling, and sublists or custom fields that come through differently.
6. Run old and new in parallel where you can. Compare results record by record for a few cycles. For financial flows such as invoices, payments and journal entries, reconcile totals before you trust the new path.
7. Cut over one integration at a time. Start with the lowest risk, leave the most critical flow for last, and keep a rollback plan until the new path has survived a month end.
8. Switch off what you replaced. Disable the old tokens and remove SOAP access, so a forgotten connection does not keep running quietly beside the new one.

A few honest warnings

• Budget for testing, not just coding. The code change is the small part. Proving that nothing changed in your financial data is the real work.
• Do not recreate your SOAP design in REST. If your SOAP integration pulled data in a dozen chatty calls, a single SuiteQL query may replace all of them. A straight translation works, but a redesign often performs better and costs less to run.
• Do the SuiteScript 2.1 work in the same project. The RESTlets and scheduled scripts around your integration are touched by both changes. Doing them together means one round of regression testing instead of two.
• Do not wait for the last release. Everyone who waits will be competing for the same consultants and the same sandbox time in 2028.

3. NetSuite Next: a new look, new navigation, and the real reason behind all of it

The new interface is the change your users will notice first, but it comes from the same forces as SuiteScript 2.1 and the SOAP shutdown. Once you see those forces, the three changes stop looking like three separate annoyances and start looking like one plan.

What is changing on screen

Oracle introduced the Redwood Experience at SuiteWorld 2024 and has been widening it release by release since. It is enabled by default for newly provisioned accounts, and existing accounts can switch it on from their appearance preferences. NetSuite’s own description calls it much more than a visual refresh, and the differences are easy to feel on day one:

• A different look and feel. New colors, icons and fonts, and a cleaner page layout across records, lists and dashboards.
• Different navigation. Redwood restructures navigation around a persistent global search, a Create (+) menu and consolidated menus, instead of the old role-based centers and tab bars.
• New dashboards. The home dashboard and its portlets are being rebuilt in the same design language.
• AI built in. Under the name NetSuite Next, Oracle is adding a natural-language assistant called Ask Oracle, AI Canvas for scenario planning and agentic workflows. Partner coverage reports these are included in existing licenses and rolling out through 2026, North America first. Check what has reached your account before you promise anything to your own users.

Why this is happening

Oracle’s public wording is about modernization, so what follows is my own reading, built from what Oracle has published and from the pattern across all three changes. I think there are three reasons, and they reinforce each other.

1. Security. Old protocols and old runtimes are attack surface. Once a SOAP endpoint reaches end of life, it receives no updates, patches or security support. OAuth 2.0 with short-lived tokens is a stronger default than long-lived credentials. A single modern scripting runtime is easier to harden than several generations running side by side. A newer front end built on current web frameworks is easier to defend than a decades-old page model. Every legacy layer that is retired is one less thing to patch, monitor and explain to your auditors.
2. Efficiency. Oracle has been maintaining two web service APIs, three generations of SuiteScript and two user interfaces at the same time. That is expensive, and the cost shows up as slower improvements for everyone. Oracle has said that future API investment goes into REST, and the pattern is the same elsewhere: pick the current technology, move people onto it, and stop paying to carry the old one. The result for customers should be faster, lighter and more reliable behavior, plus new features arriving sooner.
3. AI. This is the one that explains the timing. AI assistants and agents work best on clean, current foundations: REST and JSON they can call, scoped OAuth permissions they can be limited by, a modern scripting layer they can extend, and an interface designed around search, a Create menu and conversational prompts rather than menu hunting. An AI feature bolted onto SOAP, 1.0 scripts and the classic UI would be slow to build and awkward to trust. By clearing the old layers first, Oracle is making sure that AI capabilities slot in smoothly. If your integrations and scripts are already on the new stack, you pick up those capabilities with little rework. If they are not, you will be doing migration and AI adoption at the same time.

What to do about the UI change

1. Turn Redwood on in a sandbox and walk each role through its daily tasks. Do this before your users meet it by surprise.
2. Audit custom UI work. Suitelets, injected CSS, client scripts that depend on page structure and any browser-based automation tied to the classic layout may need rework, because Redwood uses new page structures and styling.
3. Update your training and documentation. Screenshots, SOPs and onboarding guides go stale quickly when the menus move.
4. Treat the classic UI as temporary. Oracle keeps extending Redwood to more pages and features each release, so plan on the basis that it will be the only option eventually, and check each release note for your account.

Putting it together

SuiteScript 2.1, the end of SOAP and NetSuite Next are one story told in three chapters: retire the legacy layers, move everyone onto a current and more secure stack, and make room for AI to work inside the business rather than beside it. The deadlines give you time, but only if you use it.

If you do nothing else this quarter, do these four things:

• List every integration and script that touches NetSuite, with its owner, its SuiteScript version and whether it uses SOAP.
• Move any integration on an older SOAP endpoint to the 2025.2 endpoint to secure support through 2028.2.
• Pick the first integration to rebuild on REST with OAuth 2.0, and test it in a sandbox with production-shaped data.
• Turn on Redwood in a sandbox and have each role try its daily work.

This is the kind of work we do every week at Excelym. As a NetSuite Alliance Partner, we help teams audit what is connected, plan the order of the migration, and rebuild integrations without disturbing month end. Excelym.IO, our NetSuite integration platform, exists for exactly this moment, when connecting NetSuite to everything else needs to be reliable, secure and ready for what comes next. If you want a second pair of eyes on your integration inventory, talk to us before the deadlines start talking to you.

Sources

• SOAP Removal Plans FAQ, Oracle NetSuite Help Center
• Support for Existing WSDL Versions, Oracle NetSuite Help Center
• SuiteScript 2.1 and Differences Between SuiteScript 2.0 and SuiteScript 2.1, Oracle NetSuite Help Center
• SuiteScript Versioning Guidelines, Oracle NetSuite Help Center
• SuiteScript 2.1 delivers modern JavaScript syntax, NetSuite blog
• User Interface release notes (Redwood Experience theme), Oracle NetSuite Help Center
• Redwood in NetSuite, NetSuite

Figures and dates were checked against the sources above on 2026-11-09. Oracle updates its SOAP removal plans between releases, so confirm the current schedule in the SOAP Removal Plans FAQ before you commit dates to a project plan.