You are browsing
79Consulting
.png)
SuiteScript can be one of the most valuable parts of a NetSuite account and one of the easiest to lose track of. Scripts change hands, documentation gets thin, and the business keeps relying on logic that only a few people understand.
The hard part is rarely in finding the code. It is knowing what each script touches, who owns it, what depends on it, and whether anyone can test it safely when the account changes. NetSuite admins need a clear way to regain that visibility. Use this checklist to structure your NetSuite customization audit, rank migration risk, and prepare for release testing, optimization, or a move to SuiteScript 2.1.
With NetSuite 2026.2, SuiteScript 2.1 is now the standard scripting version, and Oracle’s transition plan moves legacy versions toward a 2028.2 cutoff. Prepare ahead with a review of your scripts so you aren’t rushed into a migration plan. Use this checklist to review:
With a clear checklist, you can turn script review into a first step towards creating a prioritized work queue. Your team can see which scripts support critical workflows, which ones need developer review, and which changes should move first.
A clear script inventory gives you a starting point for cleaning up legacy code, reducing migration risk, and building a NetSuite environment that is easier to support and upgrade.
Tvarana can help you turn that inventory into a practical roadmap by identifying the scripts that matter most, tracing business and integration dependencies, defining the right test cases, and planning migration work around your priorities.
Want to take the first step toward a cleaner, more manageable NetSuite environment with fewer surprises at release time? Download the SuiteScript readiness checklist today.
You need to turn scattered script knowledge into a review workflow your admins, developers, and business owners can use during a NetSuite customization audit. Use this SuiteScript readiness checklist to review custom scripts before migration, release testing, optimization, or support handoff.
Start with the scripts themselves. For each SuiteScript file, capture enough information that someone else can tell what it is, where it runs, and whether it needs attention.
Go to Customization > Scripting > Scripts and filter by API Version. Review 1.0, 2.0, and 2.x separately instead of treating them as one migration group.
For SuiteScript 2.x, check the version tag and account settings carefully. By default, NApiVersion 2.x resolves to SuiteScript 2.0, but compatible server scripts can run under the 2.1 runtime when the account-level preference is set that way.
Then open Customization > Scripting > Script Deployments. A single script can have multiple deployment records, and each deployment can change where, when, and for whom the code runs. Check the Deployed setting, status, audience, schedule, execution context, and Execute as Role rather than assuming the script record tells the whole story.
Do not review a script as code alone. Connect it to the workflow and records the business depends on. Check every area that applies:
Then ask one more question for every script:
What actually happens if this fails?
For example:
Flag any script that affects finance, tax, customer experience, banking, inventory, or external integrations. Those are usually the scripts that need deeper testing and clearer ownership first.
For each integration-related script, document how data moves in and out of NetSuite. Check:
Knowing that a script connects to a bank, tax engine, ecommerce platform, or payroll system is not enough. Follow the dependency far enough to know what breaks if that connection fails. Say, if a RESTlet sends approved vendor data to another system, follow the whole path:
This is where hidden dependencies usually start to show up.
Before changing or migrating a script, define the success criteria for it during testing
For each high-risk script, capture:
Before you rewrite a 2.0 or 2.x server script, you can first see how it behaves under the 2.1 runtime. NetSuite provides account-level preferences under Setup > Company > Preferences > General Preferences that let eligible 2.0 and 2.x server scripts run under the SuiteScript 2.1 runtime without changing the @NApiVersion tag. That gives you a chance to find runtime problems before you start rewriting code. Check the script’s expected business result, execution logs, and any integration or permission errors while the preference is enabled.
Keep one limitation in mind: running a 2.0 or 2.x script under the 2.1 runtime does not change how the file is validated at upload. A script still annotated as @NApiVersion 2.0 or 2.x cannot use 2.1-only syntax until you update the annotation itself.
Good documentation should tell the next admin two things quickly: what the script does and what to check when it stops doing it. The next script owner should be able to understand, test, and troubleshoot the script without reverse-engineering it. Before deployment or support handoff, document:
Before you sign off on migration or deployment, make sure nothing important is still unresolved. Check that critical test cases passed in the previous steps, and recovery steps and post-deployment monitoring are ready.
For migrated scripts, also check the @NApiVersion value and the runtime NetSuite is actually using. If you rely on an account-level preference during compatibility testing, write that down. Otherwise, a later admin may mistake a runtime test for a completed code migration.
A readiness review should leave you with a clear decision for every script: migrate, test further, refactor, retire, or leave in place with an accepted risk.
