NetSuite Sandbox vs. Production Testing: What to Test and Why It Matters
Sandbox testing is not optional for live NetSuite accounts with SuiteScript. This guide covers what must be tested, when to test it, and what happens when release testing gets skipped.
Running SuiteScript development without a Sandbox-first process? Tell us about your account.
NetSuite-Certified · Post-go-live specialist · Sandbox-first development · Month-to-month
Quick answer
Sandbox testing in NetSuite means running scripts, workflows, and configuration changes in an isolated copy of your production environment before they affect real data. The Sandbox is a separate NetSuite account provisioned by Oracle that mirrors the production data model. Scripts can be deployed there, tested against realistic data, and verified before being pushed to production. The most common reason production incidents happen on live NetSuite accounts is a SuiteScript that passed its original deployment but was never re-tested before a major NetSuite release. NetSuite releases updates twice a year, typically in February and August. Any User Event script can break silently on a new release if the underlying API behavior changes. A Before Submit User Event script that breaks will prevent all users from saving that record type until it is fixed, which is a full production outage. Release testing in Sandbox before each major update is the single most important practice for keeping a scripted NetSuite account stable.
Sandbox vs. production: key differences
The Sandbox is an isolated environment. Nothing that happens there affects production users or data. Production is the live environment where errors have immediate impact.
| Factor | Sandbox | Production |
|---|---|---|
| Data | Copy of production (refreshed periodically) | Live data, real transactions |
| Impact of errors | None; isolated from real records | Immediate, affects real users |
| Script deployment risk | Low; test freely | High; broken scripts cause outages |
| Release preview | Yes (receives release before production) | Gets release after Sandbox preview |
| SuiteCloud governance | Enforced; surfaces limit violations early | Enforced; violations halt scripts in real time |
| User impact | None | All active users affected |
| Cost | Included in most NetSuite accounts | Live environment (no extra cost) |
| Use for | Testing, release validation, new development | Live business operations only |
What must be tested in Sandbox before going to production?
The following categories of changes must be validated in Sandbox before production deployment. Skipping any of them is the most common source of production incidents for live NetSuite accounts.
Every SuiteScript before first deployment
No SuiteScript should go to production without first running in Sandbox. User Event scripts can prevent record saves if they break. Client scripts can block form submissions. Sandbox testing catches these issues before real users are affected.
All existing scripts before each NetSuite release
Sandbox receives each major release before production. The testing window is January (before the February release) and July (before the August release). Any script that uses an API that changed in the release must be updated before production is upgraded.
New SuiteFlow workflows
Workflow behavior can change between releases. Complex workflows with conditional branches, field updates, and email triggers should be tested in Sandbox against realistic records before going live in production.
Configuration changes that affect existing records
Saved search changes, custom form updates, and field modifications that affect records in bulk should be validated in Sandbox first. A saved search that produces incorrect results in production affects every user who sees it.
Integration scripts that post transactions
Any script that creates or modifies transactions (invoices, bills, purchase orders) must be tested in Sandbox where duplicate or erroneous records have no financial impact. Testing integration scripts in production creates real transactions.
What are the risks of skipping Sandbox testing?
These are the specific failure modes that occur when scripts are deployed directly to production or when release testing is skipped before a major NetSuite update.
Before Submit script breaks: full outage for that record type
If a User Event script that fires Before Submit throws an error, NetSuite will prevent ALL users from saving that record type until the script is fixed and redeployed. This is not a degraded experience; it is a complete block.
Silent API changes after a release
NetSuite releases can change the behavior of SuiteScript API calls without removing the API entirely. A script that runs without error may return different values or skip records after a release, corrupting data silently before anyone notices.
SuiteCloud governance limit violations
NetSuite enforces governance (CPU time, record access) limits on all scripts in production. A script that passes light testing may hit limits when run against real production data volumes, causing it to fail or be terminated mid-execution.
Integration scripts creating real transactions
Testing an integration script in production creates real records: duplicate vendor bills, test invoices, phantom purchase orders. Reversing these requires manual cleanup and can affect financial reports and audit trails.
The NetSuite release testing calendar
NetSuite releases major updates twice a year. The Sandbox preview precedes each production release, giving accounts time to test:
- January: Sandbox receives the February release preview. Test all scripts and workflows against the new release.
- February: Production receives the new release. Scripts already validated in Sandbox are safe to continue running.
- July: Sandbox receives the August release preview. Repeat the testing process.
- August: Production receives the new release.
Accounts that skip the January and July testing windows are running unsupported risk every February and August. SuitePacific includes release testing in all ongoing support retainers.
Related reading
- NetSuite SuiteScript development covers what SuiteScript development looks like when done with a Sandbox-first process.
- NetSuite post-go-live support covers the broader scope of ongoing support for live NetSuite accounts.
- NetSuite configuration vs. customization covers when requirements need code and the upgrade risk that comes with it.
Need Sandbox-first development for your NetSuite account?
Tell us about your current SuiteScript setup and whether release testing is part of your process. We will assess the risk and give you a realistic path forward.
Frequently Asked Questions
When is the NetSuite Sandbox refreshed?
Oracle refreshes the Sandbox environment approximately twice a year, typically aligned with major release windows. Account administrators can also request an on-demand Sandbox refresh from NetSuite support, which overwrites the Sandbox with a current copy of production data. An on-demand refresh is useful when the Sandbox has drifted far from production and testing needs to reflect current data structures.
What can Sandbox not test that production can?
Sandbox cannot test real user load under production-scale concurrency. It also cannot fully replicate some real-time external integrations that depend on production endpoints. For performance testing under realistic load, additional approaches are needed. That said, Sandbox catches the vast majority of script errors, release breakages, and governance limit violations before they affect production.
Does every NetSuite account include a Sandbox?
Most NetSuite subscriptions include a Sandbox environment. However, the number of Sandbox accounts and whether they are included or licensed separately depends on the subscription tier and the original implementation contract. Accounts that do not have a Sandbox can request one from their NetSuite account manager. Development on a live production account without any Sandbox is a high-risk configuration.
What is the release testing window for NetSuite?
NetSuite typically releases the Sandbox preview in January for the February release and in July for the August release. This gives accounts a window of several weeks to test their scripts and customizations against the new release before it reaches production. SuitePacific includes Sandbox release testing as part of ongoing support retainers.
Can I deploy a script directly to production without Sandbox testing?
NetSuite does not technically prevent direct production deployment without Sandbox testing. However, deploying untested scripts to production is the primary cause of NetSuite outages for live accounts. A broken Before Submit script blocks all users from saving the affected record type immediately upon deployment. There is no safe way to test a script for the first time in production.
What is SuiteCloud governance and why does it matter for testing?
SuiteCloud governance is NetSuite's system for limiting the resources (CPU time, record access units) any script can consume in a single execution. Governance limits prevent any one script from degrading platform performance for all users. A script that passes light testing may exceed governance limits when run against production data volumes. Sandbox testing with realistic data identifies governance violations before they interrupt production operations.
Ready to put a Sandbox-first process in place?
Describe what scripts and customizations your account is running. We will identify the release risk and build a testing plan.