Moving off an ageing Sage or VB6 system without stopping the business

Two systems come up again and again when an established SME asks us to look at something old. One is a Sage install several versions behind. The other is a bespoke application written in Visual Basic 6 by somebody who left the business years ago.

Both get described the same way, as "our system is ancient", and they are not the same problem. Separating them is the first useful thing you can do, because the answer to one is cheap and the answer to the other is a decision about the next decade.

They look alike and they are not

An old Sage is a supported product you have fallen behind on. The vendor still exists, the upgrade path is documented, and once you are current again there is somebody at the other end of a phone. What you have lost is the support and the newer features, not the software.

An old VB6 application is a bespoke system with no supplier. Nobody is publishing an upgrade, because there is one copy of it in the world and it is yours. Whatever happens next, you are the one who has to make it happen.

The first is usually a project of weeks. Businesses get into trouble by bundling the two into a single panic.

What is true about VB6

VB6 is much like Access here: the truth is less dramatic than the panic and more serious than the reassurance. Our guide to Microsoft Access end of life makes the same shape of argument.

The development environment has been out of support since 8 April 2008. If you need a change made, there is no supported tool in which to make it.

The runtime is a different matter. Microsoft's support statement for Visual Basic 6.0 says the core runtime files ship with Windows and are supported for the lifetime of the Windows version they ship in, with fixes limited to serious regressions and critical security issues. So your application will in all likelihood keep starting on Windows 11. That reassurance is real, and narrower than it sounds.

It is 32-bit only. On 64-bit Windows the VB6 runtime components are supported only inside the 32-bit compatibility layer. It works, but your line-of-business system is resting on a compatibility layer rather than on the platform itself.

The runtime is not the application. Almost no real VB6 system is only VB6. There are third-party OCX controls, a grid, a reporting tool, a printing component, a database driver, often licensed from companies that no longer trade. Microsoft supports its runtime. Nobody supports those, and they are usually what breaks first when a PC is replaced.

Nobody can change it. The actual problem, and not a technical one. Every request becomes a negotiation with a black box, so requests stop being made. More on that in what happens if your software developer disappears.

What is true about an old Sage

Sage publishes a software lifecycle policy setting out which versions still qualify for support, and support also depends on having an active subscription. At the time of writing the UK policy covers Sage 50 Accounts from v26.3 upwards. Check your actual version against Sage's page rather than against what a reseller told you several years ago.

If you are below the line, three things follow. There is no support call to make when something goes wrong at year end. Compliance changes stop arriving, which is the one that really bites, because payroll and tax reporting rules do not stay still. And integrations stop working: bank feeds, ecommerce links, and anything that expected a current version.

Then be honest about the diagnosis. For plenty of businesses the whole answer is "get current", a modest cost and a planned weekend. Nobody should talk you into replacing your accounts package when what you have is an upgrade problem.

The better question is a different one. Look at what people actually do inside Sage and split it in two: the part that is accounting, and the part that is the business working around Sage. The second pile is usually stock, jobs, quotes, scheduling, commissions or customer history, held in fields never meant for them and propped up by a spreadsheet.

That second pile is what a bespoke system takes over, and it normally sits alongside Sage rather than replacing it, with the two kept in step automatically. That is the work on our system integration page, and the same pattern as connecting Xero or QuickBooks to your other systems.

What usually forces the decision

Rarely the software itself. Almost always one of four things.

The machine it runs on. Support for Windows 10 ended on 14 October 2025, and a lot of legacy applications are pinned to one ageing PC nobody is allowed to touch. When that PC dies, the hardware sets the timetable rather than you.

A person. The one who knows which order to run things in retires, and the knowledge goes with them.

A customer or an assessor. Cyber Essentials, an insurer or a procurement questionnaire asks what is running on your network and whether it is patched. Unsupported components are hard to answer for.

A change you cannot make. A new price structure, a new service line, a customer who needs data in a format the system has never produced. The answer comes back as "the system can't do that", and the business shrinks to fit the software.

The fourth is the one to watch, because it never announces itself as a systems problem. It shows up as opportunities not taken.

What is worth keeping

People underestimate how much value is locked up in the old system. Twenty years of business rules are in there: the discount logic, the exceptions, the reasons behind the reasons. A rebuild that begins by reading what already exists starts from a far better specification than a blank page. The data matters too, often the only complete record of what the business has done, and usually extractable even when the application is not.

None of which is true of a system you have already switched off.

A sane order to do this in

1. Write down what it does. Sit with the people who use it daily and record every process, workarounds included. It is the most valuable document in the project and it costs nothing but attention.
2. Prove you can get the data out. Export it, open it somewhere else, confirm it is complete and legible. Do this before committing to anything, because data that will not come out cleanly changes both the plan and the cost.
3. Remove the cheap risks now. Back it up somewhere that is not the same server, and image the machine it runs on so a hardware failure is an inconvenience rather than an emergency.
4. Then decide, without a deadline over you. Upgrade, integrate around it, or replace it.

Steps one to three are worth doing even if you decide to leave everything alone.

What it costs and how long it takes

Most bespoke projects for SMEs land between £15k and £60k. The bands, and what moves a project between them, are on our bespoke software development page and explained in what bespoke software costs. A legacy replacement sits where it does in that range largely because of the data: how much there is, how clean it is, and how much old logic has to come across intact.

On timescales, the honest answer is in how long bespoke software takes. What reliably shortens it is phasing: replace the single most painful process first, run it alongside the old system, then take the next one. Nobody should be asked to switch a twenty-year-old system off over one weekend. The full approach is on our legacy system replacement page.

When to leave it alone

If the system is stable, used by a handful of people on one site, holds nothing sensitive, is not how you win or deliver work, and the data is backed up somewhere safe, leave it. Write the decision down and look again next year. Deciding to do nothing is respectable. Drifting into it is not.

If you would like someone to look at it with you first, the free process audit is a 60 minute session, usually on site, and you will get a straight answer at the end of it. Get in touch.