NetSuite sandbox vs production at a glance
| Production | Sandbox | |
|---|---|---|
| What it is | Your live NetSuite account where real business runs | Isolated copy of production for testing, dev, and training |
| Real data? | Real customers, real transactions | Snapshot from a refresh; no impact on real business |
| Real money? | Yes — invoices post, payments process, GL updates | No — invoices and payments don't reach external systems |
| Cost | Included in your license | Add-on: ~$5,000-$10,000/year (varies by edition) |
| Refresh cycle | N/A | On-demand or scheduled; takes 12-72 hours |
| URL pattern | https://[accountID].app.netsuite.com | https://[accountID]-sb1.app.netsuite.com |
| Best for | All real business operations | Pre-release testing, customizations, training |
TL;DR: A NetSuite sandbox is a separate, isolated copy of your production account that lets you test customizations, validate releases, and train users without risking real data. It's a paid add-on (~$5K-10K/year), refreshes from production on demand, and is essential for any company doing SuiteScript development or running a NetSuite implementation. Production is your live system where actual business happens. Never test in production.
What is a NetSuite sandbox?
A NetSuite sandbox is a separate NetSuite account that runs as a copy of your production environment. It has its own login URL, its own data, and its own state — but it shares your production account's structure (chart of accounts, custom fields, scripts, workflows, integrations).
When you provision a sandbox, NetSuite copies your production account at a specific point in time. From that moment forward, anything you do in sandbox stays in sandbox. You can post journal entries, generate invoices, run scripts, break things — and none of it touches your real business data.
The technical reality: a sandbox is a fully isolated NetSuite tenant with its own database. It's not a "preview mode" or a "test toggle" inside production. You log into it as a completely separate URL with separate credentials.
There are different types of sandboxes Oracle offers, but the most common is the standard sandbox — a development/QA environment that mirrors production. We'll cover the variants below.
Why you need a sandbox
If you have any of the following in your NetSuite account, you need a sandbox:
Custom SuiteScripts. Testing scripts in production is asking for outages. A bad UserEvent script can lock down record creation across your entire organization. Run it in sandbox first.
Integrations with external systems. Shopify, Celigo, Stripe, Boomi, custom REST integrations — every one of these can fail or duplicate records if misconfigured. Validate the integration end-to-end in sandbox before flipping it on in production.
Bi-annual NetSuite releases. Oracle pushes 2026.1 and 2026.2 to sandbox accounts approximately 4 weeks before production. This gives you a window to test that customizations still work, integrations still sync, and reports still produce correct numbers.
User training. New hires shouldn't be learning NetSuite by clicking around production. Use sandbox for training so mistakes don't post to the GL.
Process changes. Implementing a new approval workflow? A revised chart of accounts? A new tax configuration? Test it in sandbox where the only consequence of getting it wrong is "we have to fix it in sandbox."
SuiteApp evaluation. Most SuiteApp vendors will let you install their app in sandbox for a free trial period. Validate fit before committing to a production install.
If you have NONE of the above and you're a 5-user company doing basic financials with zero customization, you might genuinely not need a sandbox. Most companies above 20 users do.
Types of NetSuite sandbox accounts
Oracle offers a few sandbox flavors. The terminology has shifted over the years, but in 2026 these are the categories:
Standard sandbox
The most common sandbox type. Full copy of production data, structure, and customizations. Refreshes on demand (typically 1-2 times per year is included; additional refreshes are billable). Used for:
- SuiteScript and SuiteFlow development
- Integration testing
- User Acceptance Testing (UAT) before production deployment
- Pre-release validation
A standard sandbox is what most companies mean when they say "sandbox."
Release Preview sandbox
A special sandbox Oracle pushes the upcoming release to about 4 weeks before production. Same data as your last refresh, but running on the new NetSuite version. Critical for validating that custom code and integrations don't break with the upcoming release.
You don't usually buy a Release Preview sandbox separately — Oracle provisions it from your existing sandbox during the preview window.
Development sandbox
Some larger customers run a separate development sandbox so devs can build without disrupting QA. Typically available on Enterprise tiers. Refreshes less frequently — the goal is a stable dev environment, not a clean copy of production.
SuiteCloud Development Framework (SDF) projects
Not technically a sandbox, but worth mentioning: SDF lets developers build customizations as code, version-controlled in a repo, and deploy across multiple sandboxes. Modern NetSuite development teams use SDF + sandboxes together rather than working directly in any one environment.
NetSuite sandbox cost
Sandbox pricing isn't published officially (consistent with NetSuite pricing overall). Industry estimates we see in 2026:
| Type | Approximate cost |
|---|---|
| Standard sandbox | $5,000-$10,000/year, depending on edition |
| Additional refresh | $1,000-$2,500 each beyond included refreshes |
| Development sandbox (Enterprise) | Bundled or add-on negotiated separately |
| Release Preview | Included with standard sandbox |
The cost is small compared to the cost of breaking production. We've seen one bad SuiteScript deployment cost a client 6 hours of revenue and 2 days of cleanup. A sandbox would have caught it.
Oracle does NOT publish official pricing — these are industry estimates based on partner contracts. Negotiate.
How sandbox refreshes work
A sandbox refresh copies the current state of production into the sandbox, overwriting whatever was there. After a refresh:
- All sandbox data matches production as of the refresh moment
- Custom records, scripts, workflows, and saved searches are copied over
- User accounts and roles are copied (with passwords reset)
- Integration credentials are NOT copied (security feature) — you'll need to reconfigure
- Email sending is automatically disabled in sandbox to prevent accidental sends to real customers
Refresh duration: typically 12-72 hours depending on data volume. A 50GB account might refresh in 12 hours; a 500GB enterprise account can take 3 days.
When to refresh:
- Before starting a major customization project (you want fresh data to test against)
- Before user training (so trainees see realistic data)
- Quarterly as a baseline cadence for development teams
- Whenever production has diverged significantly from sandbox
When NOT to refresh:
- In the middle of UAT (you'll lose all the test data your users created)
- Right before a release preview window (you'll lose the preview)
- During an active development sprint (you'll overwrite work-in-progress in sandbox)
Sandbox vs production: workflow patterns that work
The pattern we recommend for clients with active development:
1. Build in sandbox. All SuiteScript, workflows, custom records, and saved searches start in sandbox. Developers commit code to a repo using SDF.
2. Test in sandbox. UAT happens in sandbox with realistic data. Bugs get fixed in sandbox.
3. Deploy to production via SDF or change management. Once UAT is signed off, the SDF project deploys to production. Manual changes (creating records, modifying preferences) get documented and replayed in production.
4. Validate in production smoke-test. First 24-48 hours after deployment, watch for errors. Have a rollback plan.
5. Refresh sandbox after major prod changes. Once production has diverged enough, schedule a refresh to bring sandbox back in sync.
Companies that skip steps 1-2 and "just push to production" eventually pay for it. Usually at month-end. Usually loudly.
Sandbox login: how to access it
A sandbox has its own URL pattern that distinguishes it from production:
- Production:
https://[accountID].app.netsuite.com - Sandbox 1:
https://[accountID]-sb1.app.netsuite.com - Sandbox 2:
https://[accountID]-sb2.app.netsuite.com
You log in with your same email but a separate password (NetSuite resets passwords during refresh for security). 2FA setup is independent — if you have an authenticator app for production, you'll set up a new entry for sandbox.
For SAML SSO customers, sandbox typically uses a separate SAML configuration so you can test SSO changes without breaking production access.
Common sandbox mistakes we see
Mistake 1: Treating sandbox like a permanent test data store. Refreshes wipe everything. If you need persistent test scenarios, document them as scripts that recreate the data, not as actual records sitting in sandbox.
Mistake 2: Forgetting to disable integrations after refresh. A fresh sandbox has integration credentials wiped — but if you reconfigure them and point at production endpoints (Shopify, Stripe, etc.), you can post real charges or modify real inventory. Always point sandbox integrations at sandbox endpoints of those external systems.
Mistake 3: Testing only the happy path. UAT in sandbox should include error cases, edge cases, and bad data. The point of sandbox is to find problems before production does.
Mistake 4: Skipping sandbox for "small changes." A "small" change to a saved search formula can break a downstream integration. Test it in sandbox first.
Mistake 5: Letting sandbox drift indefinitely. If your sandbox hasn't been refreshed in 18 months, it no longer represents production. Refresh quarterly minimum for active development teams.
Sandbox and the NetSuite release cycle
Oracle's biannual release cycle (2026.1 in March, 2026.2 in September) integrates with sandboxes through the Release Preview window:
~4 weeks before production release: Oracle pushes the new version to all sandbox accounts. This is when you test.
Test these specifically during preview:
- Custom SuiteScripts (especially anything using deprecated APIs)
- Integrations that depend on REST/SOAP API behavior
- Reports and saved searches with complex formulas
- Workflows that interact with new fields or features
- Performance of bulk operations (scheduled scripts, mass updates)
~4 weeks after sandbox preview: Oracle pushes the same version to production. If you tested thoroughly in sandbox, the production push should be uneventful.
For our clients, we run a checklist during every release preview. The full breakdown is in our NetSuite 2026 release notes hub.
When you don't need a sandbox
A few scenarios where skipping a sandbox is defensible:
Pure financials, no customization, small team. A 5-user account doing basic GL, AP, and AR with zero scripts, no integrations, and no upcoming changes can technically run without a sandbox. Most should still have one for training and release validation, but it's defensible.
Brand new implementation, pre-go-live. During implementation, your "production" is effectively a sandbox until you go live. Once you're live, you should pivot to a separate sandbox for ongoing dev work.
Ultra-small SuiteSuccess Starter accounts. Some Starter tier accounts genuinely can't justify the sandbox add-on. The trade-off is no buffer for changes — every modification is live.
For everyone else: get the sandbox. The cost is small relative to what one bad production change can cost.
Frequently asked questions
Frequently Asked Questions
Not sure which is right for you?
Tell us your requirements. We'll give you an honest take within 48 hours — even if NetSuite isn't the answer.
Get More Comparisons Like This
Join our newsletter for honest ERP comparisons, NetSuite tips, and integration insights.
Related Articles
NetSuite Implementation Guide 2026: $25K–$500K Real Breakdown with Timeline & Steps
NetSuite implementation costs $25K–$500K+ and takes 8–16 weeks for mid-market. Real phase-by-phase breakdown, 3 worked examples with total Y1 cost, and the mistakes that blow budgets.
NetSuite Partner: How to Choose the Right One (2026)
Most NetSuite implementations fail because of the partner, not the platform. Red flags, real cost ranges ($25K-$200K+), partner types explained, and the questions your vendor hopes you won't ask.
Acumatica vs NetSuite: Unlimited Users vs Ecosystem
Acumatica offers unlimited users. NetSuite charges per seat but has 3x the partner network. Compare pricing, manufacturing depth, and which ERP fits.