Overview
Over time, configurations in a production instance tend to drift away from what's set up in sandbox: new products get added, workflows get refined, ticketing categories evolve. When that drift becomes large enough, sandbox stops being a useful place to test changes, because what you test there no longer reflects how production actually behaves.
To address this, gaiia supports cloning the configuration of a production instance into a sandbox instance. This article explains what gets cloned, what doesn't, when to request a clone, and how to prepare for it.
What gets cloned
A production-to-sandbox clone copies the static, configurable parts of your instance. This includes:
- Product catalog (plans, add-ons, taxes, billing settings)
- Network settings and inventory structure
- Work order templates and field service configurations
- Ticketing categories, statuses, and settings
- Workflows (including drafts and disabled ones)
- Communication templates (system, custom, documents)
- Roles, permissions, and module enablement
- General tenant settings
After the clone, the sandbox instance is a structural mirror of production at the moment the clone ran.
What does not get cloned
Some parts of an instance are deliberately excluded from a clone:
| Category | Why it's excluded |
|---|---|
| Customer data (accounts, contacts, subscriptions, invoices, payments) | Production customer data should not live in a non-production environment. This is a SOC 2 and ISO 27001 expectation, and it limits the blast radius if something goes wrong during testing. |
| Integrations (API keys, credentials, third-party connections) | Credentials are environment-specific. Reusing production credentials in sandbox would point sandbox actions at real third-party systems (billing processors, provisioning platforms, etc.), which is exactly what sandbox is designed to avoid. |
| User accounts and access | Sandbox access is managed separately. After a clone, your admins will need to re-invite the users who should have access to the new sandbox. |
| Live transactional state (open work orders, in-flight tickets, etc.) | These are tied to customer data and are not copied. |
Workflows themselves are cloned, but any workflow that depends on an integration will fail to execute in the new sandbox until the integration is reinstalled and reconfigured.
When to request a clone
Keep in mind that gaiia can help clone an instance, but that should be a last resort. We might refuse to clone or hold any request to prioritize developing new features. You should maintain the configuration in your sandbox as similar as possible to your production instance.
A clone is the right move when:
- Your sandbox has drifted far enough from production that testing there no longer gives you confidence
- You're preparing for a significant configuration change in production and want a faithful place to test it first
A clone is generally not the right move when:
- You need recent real customer data to reproduce a specific issue. The answer there is to work with our team to investigate in production rather than trying to replicate data into sandbox.
- You want to keep sandbox continuously synced with production. Clones are one-time operations, not a live sync.
Preparing for a clone
A clone is destructive: the existing sandbox is wiped and replaced. Before we run it, your team should:
- Save anything in the current sandbox you want to keep. This typically means workflows that were drafted in sandbox but not yet copied to production. The workflow editor's export option is the easiest path.
- Inventory the integrations in production that you'll need to reconfigure in the new sandbox. Have credentials for sandbox versions of those third-party systems ready (sandbox API keys for billing processors, sandbox tenants for provisioning platforms, etc.).
- Confirm with your admins that the current sandbox can be wiped. Once the clone runs, anything in the old sandbox that wasn't exported is gone.
- Decide on a user access plan. After the clone, the sandbox starts with no users. Your admins will need to re-invite team members.
After the clone
Once the clone is complete, your team takes over the next steps:
- Reinstall integrations. Each integration needs to be configured against its sandbox counterpart at the third-party system. Workflows that call those integrations will start succeeding once the credentials are in place.
- Re-invite users. Admins on your side add team members back into the sandbox with the appropriate roles.
- Create test data. Because no production customer data was copied, you'll create dummy accounts, contacts, and subscriptions in the sandbox to exercise the flows you want to test. We recommend keeping the volume modest, just enough to cover your test cases.
Requesting a clone
To request a production-to-sandbox clone, open a Zendesk ticket with the following:
- The production instance name and the sandbox instance to be replaced
- Confirmation that the current sandbox can be wiped
- The list of users who should be re-invited to the new sandbox after the clone
Our team will confirm the request, schedule the clone (typically during a low-activity window), and let you know once the new sandbox is ready.
Why we don't sync customer data
We get this question a lot, so it's worth being explicit. The need to test against realistic data is real, but copying production customer data into a non-production environment carries costs that outweigh the convenience:
- Compliance. SOC 2 and ISO 27001 both treat production data in test environments as a finding. Keeping a clean separation is part of how gaiia maintains its certifications, and by extension, part of the assurances you give your own customers.
- Liability. Every additional copy of customer data is another place that data can be exposed. Sandboxes are intentionally lower-trust environments than production, so storing real customer records there is exactly backwards from a risk perspective.
- Test fidelity. Counterintuitively, real data is often worse for testing than well-constructed dummy data. Real data has historical quirks, partially completed states, and edge cases that distract from the change you're actually trying to validate.
For most testing needs, a cloned configuration plus a small set of dummy accounts is a better setup than a partial copy of production.