Legacy Software Modernization

Signs that a system needs modernizing

An old system is not a problem in itself — many run for years. Trouble starts when the cost and risk of change grow faster than the value the system delivers. Typical signs:

• an unsupported runtime: PHP 5 or 7, .NET Framework, Python 2, AngularJS, old Java versions, Delphi or VB6;
• no more security patches for the libraries or server in use;
• every fix breaks something elsewhere, and there are no automated tests;
• knowledge of the system lives in one person’s head;
• developers for the technology are hard to hire;
• the lack of an API blocks integration with new tools, a mobile app or partners;
• deployments are manual, done at night and with crossed fingers.

Strategies: from rehosting to rewriting

Modernizing does not automatically mean rewriting everything. For each part of the system we choose one route:

• rehost — move to a new environment without code changes, for example into containers or the cloud;
• replatform — upgrade the framework and runtime with the changes that requires;
• refactor — improve the code structure while preserving behaviour;
• rearchitect — for example split out modules or services;
• rebuild selected parts;
• replace with a ready-made product, or retire unused functions.

The safest pattern is usually the strangler fig: traffic for one function after another is routed to new components while the old part shrinks until it can be switched off. A big-bang rewrite is the riskiest option — it delivers no value for a long time, and hidden business rules surface only after go-live.

Assessment: what you actually have

The first phase is an assessment that can be ordered on its own. It covers an inventory of modules, dependencies, databases and integrations, a code quality review, interviews with users and with the people who know the system’s history, and a search for undocumented business rules. The result is a behaviour and data risk map, a target architecture and a migration plan split into phases, with costs and sequencing.

For smaller systems, the reference is the discovery and technical specification anchor ($490–$1,500); large estates are estimated individually. The assessment is worth having even if you ultimately decide not to modernize — you will know exactly which risk you are accepting.

Typical workstreams

Framework and runtime upgrade

Moving to supported language and framework versions — for example from legacy PHP to current Laravel or Symfony, from .NET Framework to modern .NET, from AngularJS to Angular, React or Vue — together with library updates.

Interface redesign

Reworking the screens people use every day, often without touching the logic underneath. It gives users a quick win and reduces data entry errors.

API extraction

Exposing legacy functions through a modern API that a mobile app, client portal or partners can use. This is often the first step that unlocks further development.

Database migration

Moving data, for example from Access, older SQL Server or Oracle versions to PostgreSQL, with cleansing and record reconciliation. More on this under database applications.

Deployment automation and observability

Automated build and deployment (CI/CD), containers, centralised logs, metrics and alerts, so problems become visible before users report them.

How we protect system behaviour during change

• characterisation tests — before changing anything, we capture in tests how the system behaves today, including where that behaviour looks odd;
• golden datasets — the same inputs run through old and new code, with results compared;
• data reconciliation after migration — record counts, checksums, balances;
• parallel running of the old and new solution;
• feature flags and gradual traffic shifting to new components;
• a cutover and rollback plan, with a backup verified before go-live.

For high-risk changes, backups, data reconciliation, a parallel run and documented rollback evidence are mandatory — they are not options to negotiate away.

How a modernization programme runs

1. Assessment — inventory, risk map, strategy options and a recommendation.
2. First-phase specification — the chosen slice of the system, acceptance criteria, a data plan and a rollback plan.
3. Safety net — characterisation tests, monitoring and backups before the first line of code changes.
4. Phase delivery — in iterations, with regular deployments to a test environment.
5. Cutover — parallel run or gradual traffic shift, data reconciliation, the decision to switch fully.
6. Retirement of the old part and documentation updates, then the next phase.

An assessment is usually a matter of weeks; implementation time depends on the verified legacy scope. The schedule grows mainly with missing tests, poor data quality, the number of dependent integrations and limited maintenance windows in which production may be switched.

Security and personal data

Modernization is a good opportunity to remove unsupported components, take passwords out of code and config files, and introduce sign-in through your corporate directory (Active Directory, Entra ID) with multi-factor authentication. When personal data is migrated, we follow GDPR principles: testing uses anonymised data, and retention periods are tidied up so that data with no remaining legal basis is deleted.

Modernization budget

The anchor of from $4,900 excl. VAT applies to a first, clearly bounded phase — for example upgrading one module together with regression tests and automated deployment. The cost of the whole programme depends on:

• codebase size and number of modules;
• missing tests and documentation;
• the volume and quality of data to migrate;
• the number of integrations with other systems;
• acceptable downtime and the need for a parallel run;
• regulatory requirements — for high-complexity or regulated systems the reference anchor starts from $12,000.

Billing can be a fixed price for a phase defined after the assessment, or time and materials when scope is discovered along the way. Details of all anchors are on the pricing page.

What we need to start

• the source code and repository access — without code, modernization options are severely limited;
• a database copy or access to a test environment;
• key users who can show how the system is really used;
• documentation, vendor contracts and licence information;
• a decision on how much downtime the business can accept.

Once modernized, the system can move to ongoing maintenance so it does not age again. Other services are listed under custom software development. Start with a short description of your system.

Related services

Frequently asked questions