From my point of view, the Magento people and especially its software architects came to the conclusion that making a simple update or change in the implementation modality was not enough to achieve with their commitment, which was to continue Keeping Magento at the top of the best e-commerce platform on the market, and if they really wanted to achieve it, they should consider revolutionizing their internal architecture, the way CORE was implemented and even more so the form and metric that the implementer and developer who expanded their platform should achieve.
Magento 1.x is not that it was so bad, the problem is that the bad thing was to leave it as it was easy to corrupt, leaving the responsibility on the side of the implementers and developers is something not very recommended, Magento believed that for us developers to review over and over again the steps to achieve a store in the best conditions were following their instructions to the letter no matter that we could avoid steps, stop doing it as it should be or even invent our own ways of implementation, this at the end of the day they ended up in a project that it was better not to touch something else because it was a huge mess.
Magento 2 has come to revolutionize many of the features that were in its previous version Magento 1 as well as to implement new improvements that could already be achieved in version 1.x the problem could be that some series of steps had to be carried out, including some even complex to achieve the expected results.
Magento 2 evolved from within
Redesigning the architecture, the methodology and better yet the most sophisticated forms of implementation including integrating the best of the best giving Magento 2 a state-of-the-art FullStack, the best of the results has been achieved, ensuring that Magento continues to be the King of platforms of electronic commerce and it is that to this day I do not know a tool that contains everything that an electronic commerce system should have.
Let’s start with Migration
Let’s get down to work and start with the first thing we need to know to migrate a store that is created in Magento 1 to a store in Magento 2, I take the opportunity to comment that at some point I will make an article where I comment that no there was no magic tool that could achieve it for us to do that which in the theoretical text seems to make sense: Migrate a product 1 to a product 2 from the same supplier! ,
Preparing the migration recipe
We are going to start by defining three concepts that I use to simplify the migration and make it easier than it seems if we manage to carry out these three steps, the migration will be a success:
- Current store review
- Make a migration plan
- Use MAGENTO’s data migration tool
Of course, I will describe each point in detail and if possible I will break it down into unique concepts for a better understanding.
Current store review
This point is important since the first thing to assess is the current state of a productive store created with Magento 1 and many technical issues such as migration time and complexity will depend on this.
It is worth mentioning that I am going to break down a specific point from this concept and it is the Code Audit.
This point will be carried out by the software architect, the technical leader or that person who specializes in Magento both in 1 and in version 2 since it is practically the one who could know the current state of a store before being migrated.
The code audit is practically reviewing a series of aspects of the store to be migrated and knowing if these are feasible or will require work by the team of developers assigned to the migration task.
The general idea is to have a current Magento 1 store that is as stable as possible and that supports an update to the latest version available, that is, if we have a store in Magento 1.8 that we can upgrade or successfully update to version 1.9 as this puts us in a stable store panorama.
For the code audit to be successful I am going to leave a list of actions to be taken to achieve this goal:
- Review of Magento CORE in optimal condition
- Clean template review without built-in business logic
- Third-party extensions review
- Custom extensions review
- Review of unused extensions
- Review of installed TEMA
Review of Magento CORE in optimal condition
At this point we are going to take into account a couple of things but before let me tell you, I remember when I had to lead projects in Magento 1 Stores as there are still many bad development practices, as it is so simple that the developers cannot overwrite, customize or move some native Magento functionality and they do it directly in the Magento Core they place code directly in the vendor, every experienced programmer knows that this is an infallible rule. The Core is never touched! If this is the case and we detect that the Core has been modified, the first step is to move all that code to custom modules created with the best practices and Magento rules so that in the end the Core is completely clean without any changes.
As TIP, what I normally apply is to download a clean version of the official Magento page, I place it in a local environment and at the same level I download the project to analyze and compare both versions of code to detect which module or file has undergone any change, They can rely on the WinMerge tool that will detect if a file is different from another, and will even indicate the exact lines where it will detect a difference.
In the end, we do not guarantee that the CORE is stable and it is completely clean without any modification we would be ready with this point.
Clean template review without built-in business logic
Business logic or how the Business Layer or Intermediate Layer is technically known without getting into technicality in other words, we are going to analyze the views in particular all the custom .PHTML files or our components and extensions that do not contain lines of code that all programming that should be in the classes of our Controllers and that we find included directly in the views, we will have to perform a review of each file and validate that the view is clean of business code,remember that in the MVC model that you try to handle in Magento 1 the rule is that the part that corresponds to feed business data are the Blocks that in turn are in communication with the Controller classes that are in charge of the interaction between the client the action against the data model, our task here is if business logic is located in the views is to create their corresponding blocks and controller class to only leave the views with the corresponding code.
Third party extensions review
Third-party extensions are all those extensions that were acquired from Magento Connect as well as those that are developed by an external provider, here it is best to first of all check with the provider that has developed the extension since in the vast majority if not is that in particular any serious provider already has a specific version for Magento 2 so we will have to make a list of all those extensions and validate which ones already have a module for version 2, if not those extensions that ultimately do not have a version for Magento 2 these if the development team will have to develop them from scratch,It is important to validate if the extension has been modified by the owner of the store itself and by this I mean that the extension is as it was downloaded from the external provider since if so it will be important to validate with a member of the business team of the store that can define the request that you were asked to modify or otherwise transmit the modifications so that the development team tries to replicate it to the new version of Magento.
In the end and having all the extensions ready and available for Magento 2 we could give this point as valid.
Custom extensions review
Unlike the previous point, the custom extensions of course are not from any provider or were downloaded from an external site since they are customized solutions that were requested by the store business at the time, so in this case there will be no version For Magento 2, in this case we must take a list of all these modules and extensions and develop their version to Magento 2 from scratch.
For this case, it will be necessary for a member of the store team with a level of knowledge of the functionalities and business rules of the current store to transmit as much detail as possible of what were the rules and needs of each module or extension requested for the purpose to facilitate development to the new version of Magento 2.
If it is not possible that it can be detailed at maximum expression, the development team will have to review each controller, view block and more components of the module to obtain a summary of what the functionality may be executing in actions and events, of course this process will be longer and more tedious.
Review of unused extensions
At this point the task would seem to be very simple but without talking about Magento 1 with my extensive experience I know that it is not so easy to check which extensions are not enabled and simply make a list so as not to take them into account in the migration, it is not a thing which would give results so easy, because there are many projects in which there are extensions that are disabled depending on the platform but a class or functionality is still performing some action or is deliberately connected with other functionality and that is due to bad development practices of the programmer that when we just delete the files of that extension that in theory was not active something strange happens and the platform no longer works as it should and even in some cases stops working completely.
For these cases, we must also make a list of all these extensions detected and carefully review one by one of these extensions, fifth each of its components, validating that the platform does not stop working if it is the case, validate the why and what is the file even the lines of code that cause such a problem.
In the end, when we manage to physically remove each of the files that belong to a module or extension and it continues to function properly, we will conclude this step.
Review of installed Theme
The topic is left for last because here it is worth clarifying a couple of things to consider and that is because, firstly, if the topic has been purchased from a page, be it Magento Connect or a recognized site that is dedicated to selling topics It is likely that there is already an aversion for Magento 2 and it would have to be acquired of course that generally if it was a paid theme you should pay for the new version for Magento 2.
If the Theme was developed to measure with respect to the business need, this is where we should use our development team so that in the same way it prepares a theme for the Magento 2 version since here we clarify that the part of themes between Magento 1 and Magento 2 is completely different, but for the development team all is not lost since Magento cared about these actions and developed a base theme called the Blank Theme of the Magento 2 version that can be used to generate a legacy base theme all the modules and sections that Magento needs to customize a Magento 2 store with a customized look and feel as any client needs.
So far we will leave this first part later, I will publish the second part to continue with this topic of migration, as you can see the information is extensive so it is better to divide it into two parts.