Production Database Sync

8 min

You can sync data from a Configured Commerce production instance to a target sandbox instance within the same customer in Mission Control. This is not a whole-instance copy; the data transferred is selected to avoid syncing instance-specific data (like configuration or connection details). Data transferred from the production instance replaces the same data on the sandbox instance.

Warning

This is a destructive process for the target sandbox instance, and large amounts of data may be deleted on the sandbox as part of the sync. Ensure that the target sandbox does not contain important data before initiating a sync.

If the website keys on the target sandbox instance and the production instance do not match, the sandbox may have startup errors and unusable websites after the sync. To avoid these problems, ensure each target sandbox instance has a matching website key for every website in the production instance. If the production instance has any sites that do not match website keys on the sandbox instance, the site(s) will be unusable on the sandbox after the sync. Contact Optimizely Support to enable these sites.

Important

Do not run this action at the same time as any deployment or database backup actions.

Version requirements

Mission Control only supports Configured Commerce versions 12 months or newer.

The target environment must be on a version that is at or newer than the version of the source environment.

Both the source and target environments must be using a version within the three previous long-term support versions (or their corresponding short-term support versions).

Using versions that do not comply to the previous requirements could result in a failed sync or application issues.

Steps

Go to Customers and select a customer.

Select a target Configured Commerce instance. This is a one-way process from production to sandbox. The action is available when viewing a sandbox instance. You can select any production instance within the same customer as a source.

Click Actions on the instance page and select Production Database Sync.

(Optional) Schedule the action by toggling Scheduled Execution to On and selecting a time and date.

Select the source instance from the Source Environment drop-down list. This is the instance that UserFiles are transferred from to the target instance. It is restricted to production instances within the same customer.

Review the details to confirm the selected instance (and scheduled time, if selected). You can ignore any greyed-out or immutable fields because they are for development or debugging.

Click Continue. If scheduled, the action runs at the specified time. Otherwise, the action runs immediately.

Wait until the status is marked as Complete on the Action Request page. If the action fails, submit a ticket with Optimizely Support with a link to the failed action request page.

Note

Due to the resource-heavy nature of this action, Mission Control is limited in the number of database sync processes it runs at any given time (it operates on an FCFS-type queue). The variable nature of the data being copied can also significantly impact the completion time for the sync. Due to these factors, the database sync could take a significant amount of time, such as multiple days, or sometimes as little as a few hours.

Data synced from production

Note

Optimizely cannot support special requests to include or exclude specific tables for this action. If you have recommendations for improving the synced data, use the Optimizely Feedback portal to send feedback, and the team will review it for future consideration.

The following data is synced from the production instance into the target sandbox:

Product data – Product settings (like ERP Managed, Track Inventory, and Quote Required), attribute values, category assignments, product content (metadata and content), product specifications, child variants, pricing, cost, product number, URL segment, warehouse inventory (stock), and shipping information.

Category data – Category information (name and description), category hierarchy, products assigned, category content (metadata and content), and attribute values.

CMS Content – Page customizations (no code; only CMS out-of-the-box widgets) and variant page customizations and rules.

Attribute types and values

Variant types

Customers

Website users

Data persisted on sandbox

The following areas are not synced from the production instance and are left unchanged on the target sandbox:

System Settings

Database Users

Single Sign-On settings (Admin Console → Administration → Single Sign-On)

JobDefinition

Exception: All EmailTemplateIds are nulled out on the JobDefinition table in the target instance as it is impossible to maintain a cross-reference of data.

JobDefinitionParameter

JobDefintionStepParameter

JobDefinitionStepFieldMap

JobDefinitionStep

IntegrationConnection

Admin & AspNetUsers

Exceptions:

If a production admin user has changed data being synced down from production (like CustomerOrders, Content, ContentItems, and ContentItemFields), that admin user is synced to the target sandbox.

To maintain production admin user roles with the above, admin user roles are synced down from production to the target sandbox.

To avoid duplication of roles across sandbox or production, all roles in the target sandbox are appended with -1 when synced. Production roles maintain existing names.

If there is a match between production and the target sandbox for an admin user, it uses the production admin user and roles. If there is an admin user on the target sandbox that is not in production, the user is given the sandbox roles appended with -1.

ApplicationLog

Elmah_Error

CacheKeySuffix

CacheState

IntegrationJobLog

IntegrationJobParameter

SharedCache

IntegrationJob

Rollback

Optimizely does not have a rollback process in place. Instead, the process is designed to end with a complete backup, and Optimizely proceeds with a deployment that restores from the database. If the environment copy fails at any other step, it does not affect the sandbox environment. Additionally, there is a retry mechanism for those final steps built into the database synchronization process, where Optimizely attempts the deployment up to three times before stopping.