Understanding the migration process to PrestaShop

This article is a guide to understand the stakes and succeed in migrating to PrestaShop. (It is not a guide to know if you should migrate or not). A migration is more complicated than a website creation, because you have to redo the website and migrate the data from the old website.

Understanding the basics of a migration

The principle of replatforming

Replatforming is a strategy for changing platforms. This strategy is common to all sites: ecommerce, blog, comparator. The current trend is towards micro-services, a new way of dividing up features. It allows for better scalability, a simpler interconnection and easier maintenance. It is a major technical change that has impacts on all professions: logistics, marketing, customer relations, content writing and of course IT. 

The other major challenge is the change of back office interface, you will have to anticipate this point and plan a training time for your teams.

Changing your CMS

The change of CMS is a sub-type of replatforming because here we only modify the CMS. Nevertheless it is a delicate operation that deserves your full attention: sometimes, the new CMS does not have the same server requirements as the old one. It is advisable to change your hosting solution so that it corresponds better to your new CMS. When you change your CMS, the way your data is stored differs, so you need to convert it to the new structure. This is an important and complex part of the migration process.

Changing your CMS version

The change of version is undoubtedly the simplest migration. However, you have to be careful about the version difference. By convention, versions are noted with 3 digits (for versions of PrestaShop prior to 8 remove the 1.: 1.7.2.1 becomes 7.2.1). 

The first number represents major versions, moving from one major version to another is usually quite complicated. For example, the theme has to be redone when migrating from 1.6 to 1.7 but the data structure is similar, meaning that the data migration will be much easier than a CMS migration.

The second number represents the minor versions, they bring less changes than the major versions and it is therefore quite simple to migrate to a minor version.

The third number corresponds to a bug fix, these are generally very precise modifications that aim to correct a problem. It is therefore important to make these migrations to ensure the security of your store. Migrations are very often transparent. The structure of the code or the database hardly changes.

As you have noticed, we often use the conditional tense when talking about migration. Even if you use  the same CMS, the customizations of your site are a significant factor and can represent a source of difficulty in any migration. The more your site has been customized, the more complicated the migration will be.

The technical process of migration

All migrations have the same process, once the specifications and the mock-up are done. This migration scheme is important to understand because it will allow you to understand the stakes of each step.

Step 1: Redeveloping

This is usually the first step of the migration on the technical side. If the data was to be migrated before the development of the code, there would be a problem because the specific data would not be taken into account. That’s why we start the process by migrating the developments: the structure of the code of each ecommerce solution is radically different, thus, everything needs to be redone.

Establishing the specifications is therefore essential to know what developments you will undertake for the new site. To do this, you can go back to the initial specifications and delete the features that are no longer useful and add new ones. Similarly, if you want to update the theme of your site, you will need to rebuild a mock-up. This will allow you to better project yourself and limit the risks of unpleasant surprises.

This stage of development is the longest and most expensive, so you need to think carefully about the features and the theme you want before you start.

Step 2: Retrieving the data

This step consists in modifying the structure and format of the data of your old CMS so that it corresponds to that of PrestaShop. This step is now well mastered by agencies, and there are modules or APIs that allow you to do the migration very easily. However, there will always be the problem of specific developments: the more specific developments you have and the more important they are, the more complicated the data migration will be. 

To address this challenge, you can do partial data migrations, for example: 

• Migrating data about customers who have placed at least one order in the last 3 years
• Migrating data about orders from the last 3 years

If you have an ERP, it will be even easier to do partial data migrations because your ERP will keep the order history.

The data migration is the real particularity of a migration, it is the complex part, because it is necessary to take back the history and sometimes to clean it. It is a process that requires a lot of rigor during the acceptance test phase.

Step 3 : Performing an acceptance test

This is a very important step and unlike the first two, you must participate in it regardless of your role. Of course the developers and the agency will perform some tests, but don’t let the agency perform the tests alone. You know your site better and therefore you are in the best position to verify that the migrated data is good and consistent with the existing. This is a key phase because it will launch the last step of the production. Don’t hesitate to start training your teams at this stage, it will help you to anticipate possible difficulties.

Step 4: Migrating and connecting

This is the last step, the production launch, the switch from one CMS to another.

Here is the procedure: 

1. Putting the old site and the new one in maintenance

2. Update the database with new customers, orders, products… There are 2 strategies to do so: 
   1. Redo a complete import like the previous one. The advantage is that you reuse a script already tested and validated. The disadvantage is that this script can take a long time to do its work which will increase the downtime. This option is often used because it avoids spending too much time on the development and acceptance testing/quality control steps. In general, the import speed for orders and customers is fast enough and the operation takes a few minutes.
   2. Make a partial import. The advantage is that it will take little time to run. The disadvantage is that you will have to redo an acceptance testing/quality control for this script beforehand and test if the delta is good. This is an option if there are a lot of orders or customers to retrieve. But it is more expensive and therefore less used.
3. Connect the different integrations. The developments must of course have been done before and tested, but it is now that they will be used in real conditions.
4. Redirect the url to PrestaShop. To do this you need to change the DNS so that they are going to the right machine. A DNS makes the link between the domain name of your site (e.g.: www.monsupersite.com) and the location of the server on the internet (IP, e.g.: 8.8.8.8). This change takes a few minutes to make but it takes time to propagate: Imagine sending a letter by post to tell your relatives that you have changed your address. Sending the letter is fast but the time it takes for the letter to reach all your friends and family may take a little while. Don’t worry, DNS propagation is faster than mail and in 1 or 2 hours everything will be settled.
5. Make your website go live (disable maintenance).
6. Enjoy your successfull migration and watch your sales increase thanks to your new high-performance site!