Migration 5: Still Running on Access, FoxPro or an Old Bespoke System? You’re Not Alone
You Are in Good Company
If you are still running a legacy database system, it can feel as though you are the last organisation on earth still doing it. You are not. Many charities, NGOs, professional bodies, and voluntary organisations across Ireland and the UK are in exactly the same position.
These systems were well built for their time. They did the job, and because they did, nobody replaced them. Now the world has moved on, and they have not.
Here is a plain-language guide to the systems we most often encounter and what moving away from each one usually entails.
Microsoft Access
Microsoft Access was the main choice for small to medium database needs throughout the 1990s and 2000s. It came with Microsoft Office, was relatively easy to use, and could be customised without a full development team.
The problem is that Access was built for small datasets on a single machine. It struggles with larger volumes of data, does not handle multiple simultaneous users particularly well, and the underlying database engine has not seen meaningful improvement in years. Microsoft still sells it, but it is no longer the product it once was.
Data stored in Access is often held in a proprietary format that is not always straightforward to export. Relationships between tables may have degraded over time. Reports may have been created by someone who is no longer around to explain how they work.
Migrating from Access usually involves extracting the data, rebuilding the table structure in a modern database such as MySQL, and recreating the application logic in a modern web framework. We have done this many times and know where the problems usually lie.
FoxPro and Visual FoxPro
FoxPro was a powerful database system in its day: fast, capable, and widely used in professional and commercial settings throughout the 1980s and 1990s. Microsoft later acquired it and released Visual FoxPro, which kept it going into the 2000s.
Microsoft discontinued FoxPro in 2007 and Visual FoxPro in 2015. There are no security updates, no patches, and no official support. The remaining developer community is small and getting smaller.
From a modern point of view, the most serious issue with FoxPro is that it stores data in plain text. There is no native encryption. Every record – names, addresses, financial data, and sensitive personal information – can be read by anyone with access to the file. That creates a clear GDPR compliance risk.
Accessing a FoxPro database over a modern network often requires workarounds. In some cases, we have seen that has included running a Windows 98 virtual machine because it was the only way to keep the network connection working. That is not a sustainable position.
dBase
dBase was one of the earliest personal computer database systems and was widely used from the late 1970s through to the 1990s. It introduced the `.DBF` file format, which still turns up in some organisations today.
Like FoxPro, dBase stores data in plain text `.DBF` files. There is no encryption, no meaningful access control beyond basic password protection, and no ongoing development or support. Organisations still using dBase are often unaware of how exposed their data may be.
Sybase
Sybase was a serious enterprise database system used by larger organisations and institutions from the 1980s onwards. SAP acquired Sybase in 2010, and many older installations are now long out of support.
Organisations still running legacy Sybase databases often have more complex data structures and larger user bases, which makes migration a more involved project. But it is still very achievable, and we can assess what is involved.
Old Bespoke Systems
Many organisations have a system that was built specifically for them by a developer, a company, or a particularly capable volunteer at some point in the past. These systems were often well designed for their time and matched the organisation’s needs closely.
The problem is that the person who built them is often no longer available. There may be no documentation, no readable source code, and no clear way to understand how the system works. The organisation is left depending on a black box.
Migrating from a bespoke system starts with understanding what it actually does. We spend time with the people who use it every day, learning the logic, the workflows, and the edge cases only they know about. That takes time, but it is essential if the replacement is going to work properly.
What All These Systems Have in Common
Whatever the technology, the pattern is usually the same. A system that was fit for purpose when it was built has been kept going through habit, workarounds, and institutional knowledge rather than proper support, and the risk has quietly grown over time.
The answer is usually the same too: a modern, secure, cloud hosted web application that does everything the old system did, with proper backups, proper encryption, clearer GDPR compliance, and a developer you can actually call when something needs to change.
Ready to Have a Conversation?
If you have read this series and recognised your organisation in it, the next step is simple. Get in touch. We will have a chat, ask a few questions, and give you an honest view of what is involved. No charge. No obligation.
Back to: Legacy Database Migration Series
