Most businesses have at least one system that everyone depends on and nobody wants to touch: the order system built twelve years ago, or the internal portal a former contractor wrote. It still works, so it keeps getting postponed, until a hosting provider drops the version it runs on or a simple change request comes back with a quote that makes no sense.

This guide is for the person who has to decide what happens next and is not a programmer. It covers how to tell whether a system needs attention, the realistic legacy software modernization options, why a full rewrite is riskier than it looks, and how to plan and budget the work in phases.

Quick answer

You rarely have to choose between "leave it alone" and "rewrite everything". There are five practical options, and they can be combined:

• Rehost or replatform: move the system to supported infrastructure with little or no code change. Fastest, but fixes the least.
• Refactor: keep the system and improve it from the inside, including upgrading to supported versions.
• Incremental replacement: build the new system piece by piece alongside the old one and retire the old one gradually.
• Full rewrite: build a complete replacement and switch over once. Highest risk.
• Replace with a product: buy off-the-shelf or SaaS software and migrate your data into it.

For most business-critical custom systems, the safest route is to stabilize first, then replace in increments. A full rewrite suits small systems. A product suits processes that are not what makes your business different.

Signs a system needs attention

Age alone is not the problem. A fifteen-year-old system that is patched, understood and easy to change is in better shape than a four-year-old one that nobody can deploy. Three signs matter.

It runs on versions that no longer get security fixes

Every programming language, framework and operating system has a published support window. Once it closes, newly discovered security holes are no longer fixed. You do not need to read code to check this: ask your developer or hosting provider for the exact versions in use and compare them with the vendor's support page.

The table shows the position for some common building blocks as of October 2026. These dates change, so check the linked pages rather than relying on this snapshot.

These layers depend on each other. Laravel 13 will not run on PHP 8.2, so a framework upgrade can force a language upgrade, which can force an operating system upgrade. That chain is often why a "small" upgrade turns out to be a project.

Security exposure you cannot close

The UK National Cyber Security Centre's guidance on obsolete products says the only fully effective way to remove the risk is to stop using the obsolete product; isolating and monitoring it reduces the risk but does not remove it. In the US, the Federal Trade Commission's Start with Security guide makes the same basic point: outdated software undermines security, and businesses need a process for updating and patching it.

If the system holds personal data, UK organizations must also meet the UK GDPR security principle, which the ICO explains as requiring measures appropriate to the risk. US obligations vary by state and sector. This is not legal advice; ask a qualified adviser how the rules apply to you.

Nobody can change it safely

• Only one person understands the system, or that person has already left.
• Small changes take weeks, or break unrelated features.
• There are no automated tests or documentation, and releases are done by hand.
• You are not sure you hold the current source code.
• Staff keep spreadsheets on the side because the system cannot do what the business now needs.

If two or more of these apply to a system the business depends on daily, it deserves a proper assessment, even if it has never failed.

The modernization options compared

A note on vocabulary first. Developers use "refactor" to mean restructuring existing code without changing what it does. Cloud vendors use it more broadly: AWS's migration strategies use "refactor or re-architect" for redesigning an application around cloud features, and call it the most complex and costly strategy on their list. When a supplier says "refactor", ask which meaning they intend.

Real projects mix these. A common combination is to rehost to get off failing hardware, refactor enough to reach supported versions, buy a product for the generic parts, and incrementally replace the part that is specific to how you operate.

A simple way to choose

1. Is the process unique to your business? If not, look at products first.
2. Does the system still do the right job on mainstream technology? If yes, refactor and upgrade.
3. Is it large or critical, and in need of more than an upgrade? Replace incrementally.
4. Is it small enough to rebuild and test in one short project? Only then is a full rewrite a reasonable default.

Why big-bang rewrites go wrong

The appeal of a clean start is understandable. The trouble is structural rather than a matter of developer skill.

• The old system is the only complete specification. Years of special cases live in the code: the discount rule for one customer, the rounding fix for one tax scenario. Nobody remembers them all, so they surface when the new system gets them wrong. Martin Fowler makes this point in his description of the strangler fig approach: replacements look easy to specify, but the details of existing behavior are hard to pin down.
• The business cannot stand still. Either the old system is frozen and users wait, or it keeps changing and the rewrite chases a moving target.
• Nothing is delivered until the end. All of the spending comes before any of the benefit. If the budget or sponsor changes midway, you can be left with two incomplete systems.
• The cutover is all or nothing. Every feature, integration and record must be right on the same day.

Incremental replacement puts new pieces live one at a time, so real users find the gaps early and the return arrives gradually. It is not always worth the overhead: AWS's guidance on the strangler fig pattern notes that large systems benefit most, and that for small applications a complete rewrite can be more efficient.

Data migration: where projects are won or lost

Code can be rewritten. Your customer records, order history and balances cannot. Treat data migration as its own workstream from the first week.

