Webshop migration

If you decided it’s time to invest in a new and improved infrastructure, you’re probably wondering how to do a webshop migration without knocking it offline. To help you with this process, we’ve described how we prepare for the webshop migration, what steps do we take to ensure everything goes smoothly and how we confirm everything is working as expected.

But first things first:

We can migrate some websites with almost zero downtime; however, webshops do not fall into this category. Considering customers are regularly purchasing products online, there is a high chance a customer will try to buy something from the old webshop during the migration process. As a result, the webshop might not fully process the order, and your customer will be unhappy.

During the migration process, we synchronize the complete codebase, media content and databases to reduce the likelihood of such situations occurring. The codebase and media content migration can be done incrementally, which means we synchronize only the differences several times. However, if you’re moving from a different provider, the database has to be migrated fully, which means a full database dump and import to synchronize the discrepancies.

There is no way to migrate a webshop without any downtime; however, there are certain steps you can take to ensure minimal service disruption.

Time estimate + dry run

To migrate as quickly and as effectively as possible, we (system engineers) first establish a detailed estimate of the time needed to resynchronize filesystem content (media and codebase), as well as the time it takes to resynchronize the base (dump + import).

This process helps us do a dry run of the migration, while also setting up a test version of the webshop on the new infrastructure. As a result, the developers, quality assurance team and the customer can check webshop functionality before the migration to avoid unforeseen bugs and issues which would otherwise occur after the migration.

Lowering TTL

Prior to the migration, we make sure to lower the time to live (TTL) value of all DNS records related to the webshop to ensure faster propagation of new DNS records after the migration is completed.

In practice, this means that we usually lower TTL values to 300 seconds (5 minutes). This allows quick propagation of changes and eliminates the scenario where some visitors are still reaching the old servers, which is common when TTL value is left at high value (e.g. 4 hours) and visitor’s DNS cache is still returning old information for the next couple of hours.

Inform customers and third-parties

We also always advise our customers to inform their end-users of the planned downtime due to maintenance and let them know when the downtime will occur. With that in mind, it’s always a good idea to prepare a splash screen before the migration and put the webshop in “maintenance mode”, either through the webshop administration or through rewrite rules on the server.

The splash screen should inform your customers of the planned maintenance, so they know you have everything under control. Otherwise, customers might try to use the webshop as usual, and won’t be able to do so because the webshop is offline. Such situations will inevitably lead to customer complaints, which is why it’s vital to keep your customers informed throughout the migration process. If your customers are aware of the maintenance, and experience issues with the webshop during the migration process, they won’t be as bothered, even if the migration takes a bit longer.

We also advise our customers to communicate the downtime window with any third parties to eliminate unforeseen migration issues (e.g. developers, ERP integrators, quality assurance team, etc.).

The length of a migration process largely depends on the webshop size (i.e. the amount of data in the webshop database).

Technical factors are mainly:

• The size of the database on the source server
• Database export speed on the source server
• Data transfer speed between source and destination servers
• Data import speed on the destination server (depending on source database size)
• Time to propagate DNS records (which is why it is important to reduce TTL values beforehand)

During the migration preparation (test) phase, our system administrators usually record this information and will try to optimize the process as much as possible.

The migration time, therefore, depends on the aforementioned technical limitations. However, the time needed to do the final checks by the developers and the QA team should also be taken into account. The verification process optimization should also be done during the migration testing phase.

In some cases, if the technical circumstances allow it, we’re able to to make an asynchronous replication of the database, so we can synchronize databases almost in real-time. With such migration, the migration time will be shortened by the time needed to move the database during the final phase of the migration.

Some of the reasons why this would not be possible are:

• Obsolete (end of life) database software on the source server
• Network firewalling on the source server
• Proprietary cloud database solutions (DaaS – database as a service)
• insufficient resources available on the source server to establish replication (disk space, disk IO, high CPU usage), which would disrupt the normal operation of the webshop

Our system administrators will assess if such an approach is technically feasible. 

To minimize the impact on sales and end-users, we usually do migrations during periods of low traffic. However, we never do migrations in the middle of the night, as we still might need support from third-party providers (ERP integrators, payment gateways, etc.) in case of any issues.

During the migration period, we advise our customers (and their developers) to put the webshop in maintenance mode so as not to receive and/or process backend orders.

To avoid missed order situations, it is important in this scenario to:

• Have a fixed maintenance page for admin as well as frontend
• Disabled cron jobs and automated tasks
• Disable any integration with ERP systems

After resynchronization, the Ops team will allow web traffic to the webshop for developers and a quality assurance team so they can do the final webshop functionality check. While they check the webshop, we keep track of all possible error logs on the new system as well as the amount of response status codes returned by the webshop.

If the development and QA team confirm everything is working correctly, we release the webshop online for the general public, while we continue monitoring logs and metrics closely. At the same time, we enable automation, cron jobs and integrations with ERP and/or third-party systems. 

Alternatively, if there are blockers after resynchronization, it is essential to record them in detail so they can be resolved as soon as possible. In that case, we switch back to the old system while we (or the developers) resolve the blockers.

Once we migrate the webshop fully and it’s up and running on the new infrastructure, we continue monitoring webshop functionality and stability for a while longer to confirm everything works as it should. After we confirm everything is ok, the customer can then decommission their old infrastructure to avoid double costs.

And that’s it! Now you know how to identify and resolve most common webshop stability issues, how to monitor your webshop to ensure it’s working properly, and what to do if you decide to migrate to a new infrastructure. We hope these articles will prove useful, and as usual, if you need a hand with all of this, we’re here for you. We’ve worked with many webshops in the past, helping them resolve stability issues and moving them to better infrastructure. We’ve also recently successfully migrated a webshop overnight. If you’d like to read about it, check out our case study.

Otherwise, get in touch and we’ll be happy to help improve your customers’ user experience.