Part 1: Planning and estimation for Upgrade (CMS 12/Commerce 14)

In this series, I will talk about the Optimizely CMS/Commerce upgrade project(s) with some do's and don'ts as well as tips & tricks for a successful implementation. We can all agree depending on the complexity of the implementation, the ugprade project has a potential to go off track pretty easily. This blog post will allow you to get ahead of some of these challenges. 

5P's principle: Proper Planning Prevents Poor Performance.

In Part 1 of this series let's talk through the most important (& often neglected) phase - "Planning and Estimatation". 

Planning & Estimation

This is one of the most difficult part of the process. How do you estimate an upgrade? Unfortunately, I don't have a silver bullet, as each project is unique but here are a few critical things to consider that will help you plan and estimate it better.

Onboarding & kickoff: If you are planning to use a new sidecar team for the upgrade, you need to account for any setup/onboaring time for new developers + kickoff. 

Customizations: Take inventory of the all the customizations to the core product. This is by far the biggest variable in the estimate and can cause the project to go off track quickly if you don't have a plan for how you plan to support it.

Third Party Integrations: With the upgrade the underlying engine needs to be upgraded to .NET Core. It will be useful to document all third party integrations including nuget packages that rely on the old .NET framework & haven't been updated to support the new .NET Core architecture. You may need to work with the client to find alternatives or remove this functionality completely. 

Commerce Manager: Commerce Manager will no longer available in the new Commerce 14 and will have Order Manager instead. Ensure you are documenting any updates/customizations that need to be supported in the new Order Manager for processing your orders.

Linux Containers: The new DXP is hosted in Linux containers unlike the existing DXP which is hosted on Window's servers. This is a huge diference as Windows Forms WPF and other Window specific packages will not work in the the Linux containers. This is difficult to anticipate as the upgrade project may work perfectly fine locally but throw random errors in the new DXP. 

Did you know: Linux has removed support for TLS1.0 & TLS 1.1 certificates? We ran into this issue after deploying to DXP although it worked perfectly fine locally (windows v/s linux). 

Breaking Changes: There are lot of breaking changes in this version. I would recommend carefully reviewing these here before the start of the project to avoid any big surprises during implementation.

Ongoing development & branching: If you have a huge team of developers working on the existing project (we did in this case), you need to keep the upgrade branch updated regularly. Have a solid branching strategy figured out on keeping the old and new in sync. This along with ongoing QA can be challenging as new functionality and features will need to be merged in and tested. 

Deployments: Make sure you account for creating build & release pipelines, CI/CD etc. There may be instances where the existing DXP deployment pipelines do not work with the new DXP. In our project, the bundled js and css files weren't getting deployed correctly (due to differences in .NET & .NET Core build). 

Content Freeze: This may not impact the budget but does affect the timeline. Content freezes are essential and need to be co-ordinated with the client as we get closer to the finish line. Ensure you are accounting for how long the content freeze will last and 

Code freeze: It may be a good idea to freeze any code development (or keep it to minor bug fixes) before going LIVE to prevent introducing new bugs. Adding new features may add new defects, which could potentially delay the Go LIVE.

Go Live Prep: Ensure the right people are available for GO LIVE, ex: IT team with DNS access needs to be involved to switch from old to the new DXP environments (this is a two step process). 

Add Buffer: Always buffer your estimates for unknowns. Depending on the complexity of the project, there's a chance you missed something which could potentially take hours (if not days) to figure out & completely derail the project.

Hope this helps! In Part 2 of thia series I will talk about implementation & known issues to bypass.