"We are too scared to touch that system".
This is a nearly guaranteed sentence you are bound to hear sooner or later if you work with any sort of technology related systems. The causes can vary from company to company but it usually boils down to "we don't have enough time to deal with it" or "the original dev left the company". Another very common cause can be starting a new project without laying the necessary foundation on which to build on. This leaves the dev team constantly chasing instead of being able to confidently develop a modern system.
A regular response here is developers start creating "micro services" because for a period of time it allows them to develop on a new system where they can make some measurable progress. You continue to build until until again complexity creeps in and you have created a monolith that locks many other systems into it. At some point you need to update 5 separate systems and 3 databases to get a release out. Your releases have major bugs each time. Your dev team starts throwing around the need for a new microservice and you start discussions again all over. Gridlock!
The good news for you is, this can be fixed! The bad news is: It requires time, planning and effort. This is not something you can force on your team. You need to have buy in from everyone along with the courage to learn new things along the way. Modernising a legacy system can be scary because it removes the "familiar" element of your day to day work but is essential in allowing you to continue do that work many years into the future.
I can help you through that process!
I can assist your team in getting your legacy PHP system modernised in a controllable manner. This could mean having your PHP code just serve as a REST JSON API and leave the frontend rendering to other technologies (React, Vue) or simply helping you run it on the latest version of PHP.
My strategy between companies is usually the same. Without a solid foundation your team cant deliver on its potential. This means building out a reliable and robust CI / CD process to give your developers feedback during the development process. This can be broken down into the major points:
The first step before making any code changes is getting a reproducible build of your system as is. That means we need to be able to cleanly reproduce your current system and run it on another machine. At the end of this process your team will be able to run the whole system on their own local dev machine and everyone running on the exact same settings. "Works on my machine" is a thing of the past.
By [[reversing the testing pyramid]] we start out by gradually testing the critical paths your end users take. This allows us to build trust and become familiar with the process of checking our work before shipping it out to end users. This is literally done by opening a browser and having it automatically click through your system.
This part is essential in giving us a very broad test sweep of your system. If we break parts of the system we should notice it here fairly quickly and easy without having to get into the nitty gritty of unit testing individual components of your system. The only thing we want to know is, does your shopping cart or order process work for the end user.
Even nowadays I still come across systems that don't have a package manager. A package manager allows pulling third party (code not written by your team) dependancies in a reliable manner. If your system has third party libraries copied / pasted into its source code this is where we start by trying to switch to the exact same version but managed through the package manager. Hopefully you have not made custom changes to these "third party" packages.
At this point we start digging a bit deeper into the system. Initially we are just focused on getting an entry point to test the system in a command line environment. A common question is "why not just leave it at the high level end to end tests?". The short answer is time. Booting a browser and having it click through can be quite slow. In the same time that one end to end test runs through we can have tens / hundreds of unit tests running across your system.
Unit tests allow your developers to test the internal workings of your system and is integral in building out that solid foundation we are trying to reach.
It is only at this stage where we start the actual active process of upgrading your system. The preceding steps have give us the insights and feedback we need to start making changes to the system without breaking the whole thing.