The biggest mistake that 90% of the agencies do when upgrading a Magento 2 Commerce to a stable version is not planning accordingly with each client. My goal with this article is to introduce you to the basis of an upgrade strategy and measurements to do before starting to code. If you want to have guidance or help with this process don't hesitate to contact me.
The mindset to perform the upgrade most of the time must be to avoid bottlenecks, mistakes and predict risks. Facing two ways to go, time and cost versus risks and tests, you’ll want to either go to the slower and safest than to the quicker and broken way.
How to detect not trustable estimation
We have exceptions to almost everything upgrading Magento 2, there are many different scenarios, but to someone who doesn't have a technical architect background, these easy points might help to do the right questions to your agency and developers.
- Template of estimation to upgrade any project or version.
- There’s no analysis phase.
- Unique overall estimation.
- There’s no timeline for each phase.
- Not predict the out-of-the-box modules and bug fixes to the next version.
- You don’t have a list of risks and critical points to take business decisions.
- The same amount of hours to upgrade a small version to a bigger version, e.g. from Magento 2.4.1 to Magento 2.4.2 and from Magento 2.3.6 to Magento 2.4.3.
A clear vision of what will be done, when, and how your team will achieve it is the goal of the doc, I personally don’t see many developers doing these analyses with clients, you will have it from a Technical Architect, Business Analytics, or Lead Developer.
Upgrading Magento 2 in 6 steps
These below are the main steps that I recommend going through to understand your customer and project.
- Getting information
- Measuring risks
- Preparing for the technical step
- Step-by-step
- Clean as you go
- Finishing and measuring
1. Getting information
The getting information step is the data that you have today about the current project setup. E.g. the number of products, customers, product variations, particularities of the project, integrations, age of the project, current Magento version…
As an initial report, we’ll obtain the most important information to proceed, but it’s essential to keep a wiki to keep your finds.
2. Measuring risks
Measuring risks is the most missed point by merchants and agencies. Here we’ll make sure we’ll measure the risk of upgrade to one version or another based on your current and future scenario, checking if we have integrations with PIM, POS, ERP, OMS, CMS, or other systems. We will check the modules bought, custom modules created, and everything that will change the estimation, risk, and cost. Most of the time we will need to discuss the topics with a business decision-maker in order to decide if something worth the risk of each approach.
3. Preparing for the technical step
You will see agencies doing the initial plan, then starting to code to do the upgrade. Doing the initial strategy and business analyses but not the technical strategy to achieve it. At this point, the lead developer and the technical architect must talk with the team and create a “getting started” documentation.
The goal is to show where to go, the technical architect and the lead developer will be the most experienced technical persons to predict bottlenecks. A simple example is when the guidance is to use the out-of-the-box feature instead of building a module or to avoid implementing something that caused issues in other projects.
4. Step-by-step
With the experience of the lead developer, technical architect, and development team we can have a step-by-step to create a feedback cycle. The goal of this strategy is to have frequent and continuous validations and deploys.
If you see complaints about it, it’s probably because they aren’t predicting possible scenarios or because they are focused on the cost and not the reliability. When we have a production store the cost of losing customer experience is higher in the long term than perform more validations.
5. Clean as you go
If you don’t have a clean routine, it’s good to set up one as soon as possible. In case you left things to be cleaned (e.g. old modules, bugs, code to refactor) this is the time to cleaning them and to set up a new cleaning routine. More important than do the cleaning is to do it constantly, it’ll be cheaper and faster for your team. I highly recommend setting up automated tests to check the code quality and the maintainability of the code.
The lead developer is the one that might take the main role in this step. The pattern to follow the tools to use and the logic of it will most of the time is created and monitored by the lead developer.
6. Finishing and measuring
When finishing an upgrade, we must follow the same approach as new implementations, which is to monitor it and measure it. Since we had a clear vision about what has been updated and the metrics already set, we might put in place tools to check the impact of the changes in the layout, performance, customer experience, or security that might change due to the new implementations. As sooner as you notice something wrong, as better and cheaper it will be to you. But if you’re not keeping an eye on it, your client must call you to complain about something broken to your team see that the implementation made 2 months ago didn’t work well.
The measurement is not applied once at the end, it’s running since the first phase continuously.
Thanks
Thank you for checking this article, if you need help to predict scenarios and measure possible risks during your integrations and new implementations please let me know!
Top comments (0)