Most legacy systems are not replaced because they suddenly stop working. They are replaced because, year by year, they become harder to change, harder to secure and harder to find anyone who understands them. By the time a business decides to act, the system is often holding up growth, and the pressure to “just get it done” leads to rushed projects that go over budget or lose data.
This legacy system modernisation checklist is designed to slow that moment down in the right places. It takes you from “we think our old system is a problem” to a clear, low-risk plan, in the order we work through it with clients. You can use it on your own, with your IT supplier, or as a brief for any developer you are thinking of hiring.
Print it, copy it into a shared document, or work through it in a meeting with the people who use the system every day. They will know things nobody has written down.
Before you start: what counts as a legacy system?
“Legacy” does not just mean old. A system is legacy when the cost and risk of keeping it are growing faster than the value it gives you. Common examples in UK small and mid-sized businesses include:
- a Microsoft Access or FileMaker database built by a former employee;
- a bespoke web application written ten or more years ago, on a framework or language version that no longer receives security updates;
- a heavily customised off-the-shelf package whose supplier has stopped supporting your version;
- a spreadsheet that has grown into a system, with macros, lookups and a single person who knows how it works;
- software that only runs on one particular PC or server in the office.
If any of those sound familiar, work through the stages below in order. Each stage ends with a short list of questions to answer before you move on.
Stage 1: Take an honest inventory
You cannot plan a modernisation until you know exactly what you have. This stage is about facts, not opinions.
- Name every system involved. Include the main application and everything around it: reports, exports, scheduled jobs, linked spreadsheets and any “temporary” workarounds that became permanent.
- Record where it runs. A server in the office, a hosting company, a cloud platform or one person’s laptop. Note the operating system and its version.
- Find the source code. For bespoke software, confirm who holds the code, whether you own it, and whether it is in version control. If nobody can find it, that is your first and most urgent finding.
- List the people who understand it. Developers, suppliers and the internal “go-to” person. If that list has one name on it, write that down too.
- Check contracts and licences. Renewal dates, notice periods and any clauses about data export. These often decide your timeline more than the technology does.
Before moving on, you should be able to answer: What exactly would stop working if this system disappeared tomorrow, and who would notice first?
Stage 2: Assess the business risk
Not every old system needs replacing. Some just need to be made safer. Score each of these risks as low, medium or high:
- Security. Is the operating system, language or framework still supported with security updates? Windows 10, for example, reached the end of standard support in October 2025, so businesses still running it rely on Microsoft’s paid Extended Security Updates. Unsupported software is a common way into a business network.
- Key-person dependency. What happens if the one person who understands the system leaves, retires or is ill for a month?
- Hardware and hosting. Is it running on ageing hardware with no tested backup or replacement plan?
- Data protection. Does it hold personal data? Can you meet a subject access request, correct a record or delete someone’s data on request? The Information Commissioner’s Office expects you to be able to.
- Business fit. Does the system still match how the business works, or have staff built workarounds around it?
- Cost of standing still. Add up licence fees, support calls, manual re-keying and the opportunities you cannot take because the system cannot do something.
Two or more “high” scores usually mean modernisation should be on this year’s plan. One “high” on security alone may justify immediate action, even if the full project comes later.
Before moving on, you should be able to answer: Which risks are urgent, and which could wait twelve months without real harm?
Stage 3: Map how the system is really used
Documentation, where it exists, describes how a system was designed to be used. What matters is how it is used today. Spend time with the people who use it.
- Walk through a normal day with each type of user: office, field, finance and management. Note every screen they use and every step they take outside the system.
- Capture the unwritten rules. “We never delete a customer, we put a Z in front of their name.” Rules like these are easily lost in a rebuild and cause real problems after go-live.
- List every report and who reads it. Some will be essential, and some nobody has opened in years.
- Note the pain points. Slow screens, double entry, workarounds and anything people dread doing. These become your priorities later.
Before moving on, you should be able to answer: If we built a replacement that did exactly what the documentation says, what would staff immediately complain was missing?
Stage 4: Understand the data
In most modernisation projects, the data is harder than the software. Our data migration checklist covers the move itself in detail; at this stage you are simply finding out what you are dealing with.
- Where does the data live? One database, several databases, spreadsheets, file shares and email attachments all count.
- How much is there, and how far back does it go? Decide how much history the business genuinely needs, and how much you are legally required to keep.
- How clean is it? Look for duplicate customers, blank required fields, free-text fields used for structured information and codes nobody remembers the meaning of.
- Who owns each type of data? Someone in the business, not IT, should be able to say what “correct” looks like for customers, jobs, products and invoices.
Before moving on, you should be able to answer: Could we produce a clean list of active customers, with no duplicates, from the current system today?
Stage 5: List every integration
Legacy systems rarely stand alone. Missing a single connection is one of the most common reasons for a painful go-live.
- Accounting software, such as Xero, QuickBooks or Sage.
- Payment providers, card machines and direct debit services.
- Your website, online forms and any customer-facing portal.
- Email and text message sending.
- Supplier, courier or trade portals, and any file transfers to them.
- Reporting tools and spreadsheets that pull data out.
For each one, note which way data flows, how often, and what happens if it fails. If you are planning new connections as part of the project, our guide to connecting Xero or QuickBooks to your website and CRM explains the options.
Before moving on, you should be able to answer: If we switched the old system off for an hour, which other systems would break?
Stage 6: Choose the right route
With the facts gathered, you can make a sensible decision. There are four realistic options, and the right one depends on your scores from Stage 2 and the fit from Stage 3. We compare the main three in more detail in Rebuild, Refactor or Replace?
- Stabilise. Leave the system in place but reduce the risk: move it to supported hosting, add tested backups, document it and patch what can be patched. Right when the system still fits and the main risks are infrastructure.
- Refactor. Improve the existing code and upgrade its foundations without changing what it does. Right when the system fits the business but the technology is ageing.
- Rebuild. Create a new system that does the same job on modern technology, usually with improvements. Right when the process is unique to you and the old system is too tangled to change safely.
- Replace. Move to an off-the-shelf product. Right when your process is fairly standard and a well-supported product covers most of it.
Mixed answers are common. A business might replace its accounting with a mainstream package, rebuild its job management system, and connect the two.
Before moving on, you should be able to answer: Why is this route better than the other three, in terms the managing director would accept?
Stage 7: Plan in slices, not a big bang
The riskiest modernisation plan is the one with a single switch-over weekend. A safer approach replaces the old system a piece at a time, so each step is small enough to test properly and easy to roll back.
- Start with the most painful part, not the easiest. Early wins that matter to staff build trust in the new system.
- Keep the old and new systems in step during the transition, with clear rules about which one holds the “master” copy of each type of data.
- Define “done” for each slice: the users who will test it, the data that must match, and the date the old feature is switched off.
- Budget for contingency. Legacy systems hide surprises. A contingency of 15 to 20 percent of the build budget is a sensible starting point.
If you are weighing up the budget itself, our custom software cost guide explains what drives the price of a rebuild and the running costs to plan for.
Before moving on, you should be able to answer: What is the first slice, who will test it, and how will we know it worked?
Stage 8: Test with real people and real data
- Run a trial migration into a test copy of the new system, then ask users to check records they know well.
- Test the unwritten rules captured in Stage 3, one by one.
- Test every integration from Stage 5 end to end, including what happens when one fails.
- Run in parallel where the risk justifies it: process real work in both systems for a short period and compare the results.
- Check reports produce the same totals as the old system, or that you understand exactly why they differ.
Stage 9: Cut over, support and switch off
- Pick a quiet period for each cut-over, away from month end, year end and your busiest season.
- Freeze changes in the old system for that part of the business once the final migration starts.
- Have support on hand for the first days, with a simple way for staff to report problems.
- Keep a read-only copy of the old system and its data for an agreed period, so historic records can still be checked.
- Decommission properly. Securely wipe old servers and drives, cancel licences and hosting, and update your records of where personal data is held.
Stage 10: Avoid creating the next legacy system
A modern system can become legacy just as quickly if it is not looked after. Before the project closes, agree:
- who owns the source code, and where it is stored;
- how security updates will be applied and how often;
- where the documentation lives, and who keeps it up to date;
- how backups are tested, ideally following the 3-2-1 backup rule;
- a yearly review of whether the system still fits the business.
Quick self-assessment: how urgent is your modernisation?
Count how many of these statements are true for your main business system:
- It runs on an operating system, language or framework that no longer receives security updates.
- Only one person really understands how it works.
- Staff re-key the same information into it and at least one other system.
- We could not easily give a customer a copy of all the data we hold about them.
- We have not tested restoring it from a backup in the last twelve months.
- It cannot be used securely away from the office.
- We have turned down work, or a new way of working, because it could not cope.
0 to 1: keep an eye on it and review yearly. 2 to 3: start Stages 1 to 5 this quarter. 4 or more: treat modernisation as a priority, and address any security point straight away.
Legacy system modernisation: common questions
How long does a legacy modernisation project take?
The assessment in Stages 1 to 6 usually takes days or a few weeks. Delivery depends on the route: stabilising can be a matter of weeks, while rebuilding a core system in slices often runs over several months, with each slice going live along the way rather than everything at the end.
Can we keep using the old system while the new one is built?
Yes, and in most cases you should. Replacing the system a piece at a time means the business keeps running throughout, and each part is only switched off once its replacement has proved itself.
We have lost the source code. Can the system still be modernised?
Usually, yes. A rebuild can be based on how the system behaves, its database and the knowledge of the people who use it. It makes Stage 3 and Stage 4 even more important, because the code cannot be used as a reference.
Is it cheaper to buy an off-the-shelf product?
Sometimes. Off-the-shelf products are cheaper to start with, but compare the total cost over five years, including subscriptions, the workarounds you will still need and the cost of moving your data. If most of your process is standard, a product plus a few integrations is often the best value.
What should we prepare before speaking to a developer?
The answers from Stages 1 to 5 are ideal: the inventory, your risk scores, a list of pain points, a rough picture of the data and every integration. Even partial answers will make any conversation, and any quote, far more accurate.
The bottom line
Successful legacy modernisation is rarely about technology choices. It is about understanding what you have, being honest about the risks, and replacing the old system in steps small enough to test properly. Do that, and most of the drama goes out of the project.
Our legacy system modernisation service starts with exactly this kind of assessment, and sometimes the right answer is simply to make the current system safer. If you would like a second opinion on yours, tell us what you are running or call us on 01482 212499.
