Parallel running
The new module runs alongside the old one, and we compare the results before it takes over production traffic.
Custom software · Modernisation
Legacy system modernisation
Legacy system modernisation means replacing or rebuilding a system your business depends on but which can no longer be developed safely. We match the strategy to the risk - gradual replacement of modules, refactoring or a rewrite - migrate the data with completeness checks and make sure the business keeps running without interruption throughout.
01When
When legacy system modernisation becomes necessary
A legacy system is software that still supports important business processes but is expensive, slow or risky to develop - because the technology is no longer supported, there is nobody left who knows it, or every change breaks something somewhere else.
Age alone is not a reason to modernise. A system that runs stably, is secure and does not hold the company back can keep running for a long time yet. We propose modernisation when the cost and risk of leaving the system as it is start to outweigh the cost of change.
Warning signs worth taking seriously:
- no security updates - the platform, framework or database no longer receives patches,
- only one person knows the system - and their holiday is an operational risk,
- every change takes months and requires manual testing of the whole system,
- no integration - the system has no API, and new sales and customer service channels are left waiting,
- regulatory requirements - an audit identifies gaps that cannot be closed with the old technology.
02Strategies
Modernisation strategies: from refactoring to a rewrite
We choose the strategy for each part of the system separately - within a single project, some modules can be refactored while others are replaced.
| Strategy | What it involves | When | Risk |
|---|---|---|---|
| Refactoring | Gradually improving the structure of the code without changing its behaviour, with tests that guard against regression | The technology is supported, but the code is hard to develop | Low |
| Replatforming | Upgrading the framework, database or runtime environment, e.g. moving to the cloud in an EU region | The logic is sound, but the platform is losing support | Medium |
| Gradual replacement (strangler fig) | New modules take over functions one by one, and the old system is switched off piece by piece | A large, business-critical system that cannot be stopped | Medium, spread over time |
| Rewrite from scratch | A new system built alongside the old one, followed by a one-off switchover | A small system, or the old one cannot be wrapped | High |
The strangler fig pattern needs a point where traffic can be switched - a routing layer, an API or an integration. If the old system has no such point, we start by building one, which in itself often unblocks further development. We describe this in more detail on our system integration page.
03Risk
Legacy system migration without downtime
Gradual switchover
First a pilot group, a branch or one type of operation - then the next ones, once the indicators are within normal ranges.
Rollback plan
For every switchover, we know how to return to the previous state and how long it takes - and we test this before go-live.
Modernisation is also a change for people: users learn a new system, and the IT team takes on a new technology. That is why we agree switchover dates with the process owners, not just with IT, and avoid peak periods - year-end close, the high season, stocktaking.
04Data
Data migration with completeness checks
-
Profiling
What is really in the data: gaps, duplicates, inconsistent reference lists, data kept beyond its retention period.
-
Mapping
Rules for moving each field to the new model, agreed with the data owners.
-
Cleansing
Correcting and standardising the data - in the old system or as part of the migration process.
-
Trial migrations
Repeatable runs on a copy of the data, with timings and a list of errors.
-
Reconciliation
Record counts, checksums and samples checked by users before the final migration.
Migration is also a good opportunity to get personal data in order: data the company no longer needs to keep should not end up in the new system. We agree the retention rules with your data protection officer or legal team before we start the trial migration.
05Security
Improving security as part of modernisation
We begin modernisation with an audit of the old system: its code, dependencies, configuration and permissions. As a team that also carries out source code reviews, we usually find vulnerabilities that need to be secured straight away - without waiting for the new system to take over the function in question.
The most common problems in old systems are libraries with known vulnerabilities, passwords and keys hard-coded in the source, permissions checked only in the interface and no security event log.
New modules are built within our development lifecycle, with security at every stage: a threat model, code review, dependency analysis in the CI/CD pipeline and a penetration test before traffic is switched over. We describe this lifecycle on our secure by design page.
As a result, modernisation also reduces risk for security teams and auditors - instead of adding yet another layer of exceptions to the old system.
06Process
How we run a modernisation project
-
Current-state audit
Code, architecture, data, integrations, dependencies and security - plus interviews with users.
-
Plan
A strategy for each part of the system, the sequence, risks and milestones.
-
Pilot
The first module or area moved into production - testing the assumptions on real traffic.
-
Further stages
The next modules according to plan, with parallel running and a rollback plan.
-
Decommissioning
Archiving the data in line with retention rules and switching off the old system.
Frequently asked questions
Should we rewrite the system from scratch or modernise it gradually?
A rewrite from scratch is tempting because it offers a clean slate, but it is the riskiest option - for a long time the company pays for two systems, and the new one has to recreate the knowledge embedded in the old one, which is often documented nowhere. That is why in most cases we recommend replacing modules gradually (the strangler fig pattern), and a complete rewrite only for small systems or when the old system cannot be wrapped.
Will the system keep working during modernisation?
Yes - that is a basic requirement. We run new modules alongside the old ones, switch traffic over gradually and have a rollback plan for every switchover. The riskiest operations, such as data migration, are scheduled in agreed windows and rehearsed in advance on a copy of the data.
Nobody knows the old system's code any more. Is that a problem?
It is a common situation and usually the main reason for modernisation. We start by reviewing the code, database and integrations and talking to users - we reconstruct the business rules and document them before we change anything. The tests we add to the old system protect against unintended changes to its behaviour.
How do you migrate data?
We profile and cleanse the data, map it to the new model, run trial migrations and compare the results - record counts, checksums, samples checked by users. Only after successful trials do we plan the final migration, together with a rollback plan.
Will you check the security of the old system as well?
Yes - a security review is part of the initial audit. Old systems usually have outdated dependencies and permission flaws that need to be secured even before the modernisation is complete. We offer the same scope as a separate service: source code review.
Sources
Related services
Custom software · Integration
System integration
System integration services: ERP, CRM, MES and WMS connected via APIs, queues or ETL, with monitoring and security based on the OWASP API Security Top 10.
Penetration testing · White-box
Source code review (white-box)
Secure code review and white-box testing: authorisation logic, secrets, cryptography and dependencies with CVEs. Manual review, SAST and SCA, ready-made fixes.
Custom software · Secure by design
Secure by design
Secure by design in practice: threat modelling, OWASP ASVS requirements, code review, SAST and SCA in CI/CD, pre-release pentests and vulnerability management.