Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am about to upgrade a couple of servers from PHP 5.1.6 to PHP 5.3.x, however, we host a number of old websites that would be time-consuming to fix in application code.

As I see it there are 2 solutions:

  • stick the old sites on a separate, compatible server
  • make minimal (backwards-incompatible) fixes and turn off error reporting
  • fix all backwards-incompatible and deprecated features in application code

The latter 2 options are not preferable given this would be very time-consuming -- bear in mind that there are no unit tests and such. The former will be at additional expense given we'd have to pay for and manage an additional box.

Are there any other options you might suggest trying, or what in your experience has been the best solution to managing legacy sites?


share|improve this question

migrated from Aug 11 '11 at 16:05

This question came from our site for professional and enthusiast programmers.

Have you tested the legacy code on PHP 5.3? What doesn't work? – Michael Aug 11 '11 at 13:42
I'm with Michael on this one. Usually PHP updates are done with some form of backwards compatability. (at least between the 5.x versions). You should do a test and see if anything breaks after the update. – DeviantSeev Aug 11 '11 at 13:48
up vote 2 down vote accepted

If you have a certain degree of freedom, i recommend the following:

Try having different web servers ( multiple apaches, apache + nginx, apache + litehttpd, etc...) that are configured to use different versions of php and that handle different requests to different sites?

share|improve this answer
This is a viable alternative. – damian86 Aug 11 '11 at 14:08

You will need to update the code sooner or later. Note that security patches are not applied at older versions of PHP, and it gets hard to manage multiple different platforms after a while. I have tried your first solution, having and old server for legacy sites. The problem is that it gets time-consuming for the sysadmin, especially when you try to switch platforms entirely one day.

share|improve this answer
Good point, though it's more likely these sites will be re-engineered from scratch or decommissioned, so shorter term solutions are preferable. – damian86 Aug 11 '11 at 13:52

Even if not performing a migration, there will be a time when you'll need to make sure the site works in a supported PHP environment (since PHP 5.1 will become unsupported at some point, and for example security holes might be found and won't be patched).

For that goal you will need to test the site in the new environment.

In my own experience, functional testing alone cannot guarantee a codebase is bug-free, simply because of the high entropy of input data that can make a program's behavious vary, especially in the case of a web application.

What you need to do is do extensive functional testing along with code coverage analysis.

The more tests you performs, the more the code coverage will tend towards 100%, ensuring you that more code has been tested and can be deemed bug-free.

If you can't "naturally" improve code coverage by basic functional testing, then you need to look at the "uncovered" code to try to understand how to reach it via "biased" testing.

An extremely useful PHP code coverage tool is XDebug, or you can look at this question: Code Coverage tools for PHP for a more thorough reference.

share|improve this answer
Good point but given that we have a relatively large codebase, with 0% coverage at present, I can't make a case on financial grounds to justify writing tests --- we'd be as well reengineering the codebase completely to be honest. – damian86 Aug 11 '11 at 14:07
Well, functional testing can be cheap if assigned to a team with a clear separation of tasks, without even writing anything... just "using" the web application, if you see what I mean :) – SirDarius Aug 11 '11 at 14:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.