pecific situation…

Due to the large technological step. Depending on the size of the application, Laravel’s migration from 4.2 to 5.0 may seem overwhelming ( link to docs ) but be had harder thing to do – update 4.2 to 5.3. When I write this post already latest version of Laravel is 5.4.

// Update: Currently we are happy with version 5.4.
An additional challenge was update of PHP latest stable 7.1 with each of our development team would like to work. Probably this migration would never have happened if the application did not have enough unit and acceptance tests.

Laravel is a framework known for the regular and large API and architecture changes. It’s not that you pick up the version in composer.json, use bridge prepared by authors and you have time to update the application with fewer steps during your daily work. And here we get a pretty strong argument against the use of Laravel, which can only mitigate the existence of the LTS version (currently it is 5.2).

And the very existence of LTS in Laravel would seem obvious, but that is not true.  About Laravel’s update policy, I might write a separate post sometime.. .

Update in numbers

I think it’s good to write the results (time) that was taken to run our tests before and after the update. Here is the time needed to test in Codeception application:

Before. L4.2 and PHP5.6:


After migration to L5.3 (still PHP5.6):


Hastened quite significant. In my opinion, this is a very good result given the fact that the framework capabilities have increased. Differences in functionality and ease of use between 4.2 and 5.3 are diametrically opposed.

Unfortunately, the application did not work properly on L4.2 and PHP7.1 (laravel 4.2 did not support this version of PHP). Therefore, I am not able to upload results from this configuration.

L5.3 and PHP7.1 + opcache:


Here the speed literally blows. Duration has dropped below a minute! This is not a 100% fair result compared to the previous two because I already unlocked the opcache. Unfortunately, I do not have any screenshots with PHP7.1 without OPC, but if my memory is not wrong the time taken was about 1.3-1.4min – still a good result!

Time to deploy update on production.

Business value

It’s been a while since we’ve implemented a new release for production, so I can summarize what has been achieved:

  • Faster product performance = more satisfied customers. Especially if we are dealing with an API that delivers data in realtime.
  • Fewer AWS-EC2 instances needed to handle traffic = less cost. Profit. In this case we got rid of about 1/2 instance.
  • The most modern “skeleton”. The updated framework and programming language is what generally allows the product to grow and make it easier to maintain.


I was not sitting with my watch in my hand and counting the minutes of work, but I can honestly say that the whole thing took me ~ 40h. The application did not belong to the big (about 1.5k source files). Is it a good time? Hard to judge.

Besides, despite the knowledge of L5.3 and 4.2, there are some expected problems of library type incompatible with the new FW. As for the migration of PHP5.6 => 7.1 thankfully there were no major surprises. Several outdated methods, which are available in the first google search results and everything started working smoothly.