NetSuiteFree checklistPDF, Excel, Word exportNetSuiteAll NetSuite tools

NetSuite Sandbox Refresh Checklist

A NetSuite sandbox refresh replaces the sandbox with a copy of production, which wipes sandbox-only work and brings in live email addresses, payment settings and integration endpoints. This checklist covers what to save first, how to request the refresh, and what to fix before anyone tests.

0%

0 of 33 items complete

8 critical items still open - these are the highest-risk gaps.

Download checklist:

Before you request the refresh

Requesting the refresh

Immediately after the refresh

Redeploy sandbox work

Validate and record

Critical items protect real customers, payments and integrations from a production copy. Do not hand the sandbox back to testers until every critical item is ticked.

Get a refresh runbook for your account

Send us your list of integrations and scheduled jobs and we will turn this checklist into a refresh runbook specific to your sandbox.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Work through the groups in order. The first group is done days before the refresh, while developers can still export their work. The second is the request itself, which is made from the production account by an Administrator. The third group must be finished before the sandbox is reopened, because the copy contains real customer and vendor email addresses and live payment profiles. Tick items in the browser and export the result to PDF or Excel as evidence for your change log. If you refresh on a regular schedule, keep the exported list and reuse it, adding any integration you added since the last cycle.

What a refresh does and does not copy

The refresh copies production data and configuration into the sandbox and overwrites what was there. Some things do not carry over in a usable form, and Oracle's sandbox FAQ lists them; check the current list for your release. In practice, plan on token-based authentication tokens needing to be issued again, SAML identity provider settings needing to be set up again, users repeating 2FA setup, and attachments and documents arriving as metadata only rather than as files. Integration records should be verified, since integrations that only existed in the sandbox are gone. Anything that only lived in the sandbox, including scripts never deployed to production, is lost unless you exported it first.

Worked example

A manufacturer refreshes SB1 before a project that changes work order costing. The developer has two user event scripts and a custom record in progress, so she exports them as an account customization project. The integration team notes that the 3PL connector and the EDI middleware use TBA tokens in SB1. After the refresh, the admin sets sandbox email to the logged-in user only, finds three scheduled scripts that would email vendors, unschedules two of them, and sets the payment gateway profile to test. The integration team creates new tokens, updates the hosts to 1234567-sb1, and runs one test call each. The developer redeploys her project and testing starts the next morning.

Common mistakes

Refreshing without exporting sandbox-only work, which is the most common cause of lost effort. Leaving sandbox email set to send to real recipients, so customers receive copies of test invoices. Forgetting that an integration configured with a production account ID will write to production if nobody changes it. Assuming TBA tokens survive the copy. Refreshing during user acceptance testing, which removes testers' data. Not recording the refresh date, which makes it hard to tell later whether a sandbox object came from production or from a developer.

Frequently Asked Questions

How do I refresh a NetSuite sandbox?

An Administrator logs in to the production account and requests the refresh from the Sandbox Accounts page under Setup > Company, choosing the sandbox to overwrite. NetSuite queues the copy and sends a notice when it is complete. Export sandbox-only work beforehand and fix email, integrations and payment settings afterwards, as this checklist describes.

How long does a sandbox refresh take?

It depends on account size and NetSuite's queue, so plan for the sandbox to be unavailable for at least a day and do not schedule testing until you receive the completion notice. Larger accounts with many transactions and files take longer. Do not promise testers a time based on a previous refresh.

Can I sync only some data from production to sandbox?

A sandbox refresh is a full copy, not a selective sync. To move selected configuration, use SuiteCloud Development Framework projects or the Copy to Account feature where available. To move selected data, use CSV import or an integration. Choose this route when a full refresh would destroy too much sandbox work.

Why do integrations fail after a sandbox refresh?

Usually because tokens or integration records the integration relied on are not usable after the copy, or because the integration still points at the old sandbox or at production. Issue new tokens, confirm the integration record, update the account ID in the host name, and check the Login Audit Trail for the failure reason.

If you want your team to ask NetSuite in plain English what changed between production and a sandbox, on infrastructure you control, we can set that up.

ArchRay builder
Design the on-prem AI stack for NetSuite: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

AI on your ERP

Integrations

Comparisons

Software