Once you and company have come to the conclusion you need to migrate, check out my other article “How to Decide Between Migrating and Rebuilding Your PHP Application”.

We need to establish what the risks are and be open and transparent about these potentials. On average an in-house migration is expensive, slow and has a significant impact on business operations. This is because most developers haven’t migrated a project before and it’s all new and they will fall into the rabbit holes of the application complexity.

We can see below the worst to best case scenario which lays out the risks of migrating pretty clearly and our decisions must be pragmatic and calculated to constantly push the outcome to the best case.
 

Full disclosure, I have overseen migrations from worst to best, trying to learn from my failures and trying to understand how to mitigate them next time. But also understanding which approach is appropriate for each business.  

The risks are not to be understated, a failed migration may force a SME to downsize or even close. However, what is the alternative? 

I recently came across a SME that is running a Phalcon PHP project, Phalcon is a C extension framework for PHP. It became popular in 2010 - 2015, but failed to gain broader traction, as of writing Phalcon has only 129 total downloads. Phalcon announced back in 2020 that the next release of Phalcon 6 would be a PHP native framework, moving away from the C extension design.  Nearly five years later and this version still hasn’t been released. 

This means the company will at some point, now or later, have to migrate to a PHP native framework or rebuild in another language. The longer they delay the more incompatible and out of date their system becomes including the underlining Phalcon framework as the community is very small, updates will be rare and most likely lack inclusion of modern language features. Due to the small community finding developers to work on such a system will be challenging. Therefore, In this case the risk for this company in not migrating outweighs the risk of migrating from a technological and talent acquisition standpoint.

I must point out, It’s impossible to say how long the application could actually continue without an upgrade. Could be a year, could be 10, before unexpected behavior starts to plague the system. Such as unexpected crashes and the appearances of unknown bugs that previously weren’t there, all of which leads to an increase in development time and cost just to maintain the application. It’s unpredictable, which is bad for business.

For this business the argument is already pretty strong for migration. Then the icing on the cake I found out they have decent test coverage. One of the biggest issues with either maintaining or migrating an application is knowing where it’s broken. If you have low test coverage you are basically fishing in the dark. Any change could break any number of features and you’d have no idea. 

Decent test coverage reduces the risk of the migration because if we know where it’s broken we can fix it more quickly, which means faster delivery of the overall migration.But many applications have few or no tests, if this is the case it must be considered in the risk analysis of the migration and will affect the duration of the delivery of the migration. 

My approach to managing risk in migration for SMEs is to:  

Migration is a tough decision that brings both risks and opportunities. While a failed migration can have serious consequences, delaying it can make your system more outdated and more expensive to maintain. For some businesses, the decision is clear—remaining on legacy systems leads to bigger challenges down the road.