Modernizing FoxPro, VB6 and Access systems
Software written by someone who left years ago, running on a PC nobody is allowed to switch off.
These systems usually encode two decades of business rules that exist nowhere else. The migration risk is not the code — it is losing the rules.
Typical timeline: Discovery in 2–3 weeks, first module in 10–14 weeks
Discovery first, then module by module
These are the signs this is worth doing
If several of these are true, this is usually where the fastest return sits.
These systems are more common than anyone admits. A Visual FoxPro application handling order processing. An Access database that is the only record of customer pricing. A VB6 program driving a machine on the shop floor. They were built cheaply, they worked, and they have quietly become the most important software in the business.
The urgency is usually external: the PC is failing, Windows will not run it any more, the office is moving, or someone finally asked what happens if it stops. By then the original developer is long gone.
The real risk is not rewriting the code. Modern tooling makes that the easy part. The risk is that twenty years of business rules — pricing exceptions, approval thresholds, that one customer who is invoiced differently — exist only inside it, and nobody remembers they are there until they are missing.
How we approach it
Recover the rules, not just the data
We read the source where it exists and observe behaviour where it does not, then write the rules down in business language and have your team confirm them. This document outlives the migration and is often worth the engagement on its own.
Get the data out and readable
DBF, MDB and old SQL Server formats are all extractable. We pull the data into something modern and queryable early, so even before the application is replaced you are no longer one hard-disk failure from a crisis.
Rebuild module by module
The old system keeps running while modules move across one at a time, sharing data. There is no single switch-off date on which everything depends.
Keep a read-only original
Once migrated, the legacy application is kept accessible read-only for an agreed period, usually on a virtual machine, so anything questioned later can be checked against the original.
The first two weeks matter most
We start with discovery rather than code, because the answer to 'how big is this' is genuinely unknown at the outset — including to you. What comes out of it is a written inventory: the screens people actually use, the reports that matter, the integrations nobody mentioned, and the rules recovered so far.
That inventory routinely halves the scope. A system with sixty screens usually has twelve that anyone has opened this year. The rest were built for a process that ended, a customer who left, or a report that was replaced. Rebuilding all sixty because they exist is the most common way this work is over-priced.
You can stop after discovery with something useful in hand, and some businesses do — they learn the system is smaller than feared, and buy a few more years with a virtual machine and a backup regime. We will say so if that is the honest answer.
What you get from discovery alone
- A written inventory of screens, reports, and integrations, with what is genuinely in use.
- Recovered business rules in plain language, confirmed by the people who rely on them.
- The data extracted into a modern, queryable database.
- A risk assessment: what actually happens if the machine dies on Monday.
- A phased, costed plan — or an honest recommendation to defer.
The expensive part of a legacy migration is never the code. It is the rule nobody remembered until an invoice went out wrong.
We would rather tell you now than three weeks into a project. This work is usually the wrong call if any of the following describes you.
- Systems that are genuinely stable, isolated, and low-risk. If it runs a single non-critical report, a virtual machine and a backup are the proportionate answer.
- Businesses planning to buy a packaged product that covers the same ground — migrate to the package, do not rebuild the legacy system first.
- Anyone who wants a like-for-like rebuild. Copying a twenty-year-old interface faithfully is how you get software that is obsolete on delivery.
The systems involved
We integrate rather than replace wherever it makes sense. These are the systems this work most commonly touches.
Legacy desktop apps — questions we get asked
We do not have the source code. Is it hopeless?
No, and it is a common situation. Data can be extracted from DBF, MDB, and old SQL Server files regardless. Rules are recovered by observing behaviour systematically and confirming with the people who use it — slower than reading source, but reliable.
Can we keep the old system as a backup?
Yes, and we recommend it. It is kept read-only, usually on a virtual machine, for an agreed period after cutover so anything disputed can be checked against the original.
Will this cost more than it is worth?
Sometimes, and discovery is designed to establish that in two to three weeks rather than six months. If the honest answer is that a virtual machine and a proper backup buy you three more years, we will tell you.
The services this work sits inside
Where this comes up most
The sectors where we most often do this work, and where the payback is usually clearest.
Others worth reading
Replacing a spreadsheet that has become a system
When a workbook has become the system of record for a real process, the failure modes stop being inconvenient and start being expensive. Turning it into an application is usually a short project.
Read itMigrationMoving an on-premise database to the cloud
Moving a production database is routine work done carefully. The difficulty is almost never the copy — it is the applications pointing at it and the cutover window.
Read itThinking about legacy desktop apps?
Start with a short conversation. We will tell you honestly whether this is the right place to begin, or whether something else pays back faster.