Coconut Tickets WordPress to Laravel Migration – part 2
Part 2 - Strategy
In
I explained the motivation to migrate the Coconut Tickets event ticketing platform from WordPress to Laravel. The implementation of the ticket design tools and transactional services of Coconut Tickets are achieved with one huge WordPress plugin. Coconut Tickets regularly sells events of ten thousand tickets at a time and the Laravel application would need to do the same. Before you think we took on too much in this migration, let me also explain that having done many migrations before (with other technologies) I had a strategy in mind that would help to control the chaos of such a big technology change. The strategy could be summarized as:
A technology migration, like this, is very complicated. If the complexity becomes too much then the project turns into chaos. Therefore, the key to avoiding this is having a strategy to manage the complexity and reduce the chaos. The biggest risk in a project of this kind is getting lost in the complexity of the task, resulting in either giving up finding that the task has become a development project. This is why I thoroughly support the idea of getting something basic working as soon as possible. It also means that you don’t have to have all the answers before you start, or at least you can change your mind on the strategy if early tests don’t work. The technical spikes are very good for this, each one is a specific test that is chosen to prove a particular part of the technical strategy is working. Here are some of the technical spikes (tests) we defined at the beginning:
The spikes are simple for anyone to understand but they require many components to be working. In the early stages if the spike says to display a page then that is enough, we would not be looking for perfect formatting as that can be achieved later on. To remain a migration project you must avoid adding new functionality. As soon as you plan to squeeze something new into the software then it becomes a development project. While it remains a migration project then it is easy to compare the behaviour between the old software and the newly migrated software. When there is a risk of chaos then being able to compare old and new is a good reliable test that can save headaches. Coconut Tickets has lots of functionality implemented in JavaScript, not just PHP. It was really tempting to consider rewriting the jQuery based JavaScript written for WordPress with Vue JS (the native JavaScript framework delivered with Laravel). But the JavaScript code was not at all WordPress specific, so it was decided to migrate it with as few changes as possible and then to take the decision to use Vue JS another day. Whether you believe that WordPress is a real framework or not, it does provide services that allows an application to be built by adding software plugins (and themes). Therefore to migrate software from a WordPress plugin to Laravel requires knowledge of how the plugin interacts with the WordPress framework, to isolate those points and then to identify (or build) equivalent services in Laravel. This analysis starts by identifying the WordPress functions that are being called by the plugin. There is certainly a “Laravel way of doing things” which is not the same as WordPress. A good example of this is the use of blades to format pages in Laravel where as in WordPress we might generate HTML code dynamically in our view class with or without a template. The goal is to get the migrated software to work in Laravel, but it needs to be accepted that the first migrated version might not be fully in the Laravel style. For example if we have hundreds of dynamic PHP view classes generating HTML in WordPress then the first migration might continue to use them. Then in later iterations we would make the software more Laravel like and therefore with our example we would make more use of Laravel blades and eventually phase out the WordPress view class. Improving through iteration in this way reduces the risk of getting lost before we deliver the software that we want. Coconut Tickets has over 100 database tables in WordPress. To be performant, and to increase the maintainability of the software, it hasn’t ever made use of the generic WordPress tables such as post and postmeta. The design of these tables may have helped WordPress add new functionality without adding new tables but from a transactional processing design point of view they need to be avoided like the plague. Having not used these tables meant that Coconut Tickets already had custom tables with few WordPress dependencies that could be migrated directly to Laravel leaving only user tables and media tables needing a solution in Laravel.
In the next part of this series we will look at the technical migration details and the important technical decisions that were taken.
Find out more about