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 How to request a rollback.

When to request a rollback

Use the rollback option only for revenue-impacting emergencies caused directly by an upgrade. If the issue does not impact revenue, move forward with the current version and address the problem in a subsequent release rather than reversing the upgrade.

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

The following scenarios are not appropriate for a rollback:

• 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

• Configured Commerce base code
• Extension code

Not rolled back

• Database
• Schema
• Configuration data (websites, Simple Mail Transfer Protocol (SMTP) settings, 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.

Rollback 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. Configuration changes remain in place unless you adjust them manually.

  📘

  Note

  Change the configuration and redeploy the same version before upgrading. This isolates changes and ensures the system applies the configuration correctly.

• Optimizely does not test extensions in a rollback scenario – Optimizely quality assurance (QA) tests only base code rollbacks. Your implementation partner must ensure extension compatibility after a rollback.
• Code and configuration changes in the same deployment are not recommended – 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 customer-specific information, Optimizely does not offer remediation for a failed rollback. You and your implementation partner are responsible for resolving any resulting issues, whether 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).

Optimizely Support executes the rollback.

📘

Note

Optimizely Support does not validate rollback compatibility or provide review or approval for rollbacks. You or your implementation partner has sole discretion over rollbacks. See When to request a rollback to determine whether a rollback is appropriate