What legacy system modernisation is, and who it is for
Legacy system modernisation is the replacement or upgrading of old software a business still relies on: desktop programs, unsupported databases, and spreadsheets that became systems. Evolve does this for UK businesses of roughly 20 to 250 staff, choosing between rehost, replatform and rebuild case by case, and migrating the data so that every record can be reconciled.
The program tied to one PC
A garage runs its workshop on a Windows package licensed to a single machine in the office. One person knows the menus. The backup is a USB stick, when someone remembers. Invoices are raised in it, payments are ticked off by hand from a separate card terminal, and the month-end figures are retyped into the accounts package. Then one morning the PC does not boot.
We replaced that with a cloud workshop-management system the whole team uses from a browser and a phone: bookings, job cards, parts, invoicing, reminders and the owner's dashboards. Every historical record was migrated and reconciled, the old program was kept read-only, and the accounts package now gets its figures without a USB stick. The client is not named; the shape of the problem will be familiar to a lot of businesses.
Rehost, replatform or rebuild
There are three ways to modernise, and the cheapest is the right answer more often than agencies admit. We decide with you during discovery, after we have seen the system and the data.
Rehost
What it is: move the software as it is to a supported server or a cloud machine.
Right when: the software still does its job and only the hardware, or the single PC, is the risk.
What it fixes: access from anywhere, proper backups, no more one machine. What it does not fix: the software itself.
Replatform
What it is: keep the data and the business rules, change the database or the runtime underneath.
Right when: the software is sound but the platform is out of support, or the licence is ending.
What it fixes: the support problem and usually the speed. The screens and the process stay the same.
Rebuild
What it is: a new system built around how the work runs now, with the old data migrated into it.
Right when: the process has changed, the vendor has gone, or the rules live in one person's head.
What it fixes: everything, in phases, starting with the part that hurts most. See bespoke systems.
Data migration
The migration is the project. The software is the easy part. Old systems hold ten years of records that were entered by different people under different rules, and the new system has to make sense of all of them without losing one.
Extract
Get the data out of the old system, whether that is a supported export, a direct read of the database, or a careful scrape of a program that has no export at all.
Map
Every field in the old system mapped to its place in the new one, with the old identifiers kept so a record can always be traced back.
Reconcile
Counts, totals and spot checks compared between old and new: customers, vehicles, invoices, balances. The numbers have to match before anyone trusts the screen.
Dry runs
The migration is rehearsed on a copy, more than once, until it runs clean. The real one is a repeat of a rehearsal, not a first attempt.
The exceptions list
Records that cannot be mapped cleanly are listed, not silently dropped or guessed. You decide what happens to each of them before cut-over.
Rollback
A written path back to the old system if something surprises us after launch. Rarely used, always ready.
Running old and new in parallel
Nobody has to trust the new system on day one. For an agreed period both run side by side, and the criteria for switching off the old one are written down before the new one goes live: which reports have to match, which jobs have to have gone through end to end, who has to sign it off.
After cut-over the old system stays available read-only for as long as you want it. Where a licence is ending we plan the parallel run around that date, so the switch happens on your timetable rather than the vendor's.
Where the old systems live
The technology varies. The pattern does not: one system, one person, and a workaround everyone has stopped noticing.
Trade and workshop businesses
Desktop packages from the 2000s, licensed per machine, with the data trapped locally.
- Workshop and job management
- Stock and parts
- Invoicing with a manual accounts export
Financial and professional services
Client records and case files across systems that predate the regulation they now have to satisfy.
- Client onboarding and KYC records
- Case and matter management
- Audit trails retrofitted onto old databases
Healthcare and medical suppliers
Product, training and patient records held to standards the original system never anticipated.
- Product knowledge and documentation systems
- Ordering and inventory across regions
Anyone running on a spreadsheet
The stock list, the rota, the pipeline or the membership register that four people edit at once.
- Shared workbooks that became the system of record
- Email threads that are the real workflow
Discovery finds the rules nobody wrote down
Old systems carry business rules that exist only in habit. Before we rebuild anything, every member of staff documents how the work actually runs, so the new system encodes the business and not the bugs people learned to live with.
- 01
Listen
Everyone in scope documents their own routines, with the time and frequency attached. A census, not a sample.
- 02
Map
An explicit picture of how each workflow moves across people, systems, and decisions, drawn from what your team actually described.
- 03
Score
Every candidate opportunity scored on impact, feasibility, regulatory risk, change cost, and time to value.
- 04
Sequence
A phased roadmap that makes the order of work obvious. Quick wins first, strategic plays scheduled.
You leave with: full documentation of every process in the business, department by department, plus a prioritised opportunity register, recommended sequencing, and compliance notes. Board-ready, defensible, and yours to keep and use with anyone.
Learn how the Workflow Audit worksHow a modernisation runs
Discovery
The audit, or a scoping engagement for a single system. We sit with the people who use it, read the old database, and find out whether the data can come out.
Choose the approach and fix the price
Rehost, replatform or rebuild, and a fixed price for the first phase. Usually the first phase is the module that hurts most.
Build and rehearse the migration
Weekly demos on real migrated data, so you are checking your own records, not sample ones. Dry runs until the migration is clean.
Parallel run and cut-over
Both systems live. Cut-over when the agreed criteria are met and signed off, not before.
Handover
Repository, cloud account, database and documentation in your name. The old system kept read-only. Optional monthly support after.
What it costs
A fixed price per phase, quoted after discovery, with no day rates. What moves it:
- Undocumented business rules. The more of the system lives in one person's head, the longer discovery takes.
- Data quality. Duplicates, free-text fields and ten years of inconsistent entry all add reconciliation work.
- Integrations. The accounts package, the card terminal, the supplier feeds.
- User roles. How many different people need different screens.
- The parallel run. Longer is safer and costs more to support.
- Whether the old vendor will help. An export they provide is cheaper than one we have to engineer.
Why an AI-native studio modernises faster
What AI does in a modernisation
- Reads the old code or database schema and documents what it finds
- Drafts the field mapping and the migration scripts
- Generates test cases from historical records, so the new system is checked against real history
- Writes the reconciliation reports for the parallel run
What AI does not do
- Decide which of the old rules are still the business and which were bugs people learned to live with
- Sign off the exceptions list
- Call the cut-over
Questions people ask about modernisation
What is legacy system modernisation?
The replacement or upgrading of old software a business still relies on: desktop programs, unsupported databases, and spreadsheets that became systems. It covers three approaches, rehost, replatform and rebuild, and the choice between them is the first decision.
Rehost, replatform or rebuild: which applies to us?
Rehost if the software works and only the hardware is the risk. Replatform if the software is sound but the database or runtime is unsupported. Rebuild if the process has changed, the vendor has gone, or the rules live in one person's head. We decide this with you during discovery, not before.
Will we lose data in the migration?
Not without knowing it. Every record is reconciled against the old system: counts, totals and spot checks, with an exceptions list you sign off before cut-over. The migration is rehearsed on a copy before it runs for real.
Can we keep using the old system while the new one is built?
Yes, and you keep using it after launch too. Old and new run in parallel until agreed cut-over criteria are met, and the old system stays available read-only for as long as you want it.
Our software vendor has gone. Can you still get the data out?
Usually. If the database is readable we can extract it, and most are. If it is encrypted or proprietary we say so in the first week, before you have committed to anything.
How long does modernisation take?
A first fixed-price phase usually goes live within eight weeks of sign-off. Larger systems are replaced module by module, starting with the bottleneck, so each phase ships something you can use.
What does it cost?
A fixed price per phase, quoted after discovery. What moves it is undocumented business rules, data quality, the number of user roles, the integrations, and how long you want the parallel run to be.
Can you modernise part of a system rather than all of it?
Yes, and it is usually the better plan. Replace the part that hurts most, connect it to what remains, and take the rest in later phases if the first one earns it.
Tell us what the old system is
On a free call we will ask what it runs on, who knows how it works, and whether the data can come out. That is usually enough to say which of the three approaches fits.