Roll back Configured Commerce base code

Rolling back Optimizely Configured Commerce base code and extension code is an emergency recovery option when an upgrade breaks your environment. Only Optimizely Support can execute this process. See the How to request a rollback section for instructions.

When to request a rollback

Use the rollback option only for revenue-impacting emergencies caused directly by an upgrade. If the issue is minor or not revenue-impacting, fail forward and fix it in a new release or redeployment instead.

Appropriate use cases include the following:

• Your site is down or critically broken after a base code upgrade
• The issue is directly tied to the upgrade and is actively impacting revenue

Not appropriate for the following:

• Minor post-upgrade regressions
• Issues caused by configuration changes rather than a code upgrade
• Non-revenue-impacting bugs

Rollback strategy

A rollback reverts only certain elements of the instance. Rolling back to a previous version when the schema, data, or website configuration is incompatible causes issues, because Optimizely does not revert these elements.

Rolled back

• CFG base code
• Extension code

Not rolled back

• Database
• Schema
• Configuration data (websites, SMTP, and so on)

Version support

Optimizely supports rollbacks for versions 5.2.2512.357+sts (5.2.2512.412+lts) and later. Optimizely does not support earlier versions.

📘

Note

Optimizely validates that only base code versions at or above 5.2.2512.357+sts (5.2.2512.412+lts) are compatible with existing and future database schemas.

You or your implementation partner must verify extension compatibility, database data, and your website configuration.

Risks

Review the following risks before requesting a rollback:

• Optimizely does not revert configuration changes – Optimizely does not roll back changes to website configuration or other environment settings. These remain in place unless you adjust them manually.

  📘

  Note

  You should change the configuration and redeploy the same version before upgrading to isolate changes and ensure the system applies the configuration upgrades.

• Optimizely does not test extensions in a rollback scenario – Optimizely QA tests only base code rollbacks. Your implementation partner must ensure extension compatibility after a rollback.
• Change one variable at a time – If you changed both code and configuration in the same deployment, isolate the cause before requesting a rollback.
• A rollback could cause more problems – If you do not review changes or compatibility issues occur, the environment might remain in a broken state after a rollback. Because each rollback relies on unique customer-specific information, Optimizely does not offer specific remediation for a failed rollback. You and your implementation partner are responsible for resolving any issues that arise from a rollback, either through support requests or self-service.

How to request a rollback

Rollbacks require Optimizely Support team intervention and are not self-service. To request a rollback, complete the following steps:

1. Validate rollback compatibility of extensions, database, and configurations.
2. If validation is successful, open a support case with Optimizely and include the following information:
   • Target environment.
   • The version you are rolling back from (existing version).
   • The version you are targeting for rollback (previous version).
3. Optimizely Support executes the rollback.

📘

Note

Optimizely Support does not validate rollback compatibility or provide review or approval for rollbacks. The customer or implementation partner has sole discretion over rollbacks. Follow this documentation to determine when to roll back.