Optimizely Configured Commerce currently hosts many customers on non-containerized, shared infrastructure, sometimes referred to as pods (v1). All sandbox and production environments must migrate to the new containerized infrastructure (v3) as support for Classic CMS ends in 2025. Containerized infrastructure provides several benefits, including speed, security, and stability, and is a prerequisite for migrating from Classic CMS to Spire CMS.
An Optimizely Project Manager and team will coordinate your migration at no cost with minimal disruption and development time. The migration will not impact B2B Analytics, Configured Commerce Mobile app or SDK, or Optimizely Product Information Management (PIM). If you encounter an issue with these enhancements after your migration, please submit a support ticket to support@optimizely.com. If you have any questions about this process or would like to start your migration, please contact your Customer Success Manager.
Timeline
Optimizely has scheduled end of service for v1 environments on December 31, 2023, as most customers are already in process, scheduled, or preparing for migration before the end of the year. If you would like to schedule your migration, please contact your Optimizely Customer Success Manager. They will help you set a start date and add you to the queue.
The timeline for end of service is as follows:
This does not affect customers who are migrated out of v1 before the end of the year.
- October 1, 2023 – Optimizely scales down pods to support the number of customers remaining in each. There is no customer or site performance impact.
- December 31, 2023 – Optimizely ends service for v1 environments. All customers should migrate to v3 architecture before this date.
If you remain in the v1 environment after the end of service date, you are subject to the following deprovisioning schedule:
- January 1, 2024 – Optimizely only maintains uptime SLA for v1 architecture and does not support other code or transaction issues nor base code deploys.
- February 1, 2024 – Optimizely scales down pods to the minimal needed. This may have performance impacts.
- March 1, 2024 – Optimizely deprovisions servers for v1 environments.
Migration requirements
There are several requirements to begin your migration:
- You should ensure there are no in-progress code changes outside of base code not deployed to production.
- Optimizely requires a code freeze for the duration of the migration on sandbox and production environments. The process will take approximately four weeks; if the process takes longer than four weeks, the environments will remain in code freeze until the migration is complete.
- The versioninfo.yaml file contains information about the version of Configured Commerce that will be deployed for containerized environments. This differs from pod environments, for which Optimizely controls deployment of specific versions. The version in the YAML file in your sandbox branch must match the version currently deployed to your pod sandbox environment, and the version in the YAML file in your production branch must match the version currently deployed to your pod production environment.
- You should verify that the versions referenced in the extensions DLL for the NuGet packages Insite.Commerce.Public and Insite.Commerce.Private match the version you intend to deploy. These should be correct in most cases, unless your sandbox environment was sync released and you did not update code alongside it.
Process
An Optimizely Project Manager will meet with you to provide a detailed overview of the migration process. You must commit to finishing the migration project within four weeks. Any issues that arise and cause a migration project to run longer than four weeks may result in the project being prioritized later.
The implementation team will provision a sandbox environment where you will complete one to two weeks of testing. The team will then provision a production environment where you will complete an additional one to two weeks of testing. Optimizely will provide test documents for guidance.
Optimizely recommends the following during testing:
- Obtain the Containerized IP addresses if any third-party systems updates explicitly allow integrations from a specific IP range.
- Test common extension functionality, third party integrations, and code deployments. Optimizely does not expect any difference in behavior in the container environment.
Because this environment connects to third-party systems, be cautious when executing integrations such as order submissions and credit card authorizations.
- Run all integration jobs that you typically run to ensure they work as expected. Test pricing, inventory, and order submission when in sandbox.
- Ensure no processes exceed the allotted memory, which could occur due to data volume, custom code, or running multiple integration jobs concurrently. One of the key differences between pod and container environments is the amount of memory allocated. Integration containers have a 6 GB cap for integration jobs. Configured Commerce containers have a 4 GB cap. A frequent site startup message in the application log is an indication you may have exceeded the allotted memory.
- Run Search Index Rebuild.
Once you complete testing, Optimizely will schedule your final move to the new containerized environment. Your site will be down one to four hours during this process, which you can schedule to start from Monday to Friday between 9 am and 5 pm CST.
See the diagram below for a high-level overview of the migration process.
Please sign in to leave a comment.