Cutover plan 4 sections Part of bespoke software
Legacy Software
Modernisation
What legacy modernisation is
This is not a normal build, and the difference is worth understanding before anyone quotes for it. On a new system you decide what it should do. Here the answer already exists. It is scattered across screens, reports and the habits of whoever has used the system longest, and most of it was never written down. The job is to find those rules before they are lost, not to invent better ones.
Dev Moves does not present this as a past client project. It is the cutover method we would use.
Starting with a sheet or an Access file? That route sits on the bespoke databases page.
If the system still works and only needs keeping current, that is website support and maintenance rather than a rebuild.
Which systems count as legacy
Legacy does not mean old. It means the software still runs the business, but changing it has become risky, slow or impossible. Age is only a clue.
In UK small businesses it usually looks like one of a handful of things. A Microsoft Access database on one machine. A Visual Basic or classic ASP application from the 2000s. A PHP site on a version that no longer gets security fixes. A server in a cupboard running an unsupported Windows Server. Or software whose supplier has stopped answering the phone.
The clearest test is not technical. If nobody will change the system because they are afraid of what will break, it is legacy, whatever year it was written.
The six ways to modernise
There is more than one way out, and they are not equally expensive. Most guides list six. Here they are in plain English, cheapest first.
- Rehost
- Move the same software onto newer hardware or a cloud server. Nothing is rewritten. Buys time, fixes nothing.
- Replatform
- Move it and update what it runs on, such as the database or language version. Small changes only.
- Refactor
- Keep the same behaviour but tidy the code so it can be changed safely again.
- Rearchitect
- Split one large system into parts that can be replaced separately. Usually how a phased switch becomes possible.
- Rebuild
- Write it again around what the business does now, keeping the data.
- Replace
- Buy a product that already does the job and move the data into it.
Rehosting a system nobody can change leaves you with the same problem on a newer server. Replacing works when a product genuinely fits, and we will say so if one does. Most jobs land on rearchitect or rebuild, because the rules that matter are the ones buried in the old system.
What actually goes wrong
These are common failure modes across system migrations. They are risks to plan for, not stories about a Dev Moves client.
The data is messier than anyone thought
Names, dates and codes use several formats. Old records may also be missing key fields.
We profile a copy first. Bad patterns are counted, mapped and agreed before the live move.
The old system has rules nobody can explain
A report may change a value without showing why. Staff may also fix edge cases by hand.
We trace inputs to outputs. Each rule gets written down, tested and signed off by its owner.
The switchover weekend overruns
One large cutover leaves every fault to the final change. There is no room to learn safely.
We rehearse the move and split it into smaller releases. Each release has a clear way back.
The person who understood it has left
The business knows what comes out, but not what the code does between one step and the next.
We use the screens, records and reports as evidence. Staff then check each rule against real work.
The old system stays understood and usable while its replacement is proved.
How the cutover runs, and what it costs
The business keeps working through all four stages. What staff do during each one is part of the plan.
-
03.1
Read the old system
Your team keeps using it while we map the screens, reports, users and links. Staff show the normal route and the awkward exceptions. The result is a written map of what must survive.
-
03.2
Move the data and check it
A copy moves first. Staff search known records and compare totals with the old system. Faults go back into the map. Live data stays where it is until the checks pass.
-
03.3
Run both side by side, then switch in pieces
A small group does real work in the new system while the wider team carries on as normal. Outputs from both systems are compared, and the old route stays available. Then one team, function or record type moves across at a time. The business always knows which system owns each task, and the next piece moves only once the last one is stable.
-
03.4
Retire the old one
The new system becomes the main record. The old one turns read-only and stays available for checks. It is retired only after the business no longer needs it for daily work.
Replacing old software, and why it is rarely a clean sweep
The old system is still running the business. That is the awkward fact any replacement has to respect.
| What to weigh | The case for modernising | What makes it hard |
|---|---|---|
| Finding help | Current tools mean a normal developer can pick the work up. | The person who knows the old system may be the only one who does. |
| Security | Software still receiving updates can actually be patched. | Old systems often cannot be touched without something else falling over. |
| Changing it | A change becomes a week rather than a negotiation. | Every rule in the old system exists for a reason nobody wrote down. |
| The rebuild | Rebuilding in pieces lets each part prove itself before the next. | Pieces need somewhere to meet, so the old and new run side by side for a while. |
| The data | Years of history can usually come across intact. | Old data is messy, and cleaning it is most of the work rather than a step. |
| Doing nothing | Sometimes the honest answer is that it still works and can wait. | That answer has a shelf life, and it is shorter than people hope. |
What you keep
Modernisation should not throw away the parts the business trusts. Useful history moves with the live records. Rules that once sat in code or memory become plain documents.
The new system is not another locked box. Your data, agreed project code and any platform licence stay documented.
- The data, including useful history
- The business rules, written down
- The agreed project code or platform licence
- No licence on the old system
What drives the cost
The new screens are only one part of the scope. The data, hidden rules and safe cutover usually move the number most.
-
05.1
How much data there is, and how messy it is
Old formats, gaps and copied records need choices before they can move safely.
-
05.2
How many rules were never written down
Each hidden check or exception has to be found, explained and tested.
-
05.3
How many people use the system
More roles bring more screens, permissions, checks and ways to phase the move.
-
05.4
Whether it can stop
A weekend cutover is simpler. Continuous use needs parallel running and smaller hand-offs.
Common questions
What is legacy software modernisation?
Do we have to replace everything at once?
What happens to our old data?
Can the business keep running during the change?
What if nobody here understands the old system any more?
What are the 6 Rs of legacy modernisation?
Is it cheaper to modernise or to start again?
What normally replaces an old system: bespoke CRM system, bespoke ERP system and API integration services.
Start with the system nobody dares touch
Show us what it runs, who uses it and what cannot stop. We will map the cutover before anybody talks about new screens.
- Pontefract, West Yorkshire
- Building for businesses across the UK
- Reply within 1 working day