Try our conversational search powered by Generative AI!

Aniket
Dec 19, 2023
  237
(2 votes)

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. 

Dec 19, 2023

Comments

John walsh
John walsh Dec 20, 2023 12:21 AM

I would also add database backup's to the list

Aniket
Aniket Dec 20, 2023 12:24 AM

Hi John, good point. I am not sure if they add to the timeline though. Usually DB backups are click and forget and I also added "onboarding time" which includes backups/restore for DB etc.  

Please login to comment.
Latest blogs
Optimizely Web... 6 Game Changing Features in 2024

If you are interested in learning about what's new within Optimizely Web, you are in the right place. Carry on reading to learn about the 6 greates...

Jon Jones | Mar 3, 2024 | Syndicated blog

Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog