SuiteScript 2.1 / Readiness assessment
SuiteScript 2.1 readiness.
From inventory to action.
Connect script versions with ownership, business purpose and a practical plan for conversion and testing.
Beyond a script count
Know what the
inventory means.
A count of older scripts tells you where to begin. A useful assessment explains who maintains the code, whether it is still needed, what depends on it, and what evidence you need before updating production.
In a client assessment, I built a saved search of script records, exported the installed bundle list, and combined the information into a working table. That let me separate Left Ledger customizations from Oracle-maintained applications, third-party products and items requiring further investigation.
The examples below illustrate that approach without reproducing client records or internal identifiers.
The assessment steps
Build a plan
someone can execute.
Collect the records
Review script versions, deployments, related files and installed bundles.
Inspect dependencies
Review source annotations and shared modules. A record count is not a unique file count.
Confirm responsibility
Establish the maintainer, edit restrictions and vendor update path. Keep unknowns visible.
Connect the business process
Identify what must continue working and who will approve the test scenarios.
Assign the next action
Record the planned work, responsible person, test evidence and rollout requirements.
Start in NetSuite
Records first.
Then inspect the code.
Go to Customization > Scripting > Scripts and review the API Version filter. Oracle also documents saved searches and SuiteAnalytics Workbooks for reusable inventories. Include scripts that are not already at 2.1.
Record-level information is the starting point. Review source annotations and referenced files as well. Shared libraries and custom modules may support multiple scripts, and a script record count is not the same as a unique file count or an effort estimate.
Your working checklist
What the assessment should capture
| Information | What it helps establish |
|---|---|
| Script name, ID, type, and API version | Which customization needs review and what migration path may apply. |
| File and shared dependencies | Which source files and supporting modules need inspection. |
| Inactive status and deployments | Where and how it can execute. An active record alone does not establish usage. |
| Bundle association and installed version | Whether the script arrived with an application and which update path to investigate. |
| Maintainer and edit restrictions | Who can deliver the change. Confirm ownership rather than relying only on the employee Owner field. |
| Business purpose and process owner | What must continue working and who can approve functional testing. |
| Proposed action and status | Convert, test compatibility, request a vendor update, investigate, or evaluate retirement. |
| Test evidence and rollout plan | How to demonstrate the expected outcome and manage production changes. |
Separate the work
Confirm who can deliver the change.
Custom development
Assign source review and conversion. Test permitted and blocked transaction scenarios for the intended roles and contexts.
Vendor or Oracle applications
Confirm the supported release, required upgrade actions and recommended Sandbox testing. Track unresolved answers.
Unresolved ownership
Investigate bundle membership, edit restrictions and maintenance history. Keep responsibility open until it is confirmed.
Bundle membership does not by itself prove that a file is locked, currently used or maintained by its original publisher. Old implementation utilities need a dependency and usage review before retirement.
Estimate the actual work
Counts are not
migration effort.
Count distinct script records by a stable identifier. Report unique source files and shared dependencies separately when estimating development work.
Keep unknown ownership and unmatched bundle information visible as open questions. An incomplete lookup is not evidence that a script is custom or safe to remove. Record the assessment date so the inventory can be refreshed after application updates.
Vendor follow-up
Ask for a supported
update path.
- Which installed scripts are covered by your SuiteScript 2.1 update?
- Which supported release provides the update, and when will it be available?
- Is installation automatic or does our account need an upgrade action?
- What Sandbox testing and configuration changes do you recommend?
- Are there dependencies or exceptions we need to track?
Keep the response, target release, responsible contact, and follow-up date with the assessment. A vendor request remains open until its update path and required account actions are understood.
Track evidence, not just activity
Make progress visible.
An example path for custom code. Vendor updates and approved retirements follow their own action plans.
Identified
The script and dependencies are recorded.
Assigned
A maintainer and next action are confirmed.
Converted
The required code changes have been reviewed.
Tested
The affected business scenarios have passed.
Deployed
Approved changes are live and monitored.
Define completion
Business behavior
is the acceptance test.
A conversion should have an assigned developer, a process owner, and specific test scenarios. For example, a transaction validation should still accept valid entries and block invalid ones for the intended roles and execution contexts.
For integrations, confirm request and response behavior with the consuming system. For scheduled processing, verify results at a representative volume. Review logs, record changes, permissions, and expected error handling. A successful upload or clean syntax check is one step in that process.
Keep proposed, converted, tested, and deployed statuses distinct. The final assessment should show completed work and unresolved dependencies clearly enough for the account owner to make the next decision.
Companion guide
Need the release timeline and migration options?
Return to the overview for Oracle’s release milestones, the different migration paths and the recommended sequence.
Oracle references
- Transitioning to SuiteScript 2.1
- Identifying scripts that are not using SuiteScript 2.1
- Choosing a migration path
- Updating scripts using the SuiteScript Agent Skill
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.
Back to all insights