Part 5 – Putting it all together
As I write this post the migrated Coconut Tickets built with Laravel has been live for 3 weeks without any major incidents. There have been some small bumps in the road but with careful scanning of log files and with caring users that do report problems, it has been possible to fix issues as they have arisen.
In previous posts in this series I explained the strategy and then the technical approach to migrating the Coconut Tickets platform from WordPress to Laravel. This post will bring all these parts together as I describe the process of migration and share our final conclusions.
Our process of migration can be described as:
- Analysis of the use of WordPress in the plugin
- Identification of Laravel replacements for WordPress functions and services.
- List down any new developments needed as part of the migration.
- Migrate a chunk of the plugin at a time to meet achieve one technical spike.
- Repeat point 4 until all technical spikes are complete.
- Revisit each migrated chunk, complete the migration and make it production ready.
- Regression test comparing it with the original WordPress application.
You will remember that in the strategy I stated that improvements would be made iteratively. The repetition of point 4 and the revisiting of work already done in point 6 is the embodiment of these iterations.
Also, you will see the clear use of the technical spikes in this process. Remember that we carefully chose our spikes to be easily described tests that would really prove pieces of the solution were working in Laravel (e.g. display the event organizer dashboard).
At this stage you might be wondering why we didn’t complete the migration of a chunk while we were working on it instead of coming back and finishing it later on. This was because there is always a risk that in achieving a technical spike the solution will have to change from what was planned, this change can have a knock-on effect leading to changes elsewhere. So if you avoid finishing the migration in the finest detail and a change has to be made then making that change is less painful than if you thought you had finished.
We followed the process as planned. There was a lot of iteration and some technical solutions had to change (for example the solution for privileged versus public Ajax calls). What did take longer than planned was the migration from Bootstrap 3 to Bootstrap 4. Although these two CSS/JS frameworks look very similar, in practice many pages wouldn’t display or displayed badly until specific Bootstrap 4 changes were made.
It took less than 300 hours to migrate Coconut Tickets to Laravel. This is around one tenth of the time it took to build Coconut Tickets on WordPress in the first place. We can imagine that a rewrite of Coconut Tickets in a new technology would have taken a lot more than 300 hours and therefore the idea to migrate and not to re-write was a good choice.
- WordPress can be used as a platform for building transactional applications but there is little support in WordPress for doing this.
- Laravel is very productive for building web applications and the framework fully supports it.
- Both WordPress and Laravel are PHP based but there are lots of differences, sometimes on Laravel I forget I am writing PHP because it feels like working at a higher level.
- It is possible to migrate some applications from WordPress to Laravel.
- WordPress has great plugins, but they can all be replaced, they should not be a reason to feel locked into WordPress.
- Migrating from Bootstrap 3 to Bootstrap 4 has a lot of hidden surprises.
So why continue with your application on WordPress when you now know at least one way of migrating it to Laravel!
Find out more about Coconut Tickets