SuiteScript 2.1 / Transition overview

NetSuite's SuiteScript 2.1 transition.
What to do next.

Start with a clear account assessment. Then plan conversion and testing around the business processes your scripts support.

By Jack Ring · Published October 15, 2026

Understand the notice

A starting point.
Not an effort estimate.

If NetSuite is showing you a notice to update scripts to SuiteScript 2.1, start with an assessment of your account. The notice identifies older scripting versions. It does not tell you which business processes depend on them, who can change them, or how much conversion work is required.

My clients have been asking the same question: what does this mean for our system? My first step has been to inventory scripts and connect them with installed bundle information so we can separate custom development from vendor-maintained applications.

Oracle’s published release plan

The transition timeline

Plan around your account’s release schedule. These milestones describe NetSuite releases, not one calendar date shared by every account.

  1. 2026.2

    The standard changes

    SuiteScript 2.1 becomes the standard scripting model for new and existing scripts.

  2. 2027.1

    1.0 support narrows

    SuiteScript 1.0 support covers critical issues only. Other issues require conversion first.

  3. 2028.1

    Runtime defaults change

    No 1.0 deployments in new accounts; existing accounts can still deploy them. 2.0/2.x runs as 2.1 by default.

  4. 2028.2

    Transition milestone

    All new and existing scripts must use SuiteScript 2.1 under Oracle’s published plan.

Include scripts annotated @NApiVersion 2.x in your review. That annotation does not establish that the source has been updated to 2.1. Oracle expects legacy version and annotation support to be removed in 2028.2; documented product exceptions still need individual review.

Choose the right migration path

Two different starting points.

SuiteScript 1.0 → 2.1

A different API structure. Review API calls, script entry points and data handling. Some scripts also need changes to how they process larger workloads.

SuiteScript 2.0 / 2.x → 2.1

Already uses the modular API. Some scripts require limited changes, but changing the annotation alone does not prove correct behavior. Review compatibility and test the business process.

Oracle provides account preferences for testing 2.0 and 2.x server scripts in the 2.1 runtime in Sandbox. These do not replace source updates or client-script testing.

Responsibility before conversion

Not every script is yours to rewrite.

An account may include code from your developer, Oracle SuiteApps, payment providers, EDI applications and past implementations. The employee Owner field is a clue, not proof of who maintains the code.

Your custom code

Confirm who will review and convert editable customizations, including their shared modules.

Vendor applications

Request the provider’s supported migration plan for locked or vendor-maintained code.

Unclear or obsolete code

Investigate current use and dependencies before assigning ownership or approving retirement.

Tools and judgment

Conversion assistance.
Business verification.

Oracle publishes a SuiteScript Upgrade skill through its SuiteCloud tooling. It can analyze code, propose conversions, explain API differences, and check converted files for common migration problems.

That is different from an account inventory. Inventory tools help find and classify scripts; conversion assistance works on code. Neither establishes that an order approval, invoice process, or external integration still works. Oracle explicitly distinguishes static validation from functional testing.

You can begin an inventory with NetSuite's script list filters or a saved search. The important output is a plan that assigns responsibility and identifies the affected processes.

The working sequence

From a notice to verified changes.

  1. Inventory

    Find scripts, deployments, source files and installed bundles.

  2. Assign

    Confirm the maintainer, business purpose and process owner.

  3. Convert

    Analyze the code and make the required compatibility changes.

  4. Test

    Verify business scenarios, roles, integrations and error handling in Sandbox.

  5. Deploy

    Release approved work in groups, retain rollback options and monitor results.

Plan critical processes and vendor dependencies early. Use a manageable, lower-complexity pilot to establish the conversion and testing process. Keep required compatibility work separate from optional redesign.

Next guide

Turn the notice into a plan for your account.

Continue with the companion assessment guide: ownership, dependencies, vendor updates and business testing.

Read the assessment guide

Oracle references

Guidance reviewed October 15, 2026. Release milestones reflect Oracle's published plan and may change. For product areas with documented version exceptions, follow Oracle's specific requirements.

A practical next step

Questions about your scripts? Call me.

You don't need to know which scripts need changing before we talk. Tell me what NetSuite is showing you, and we can work out where to start.

Call Jack: (724) 816-1000 Send a message

My direct number. You don't have to be an existing client to call.

Back to all insights