So you have a medium to large PHP codebase that is… well let’s just say it’s not a spring chicken anymore. Not that there’s anything wrong with that. It does what it needs to do and it does that well.
So, everything is awesome! Except…
Well except that your code still uses the old deprecated MySQL Extension.
But that’s not really a big deal, is it? People have been going on about this for years. It’s not that you aren’t aware of the reasons you should upgrade. It’s just that you never got around to actually doing it. Anyway, your system is doing just fine as it is, right? Right?
Well, that may have been true up till recently, but the situation is becoming a bit more urgent. This is not something you can afford to put off much longer. Let me explain why…
This means that if your codebase still uses the MySQL extension, your system will not work on PHP 7. Having any code that uses the old extension rather than one of the alternatives is effectively keeping you stuck on PHP 5 by preventing you from upgrading to PHP 7.
This version lock-in situation has probably not been too big a deal for you up till now. You have things running just fine in PHP 5. Sure PHP 7 looks awesome, but your system doesn’t really need the new features and you couldn’t justify the upgrade effort. Sure, you were probably even able to maintain a decent level of security with the old MySQL extension if you did things like escaping your queries properly. Unfortunately, this is not a viable position anymore, because…
This means, that starting 2019 there will be no more security updates and patches for PHP 5. So any system or site running on PHP 5 will become inherently insecure.
In addition, PHP 5 has already started to disappear from OS package managers, hosting services and other sources. As a result, it will become increasingly difficult to set up or find a place to host your PHP 5 system when you need to move it.
All of which means that if your codebase is still locked into PHP 5 by its dependence on the MySQL extension, come 2019, you are in going to be in for a rough ride.
All of this means that you should seriously start working a migration strategy for codebase now.
It’s important to know that the process of converting your code could take a significant amount of time. How long exactly depends on a number of factors such as the size and complexity of your codebase, which technology you choose to replace the old API and the resources available to you.
Time is ticking. Start looking at your code and researching your options. Then come up with a plan and start converting. The longer you wait the harder this is going to get.
I’ll be posting a series of practical articles and resources to help you with the choices, planning and the actual migration process. Subscribe below if you don’t want to miss them.
Did this help you?
Sign up for my newsletter and I will send you regular articles and other goodies.Sign Me Up!
You can unsubscribe at any time