If you have several old internal systems doing overlapping jobs, you consolidate them by choosing one to keep, moving the others’ data and users onto it, and then switching the others off completely. The saving comes only at that last step, when licences, servers, support contracts and the effort of keeping data in step all stop. This guide is for an IT manager at a medium or large organisation who has inherited systems like these, and for the operations or finance manager who pays for them.
The work falls into six stages. Most of the risk sits in the first two and the last one, not in the data move.
1. Map what each system does and who uses it
Start with a plain inventory, one row per system:
- what it is for, in the words of the people who use it;
- which teams use it, how many people, and how often;
- the data it holds and where else that data is typed in or copied to;
- the processes it supports, including the ones that run once a month or once a year;
- every report, export and spreadsheet that depends on it;
- every other system it sends data to or takes data from;
- what it costs to run: licences, hosting, support contracts and staff time;
- who can change it, and whether the supplier or developer is still around.
Do not rely on the documentation. Talk to the people who use each system, and watch them use it if you can. The jobs that matter most are often the ones nobody wrote down: a weekly export a finance assistant pastes into a spreadsheet, or a field reused years ago for something it was never meant for.
2. Find the overlap
Put the three inventories side by side and mark where they cover the same ground. Look at three things.
Data. The same customers, suppliers, products, staff or assets held in more than one place. Note which copy people trust and why. The record that is “always right” usually tells you where the real work happens.
Processes. The same job done in two systems by different teams, or one job split across two systems with someone re-keying between them.
Reports. Figures produced from more than one system that are supposed to agree. Where they do not, find out why before you merge anything, because the difference is often a business rule that one system applies and the other does not.
What is left after the overlap is just as important: the jobs only one system does. Each needs a home after consolidation, or a decision that the business no longer needs it.
3. Choose the system to keep
The newest system is not automatically the right one to keep. Score each candidate against the same questions:
- Fit. How much of the combined work does it already do, and how much would have to be added?
- Supportability. Is it on supported software? Can you get it changed, by your own staff or a supplier, at a known cost? A system that only one departed developer understood is a weak choice however good it looks.
- Data quality. Which system holds the most complete and accurate records?
- Cost. The running cost after consolidation, including any extra licences for the users who move across, not just the cost today.
- Integration. Which system is easiest to connect to the rest of your estate, such as your finance system or Microsoft 365?
Sometimes none of the three is worth keeping, and the honest answer is a replacement, either an off-the-shelf product or new software. Our guide on when to keep, modernise or replace a legacy system covers that decision, and the ten-question check gives a first view.
Write the decision down with the reasons. People who lose their system will ask why.
4. Move the data safely
Map it. For every field in each system being retired, decide where it goes in the system you are keeping, or that it is not needed. Codes and lists (statuses, categories, departments) rarely match and need a conversion table agreed with the people who use them.
Clean it. Remove duplicates, merge records that describe the same thing, and fix obvious errors before the move, not after. Decide who has the final say when two systems disagree about the same customer or asset.
Run trials. Load a full copy of the data into a test copy of the system you are keeping. Check record counts, totals and a sample of individual records against the originals, and ask users to run their usual tasks and reports. Repeat until a trial run produces no surprises, and time it: that tells you how long the real move takes.
Plan the cut-over. Choose a quiet period, away from month-end and year-end. Freeze changes in the old systems, run the final move, check it, and only then open the system you are keeping to the users who are moving.
Keep a way back. Leave the retired systems running, read-only, for an agreed period. Agree beforehand what would make you roll back, who decides, and the point after which problems are fixed in the new arrangement instead.
You can move one system at a time: two smaller moves are often safer than one large weekend.
5. Keep integrations working
Every connection found in step 1 needs a new source or destination: interfaces to the finance system, scheduled imports, shared folders, emailed reports and links from other applications. Some will be repointed, some rebuilt, and some will no longer be needed because the data now lives in one place. Test each one in the trial runs. If the system you keep was never designed to connect to others, see when your systems do not talk to each other and what system integration involves.
6. Retire the rest properly
A system that is no longer used but still switched on saves nothing. To retire one:
- Archive the data. Export what you have to keep in a format you can read without the old software, and record where it is and who can get to it. Check retention periods with your finance and data protection leads. HMRC, for example, expects companies to keep financial records for six years, and UK GDPR says personal data should not be kept for longer than it is needed.
- End the licences and contracts. Check notice periods and renewal dates early. A missed renewal date can mean paying for another year.
- Shut down the servers and databases, including test copies and backups that are no longer needed.
- Remove access. Delete user accounts, service accounts, firewall rules and stored passwords that belonged to the old system.
- Update the records. Your asset register, support contacts and any documentation that still names the old system.
Common mistakes
- Choosing the system to keep before mapping what the others do, then finding a job it cannot handle.
- Treating it as an IT project only, so the people who use the systems first see the change on cut-over day.
- Moving data without cleaning it, so duplicates and errors arrive in the system you are keeping.
- Missing a monthly or yearly process because the trial runs did not include one.
- Leaving the old systems running “just in case” with no end date, so the costs never stop.
Where an outside assessment helps
You can do most of the mapping yourself. An outside view is worth having when nobody can say exactly what one of the systems does, when the original developer or supplier has gone, or when you need an independent comparison to settle a disagreement between departments. Our fixed-price code audit reports on a system’s condition, risks and options, and can be used on each candidate before you choose. If the systems you keep need changing to take on the extra work, that is legacy software modernisation.
A practical first step
Before any decision, build the inventory in step 1 as a single spreadsheet, one row per system and one column per question, and show it to the managers of the teams involved. It costs a few days of someone’s time, and it usually makes the choice of which system to keep much clearer.