• Inventory. List what data exists, where it lives and who owns it, including attachments and side spreadsheets.
• Clean before you move. Decide which duplicates and broken records get fixed, archived or left behind.
• Map every field. Each field in the old system needs a destination or a documented decision.
• Rehearse. Run the migration several times against a copy of real data, and time it. Protect those copies as you would production data.
• Reconcile. Agree checks in advance with the people who own the numbers: record counts, financial totals, open balances, and a hand-checked sample.
• Decide on history. Moving ten years of closed records is often the most expensive part. A read-only archive may be enough, subject to your record retention obligations.
• Keep a way back. Hold a verified backup and a written rollback plan until the new system has been through a full business cycle, such as a month-end close.

Running old and new in parallel

Any option other than a single switch-over means a period where both systems exist. Without rules, that period produces two versions of the truth.

• One owner per piece of data. For each type of record, decide which system is the master at each stage. Two systems that can both edit the same customer record will drift apart.
• Move whole workflows, not screens. Staff should not start a task in one system and finish it in the other.
• Compare outputs before trusting them. Where possible, run the new component on real inputs in the background and compare its results with the old system's.
• Write down exit criteria. Define what must be true before each old module is switched off, and who signs it off. Otherwise parallel running never ends and you pay for two systems indefinitely.

Illustrative scenario, not a client case study: a wholesale distributor runs orders, invoicing and stock on an aging custom PHP system. It first moves to a supported server and verifies its backups, then shifts invoicing to an accounting product, then rebuilds order entry as a new web application that reads stock levels from the old system. Stock control, the most intricate part, is replaced last. At every stage the business has a working system.

Planning and budgeting in phases

A phased plan lets you approve spending one decision at a time, with evidence from the previous phase.

1. Assessment. A short, fixed-scope review of versions, code condition, integrations and data quality. The output is a written recommendation with options, not a commitment to build.
2. Stabilize. Secure the source code and credentials, verify backups by restoring one, restrict access, and get onto supported versions where feasible. This reduces risk whatever you decide next.
3. First slice. Replace or refactor one meaningful, low-risk part end to end, including its data. This proves the approach and gives real figures for estimating the rest.
4. Remaining slices. Ordered by business value and risk, each with its own scope, acceptance criteria and go-live.
5. Decommission. Archive the data, switch off the old system, and cancel its hosting and licenses.

We do not quote figures here, because an honest number depends on the assessment. The main cost and timeline drivers are:

• The size of the system and the number of distinct workflows.
• Whether automated tests and documentation exist.
• The number of integrations, and whether they are documented.
• Data volume, data quality and how much history must be carried over.
• How many versions behind the technology is, since upgrades are usually done in steps.
• How long old and new must run side by side, and how much of your staff's time is available for testing.

Two items are often missed: the cost of running both systems during the transition, and a yearly maintenance allowance afterwards, because the new system will need version upgrades too. If you plan to use an external team, our guide to outsourcing software development from the US and UK covers contracts, code ownership and pricing models.

For technical readers

• Characterization tests first. Capture current behavior at the HTTP or database boundary before changing legacy code.
• Route at the edge. A reverse proxy or API gateway that sends each route to the old or new application is the usual mechanism for incremental replacement. It is also a potential single point of failure.
• Avoid a long-lived shared database. Prefer one-way synchronization with a clear owner per table, and put an anti-corruption layer between new code and the legacy data model.
• Do not default to microservices. The strangler fig approach is about gradual replacement; the target can be a well-structured single application.

Frequently asked questions

Is it cheaper to rewrite or to refactor?

It depends on the state of the code and the size of the system. Refactoring is usually cheaper when the system does the right job and the technology is still mainstream. A rewrite becomes competitive when the system is small or the technology can no longer be supported.

Can we keep using software that has reached end of life?

It will keep running, but new security vulnerabilities will not be fixed. Some vendors sell extended security updates for a limited period, which can buy planning time. Isolating the system reduces the risk without removing it, so treat it as a temporary position with an end date.

How long does legacy software modernization take?

There is no reliable general figure. It depends on system size, test coverage, integrations and data quality. A phased plan gives a firm estimate for the next phase and a rougher one for later phases, which is more honest than a single date for everything.

Do we need to stop new feature work during modernization?

Not with an incremental approach. New features are built in the new system while the old one receives only essential fixes. A full rewrite is where a feature freeze becomes hard to avoid.

Conclusion

Outdated software is a business risk decision more than a technology one. Check your versions against the vendors' support pages, be honest about whether anyone can safely change the system, and pick the least disruptive option that solves the actual problem.

A sensible next step is a written assessment of one system: its versions, risks, options and a rough phase plan. Entrant Technologies builds custom software and web applications, including Laravel development for PHP systems that need upgrading or replacing. If you would like a second opinion on a specific system, you can describe it and request an estimate.