FoxPro migration

Out of support for over a decade. Microsoft ended extended support for Visual FoxPro 9 in January 2015 and there was never a version 10. It's a 32-bit product, so on Windows 11 it runs through the compatibility layer, and its ODBC and OLE DB drivers are 32-bit only, which is why a modern 64-bit application can't read a FoxPro database directly.

And yet plenty of businesses run on it every day, because the systems were built well by people who knew the business, and DBF files don't stop working. The risk isn't that it fails tomorrow. It's that nothing around it can be changed, nothing new can talk to it, and the person who understands it is retiring.

A data-centric system, which is the FoxPro way. Tables in DBF files with their indexes alongside, memo fields holding notes and documents, programs and forms that do the work close to the data, and a set of reports the business has relied on for years.

The data model is usually clear, because FoxPro developers thought in tables. The rules are in the program files and the form events, readable but spread out. Code pages and date handling need care. And there's often a second FoxPro system somewhere that nobody mentioned.

Contain it. Make sure the runtime is installed and working on a supported machine, the DBF files are backed up and the backup restores, and the build is documented. This is the first stage whatever follows, and for a small system with a few users it can hold for a while.

Move the data, keep the front end. DBF tables move to SQL Server, reconciled, and the FoxPro application is pointed at SQL Server through its remote data features. The 32-bit driver problem goes away for everything else: modern applications, reporting tools and integrations can now read the data. The FoxPro screens carry on. This is often the biggest single improvement for the least work.

Rebuild alongside. With the data on SQL Server, new processes are built on the web or on .NET one at a time, sharing the database, while FoxPro keeps running everything that hasn't moved. Each process switches when it has proven itself, and FoxPro is retired when the last one has.

Replace with a package. Sometimes the right answer, when an off-the-shelf product now does what the FoxPro system was built to do. The data still has to move, and the assessment says whether the fit is real.

The assessment reads the tables and the programs and prices each path as a fixed number.

Cleaner than most legacy migrations, because the DBF format is well understood and the tools are standard. The tables are read through ODBC, OLE DB or a dedicated DBF reader, moved into SQL Server with the types mapped properly (dates, logicals, memos, the code page), and reconciled: record counts, totals, and a sample compared row by row.

The things that need a person rather than a tool: memo fields that hold structured data nobody documented, indexes that encode rules, deleted-but-not-packed records, and the second system that shares tables with the first.

It moves once, to SQL Server, and it never meets a change until the change has proven itself somewhere else. The migration is tested against a copy in a test environment, then run in staging with every table reconciled, before anything connects to live. The DBF files stay untouched as the fallback until you're confident.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a FoxPro system it reads the tables and the programs, tests how the data comes out, and prices containment, the data move and the rebuild as fixed numbers. The data move is usually the first stage and the one with the most immediate benefit. What drives the price and the payment terms each have a page.

A 32-bit runtime on an operating system that's moving on, with no vendor patches since 2015. A driver that modern software can't use, so every new tool the business buys has to be worked around. DBF files that corrupt under network load, like Access files do, and a backup nobody has tested. And the developer, who is one person, and who is retiring.

Data first, because it's the asset and because moving it fixes the most. Marc Allington has worked in FoxPro and in the SQL Server, .NET and web stacks it moves to. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.