To decide whether to modernise existing software or rebuild from scratch, assess which parts still serve the business, map their dependencies and reserve a full rebuild for problems that targeted changes cannot sensibly resolve.

Do not approve either route simply because the software is old or a new platform looks appealing. Ask for a recommendation that explains what should stay, what should change and how the business will operate during the work. For a UK business weighing up an ageing application, that is a more useful starting point than a replacement quote alone.

What should you check before choosing a route?

FullyCoded starts legacy modernisation by mapping how the business operates and what depends on the existing system. That review comes before changes to the code, rather than treating replacement as the default.

Ask for a short, written assessment that answers the following questions. Separate confirmed findings from assumptions, and ask the reviewer to identify anything they could not inspect.

  • Business fit: which tasks does the application handle well, and which required processes does it no longer support?
  • Dependencies: which people, reports, applications and integrations rely on the system or its data?
  • Supportability: who can change, deploy, back up and restore the application, and which platforms or components need attention?
  • Change requirements: what must the business be able to do next, and what evidence shows that the current system cannot accommodate it?

Keep symptoms separate from proposed solutions. For example, write down the reporting task you need to improve before deciding that the database must be replaced. Ask the technical reviewer to explain the connection between each business problem and the recommended work.

When should you favour modernisation?

Give modernisation serious consideration when useful parts of the system can remain in service. FullyCoded's legacy modernisation approach assesses components individually, with options to retain, wrap, replace or rebuild them rather than automatically replacing everything.

Ask for a phased proposal with a useful first outcome. That might mean addressing a particular integration or reporting need before considering wider replacement. Require the proposal to explain the boundary of that first phase, what it leaves untouched and how its results will be checked.

For WordPress websites specifically, targeted remediation is the lower-cost, lower-risk option when the architecture remains understandable and business requirements have not materially changed. That is a conditional judgement, not a rule that every older application should be patched indefinitely.

When should you consider a full rebuild?

Ask for a rebuild proposal when the review identifies structural obstacles rather than a list of isolated defects. For each obstacle, request an explanation of why retaining or replacing only the affected component would not meet the requirement.

FullyCoded's WordPress rebuild guidance identifies structural problems such as an inability to support required integrations, an unmaintainable theme or content models that no longer fit the business. For a bespoke application, use the same kind of questioning, but ask for evidence specific to that application rather than borrowing a website diagnosis.

Do not make reproducing every existing feature the default brief. Ask users to identify which functions they still need, which rules must be preserved and which workarounds should disappear. Make those decisions explicit before approving the replacement scope.

How should you compare the costs?

Compare both routes against the same business requirements and assessment period. Request separate allowances for the following work rather than accepting a single build figure.

  • Discovery and delivery: reviewing the existing system, specifying the changes and developing the agreed functionality.
  • Migration and verification: moving data, checking integrations and testing the processes the business needs to retain.
  • Transition: staff involvement, training, parallel operation and the proposed switch-over.
  • Ongoing operation: hosting, maintenance, support and responsibility for future changes.

Include a baseline for keeping the current system: record support spending, recurring fixes and time spent on manual workarounds. Treat estimates as estimates, and ask what could change the price. Avoid declaring either option cheaper until the scope and exclusions are comparable.

How will the business keep running during the change?

FullyCoded's phased modernisation approach runs new components alongside existing ones and switches over after the results match. Existing components are not decommissioned while dependencies remain.

For either route, ask for a transition plan before approving delivery. Specify who will verify the results, what counts as acceptance and what should happen if checks fail. Include the reports and integrations in those checks, not just the screens staff use directly.

Also ask who will own the system after the change. Request documentation, access arrangements and a clear support responsibility as part of the handover, rather than leaving those decisions until launch.

What should you ask for next?

Before commissioning a full build, request a decision document comparing targeted improvements, phased replacement and a full rebuild. Ask it to state the recommended route, the evidence behind it, the first deliverable and the unresolved risks.

FullyCoded offers legacy audits, migration planning, phased modernisation and rebuilding where appropriate. To discuss your application, visit our legacy system modernisation page and request a conversation with Mark. Bring a list of the system's main tasks, known problems and the changes your business needs next.