You Inherited a Legacy Codebase: What to Keep and What to Bin

Many UAE businesses inherit a website when a freelancer moves on, an agency closes or a staff developer resigns. The new owner often receives a server login, a code folder and very little explanation. Some of that code may be solid and worth keeping for many more years. Some may be a security risk that nobody has updated since launch.

This guide explains how to assess an inherited codebase before deciding what to keep, fix or replace. It covers account access and backups, supported software versions, safe testing methods and gradual replacement of weak parts. It uses PHP's official support schedule and Martin Fowler's description of the strangler fig approach. Each section ends with a short answer for decision makers.

What should you secure first when you inherit a codebase?

Start by confirming you control every account the website depends on. That includes the domain registrar, hosting, database, code repository, email sending service and any payment or analytics accounts. Change shared passwords and remove access for people who no longer work on the site.

Next, take a full backup of the files and database, then restore it somewhere separate to prove it works. A backup that has never been restored is only an assumption. Store copies away from the live server so one hosting failure cannot remove both at once.

Quick Answer

Confirm ownership of the domain, hosting, database, repository and connected services, then remove former developers' access. Take a full backup and restore it somewhere separate to prove it actually works.

How do you check whether the software stack is still supported?

List the versions of everything the site runs on, including PHP, the database, the framework or CMS and each plugin or library. Then compare each version against its official support schedule. Outdated components often explain mysterious errors and slow pages as well as security exposure.

For PHP, the official supported versions page shows security support for PHP 8.2 ending on 31 December 2026. It warns that users of end-of-life releases may be exposed to unpatched security vulnerabilities. A site still running older PHP needs an upgrade plan before new features.

Quick Answer

List versions of PHP, the database, framework and plugins, then check each against official support dates. PHP 8.2 security support ends on 31 December 2026, according to the PHP project.

How do you judge whether the code is safe to change?

Check whether automated tests exist and still pass reliably. Then confirm a developer can set up a working copy of the site locally or on a staging server. If nobody can run the site outside production, every change becomes a risk to live customers.

Look for code where one change breaks unrelated features, such as shared functions edited in many places. Note pages with no clear owner, duplicated logic and hard-coded passwords. Our guide to rebuild versus refactor decisions explains how to test small repairs before committing to a rebuild.

Quick Answer

Check for working tests and a staging copy, because changes without them risk live customers. Note tightly coupled code, duplicated logic and hard-coded passwords before planning any significant code changes.

Which parts of a legacy codebase are worth keeping?

Keep code that works reliably, matches how the business operates today and can be changed without breaking other features. Business rules that took years to refine, such as pricing or booking logic, often deserve careful preservation. Content and URLs that bring search traffic should also stay.

Replace parts built on unsupported software, parts nobody understands and parts that cause repeated support requests. Score each module on business value, security risk and ongoing cost to maintain it. That turns an emotional rewrite debate into a clear list your budget can follow.

Quick Answer

Keep reliable code that reflects current business rules and can be changed safely by developers. Replace parts on unsupported software, parts nobody understands and features that keep generating support requests.

How do you replace the parts that are not worth keeping?

Replace weak parts gradually instead of rewriting the whole site at once. Martin Fowler describes the strangler fig approach as moving pieces of behaviour from the legacy system into new code over time. He notes that because each component is small, introducing it carries less risk.

Start with the module that combines high risk and high business value, such as an outdated checkout or contact form. Release it, then monitor it closely before moving on. Our guide to phasing a big rebuild around cash flow covers budgeting for that approach.

Quick Answer

Replace weak parts gradually using Martin Fowler's strangler fig approach. Start with modules that are high risk and high value, release each one carefully and monitor results before moving on.

Main Takeaways

Secure every account and prove your backup restores before touching any code. Check PHP, database, framework and plugin versions against official support dates, as PHP 8.2 security support ends on 31 December 2026. Keep reliable code that reflects current business rules and protects search traffic. Replace weak modules gradually rather than rewriting everything at once, starting with high-risk, high-value areas.

Assess first, then decide what to keep

An inherited codebase is rarely all good or all bad, even when the previous developer left in a hurry. List the accounts, versions, tests and modules before anyone proposes a complete rewrite. Score each part by business value, security risk and ongoing maintenance cost. That evidence gives you a sensible, phased plan instead of a costly guess.

Auronix offers website recovery for UAE businesses, including audits of inherited code, hosting and access. Send us your live website address, hosting details and any documentation the previous developer left. We will check security, software support and code quality, then explain what to keep, fix or replace. Request a quote to start with a clear, written audit of your current website and hosting.

Sources & References

The PHP Group - Supported Versions - https://www.php.net/supported-versions.php (checked 2026-10-09)

Martin Fowler - Strangler Fig (22 August 2024) - https://martinfowler.com/bliki/StranglerFigApplication.html (checked 2026-10-09)