Every agency has one: the old site nobody wants to touch. It still makes money, the client still wants updates, and every deployment feels like defusing a bomb.

We took over one of these through a US agency partner. The client is a large consumer brand. The site powers a yearly campaign with heavy traffic in a short window. It runs on an older PHP codebase, and changes were deployed by uploading files over FTP straight to the live server.

The obvious answer is "rebuild it." The real answer was: not this year. The campaign date was fixed, the budget was for updates, and a rewrite would have added risk right before the busiest weeks.

So we made the old system safe instead.

Step 1: Get the real code under version control

What was on the live server did not fully match any copy anyone had. We downloaded the live files, committed them to Git as the starting point, and treated that as the truth. From then on, nothing went to the server unless it was in Git first.

Step 2: A copy of production we could break

We set up a staging copy with the same PHP version and server settings. Old PHP apps often break silently when the version changes, so matching it exactly mattered more than making it modern.

Step 3: Make deployments boring

FTP stayed (the hosting required it), but people stopped uploading files by hand. We scripted it: only changed files go up, the previous version is kept, and rollback is one command. rollback time, under 2 minutes.

Step 4: A short checklist before every release

Ten minutes, every time: key pages load, forms submit, tracking fires, nothing new in the error log. Not clever, just consistent.

Step 5: Fix only what the campaign needed

We resisted the urge to clean up everything. Each change was small and tied to a business need. We kept a written list of the deeper problems, ranked by risk, for when the client is ready to rebuild.

The result

10 releases through the campaign period, zero rollbacks needed & deploy time went from about an hour of manual work to 5 minutes.

The trade-off we accepted

This did not make the code good. It made changing it safe. The site still needs a rebuild, and we've told the client that plainly, with a cost and timeline. Hiding that would make the next team's job harder, and it would probably be us.

For agencies

If you're carrying a legacy site like this, you don't have to choose between a risky rewrite and crossing your fingers. Version control, a matching staging server, scripted deploys and a checklist get you most of the safety for a small part of the cost.

We work as a white-label tech partner for agencies in the US. Talk to us about a legacy site you're stuck with.

We inherited a fragile PHP site deployed by FTP. Here's how we made it safe without a rewrite.