Moving Configurations and Code Changes from Sandbox to Production

Hi ​@asubramaniam,  What Can Be Migrated (and What Typically Isn't).
 

Configuration is the primary thing that moves

The standard pattern is:

• Build and validate configuration in Sandbox (SBX)
• Migrate the functional and technical build to Production at go-live
• Use a formal go/no-go decision after smoke testing

Data does not sync between environments

Sandbox and Production are independent environments. Data doesn't flow automatically between them — changes require either import or API-based integration. This is why customers often request "mirroring," but it's not treated as an always-on sync.

Custom code is typically out of scope

Platform-level code changes are not part of the standard SBX→PROD migration unless formally scoped through a Change Request (CR) process.

Migration Options

1. Cutover approach — Migrate config to Production, complete smoke testing, hold a go/no-go, then enter hypercare.
2. Instance management tool — Compare SBX vs. PROD configuration (gates, custom fields, roles/permissions) and migrate tested config. Does not migrate data. Note: integration systems must be created in PROD first before pulling over config.
3. Entity-level migration — For specific items like email templates, use targeted migration utilities in the Admin Console.
4. Manual reconfiguration — Some items are environment-specific and always require manual setup in PROD: SSO/SAML configuration and integration credentials (API keys, endpoints, domains).

Key Considerations

• Integrations require PROD connectivity work even when SBX is complete — plan for separate credentialing and validation.
• Testing sequence: SIT → UAT → Smoke test → Go/No-Go.