Sometimes we open an inherited application and the code is clean, documented, and organized.
Sometimes we open it and immediately realize we are going to need coffee.
Functions are duplicated. Passwords are hard-coded in files. Nobody knows which copy of the database is current. There are folders named old, new, and new2. The production server is the only place the application has ever run.
Before we make it prettier, we make it safer.
Step One: Get a Complete Copy
We want the source code, database, configuration, uploaded files, server information, and anything else required to reproduce the system.
Then we create backups and get the application out of the production-only mindset.
Step Two: Build a Local Environment
Docker is extremely useful for older applications because it lets us recreate specific combinations of PHP, Apache, MySQL, and other services without reconfiguring the developer’s entire computer. The Docker documentation explains how containerized environments work.
Once the application runs locally, we can break things without breaking the client’s business.
Step Three: Put It in Git and Start Debugging
We put the source code into version control, establish a known working baseline, and begin tracing the important workflows. That lets us see exactly what changed if a fix creates a new problem.
We wrote more about this process in our overview of the development tools we use.
From there, our custom programming team can begin cleaning up the highest-risk sections, upgrading obsolete dependencies, and documenting the areas that matter most.
Do Not Refactor Everything Just Because It Is Ugly
Ugly code that has worked for ten years can still contain valuable business logic. We would rather understand it first than perform an elegant rewrite that accidentally changes what the company depends on.
If you have an old application nobody wants to touch, Code Team Blue is comfortable being the team that opens the mystery folder and figures out what is actually going on.