What a sandbox is for
A sandbox is a separate account that is a copy of production, used for building and testing without touching live data. It is where you try a new workflow, test a script, rehearse a data load, train users, and validate that something works before releasing it. Because it starts as a copy, it reflects your real configuration and, depending on the type, your real data, so tests are realistic.
- Build and test changes before they reach production.
- Rehearse migrations and integrations with realistic data.
- Provide a safe place for training.
Refreshes and how stale a sandbox becomes
A sandbox is a snapshot, and it drifts from production as production changes. Refreshing it recreates the copy from current production, which resets customizations made only in the sandbox. Plan refreshes around project cycles so work in progress is not lost, and decide when you need fresh data versus when a stale copy is acceptable. Never assume a sandbox matches production without checking, especially before an important test.
Promoting changes to production safely
Moving a change from sandbox to production should be deliberate and repeatable. Options include packaging changes as bundles or project deployments for scripts and customizations, and manually reproducing simple configuration changes. Whichever you use, record exactly what is being moved, who approved it, and when it was released, and have a plan to reverse it if something goes wrong. Avoid making unrecorded changes directly in production, which cause the differences that confuse later work.
NetSuite development services →Handling the platform's regular releases
NetSuite is updated on a regular schedule, and customers typically gain access to a preview of each release before it reaches production. Use that window. Read the release notes for items affecting features you rely on, run your key processes in the preview account, and compare results to what you expect. Fix issues before the release reaches production, and tell users about changes they will see. Skipping the preview means discovering problems when your users do.
A regression test set that you actually run
Create a short list of scenarios that must work: entering and approving a vendor bill, creating and fulfilling a sales order, posting a journal, running the month-end reports, and each integration's main flow. Write the steps and expected results, and run them in the preview after each release. Keep the set small enough that people will really run it. A modest suite executed every time is worth more than an elaborate one that is skipped.
Managed and advisory services →Decisions to settle before you set the routine
- Environment roles. Define what each environment is for and who may change it.
- Change approval. Decide who approves changes to production and how emergency changes are handled.
- Refresh calendar. Schedule sandbox refreshes around project work.
- Test ownership. Name who runs and signs off the regression set after each release.
A realistic first 90 days
- Days 1 to 30. Document environments and current customizations, and write the initial regression test list.
- Days 31 to 60. Introduce the change-request and approval step, and record all deployments in a change log.
- Days 61 to 90. Run the first release-preview test cycle with the regression set and capture lessons for the next one.
Pitfalls to avoid
- Building directly in production. It is quick until it breaks something. Use the sandbox.
- Forgetting what changed. Without a change log, nobody can explain why behavior differs. Record each deployment.
- Skipping the release preview. Problems found by users are costlier than problems found in preview.
- Testing with stale data. Results from an out-of-date sandbox can mislead. Check its currency first.
