Service · Software development

Replacing your FoxPro application.

Stock management, customer management or administration still running on a FoxPro application from the nineties or early two-thousands. The data sits in DBF files on a network drive, and the program launches from a shortcut on a PC running a version of Windows that Microsoft stopped supporting years ago. We replace FoxPro applications with a modern web application, with careful export of your existing data and a transition that doesn't halt your day-to-day work.

Arrange an introductory call See our work

↻

A DBF file is not a database, it is a risk.

FoxPro, and later Visual FoxPro, was a popular platform for small and medium-sized business applications in the nineties and two thousands: accounting, stock management, customer management, invoicing. Microsoft took over developer Fox Software in the early nineties and released the last version, Visual FoxPro 9.0, in 2007. No new version has appeared since, and both mainstream and extended support finally ended in January 2015. No more security updates, no patches, no official support: the platform has been frozen for more than ten years.

The underlying data is usually held in DBF files, a simple table format with no real database engine behind it. Each table is a separate file, memo fields sit in a separate .fpt file and indexes in a separate .cdx file. That works fine for a single user or a small group on the same network, but there is no serious concurrency layer underneath: with simultaneous writes, a flaky network connection or an application that doesn't close cleanly, a DBF file can become corrupted relatively quickly. There is no built-in repair function; recovery requires specialist tools and doesn't always fully succeed.

A second layer of risk comes on top of this. To keep the application running, the underlying Windows version has often been running in compatibility mode for years, sometimes a version Microsoft no longer supports either. Application and operating system are then both end-of-life: a double security risk with no vendor still releasing a patch. Even hiring a FoxPro developer to temporarily mitigate this is becoming harder. That makes FoxPro a slightly different kind of risk from a Delphi application or an AS/400 system: it is not only the language that is outdated, the file format underneath also lacks any form of modern database protection. Our broader approach is described under replacing legacy software.

How we approach FoxPro projects.

Data export first

Full inventory and export of the DBF tables before anything is built

Rebuilding the logic

Reconstructing business rules from screens, code and actual use

Phased transition

Module by module, with validation at each step and the old system as a safety net

Data ownership

Full migration with checks and a read-only archive of the old system

From FoxPro to a modern web application.

At its core, every FoxPro project follows the same three movements: extracting the data without loss, rebuilding the business logic in a modern application, and phasing the transition so that operations never come to a standstill.

Approach 01

Data export from the DBF files

The first step in every project

We inventory all tables, fields and the relationships between them, including memo fields and index files that are often undocumented. Relationships between tables were rarely formalised as foreign keys in FoxPro; we reconstruct them through naming conventions, code fields and actual use. The data is moved to an intermediate format and validated per table against the original: record counts, key fields and referential consistency.

Where DBF files turn out to be already damaged, we record this before any further work. We would rather have an honest list of missing records at the start than a surprise after the transition.

DBF inventoryMemo and index filesValidation against the originalCorruption checkIntermediate CSV/SQL formatReferential integrity

Approach 02

Rebuilding the business logic

The real work lies not in the screens, but behind them

A FoxPro application consists of forms with procedural code directly behind them. Validation rules, calculations and exception handling are often woven into the screens themselves and rarely documented anywhere. We reconstruct that logic through code analysis, interviews with the people who use the system every day and observation of how it is actually used, then translate it into a modern architecture with a proper database underneath.

Not every FoxPro system requires a full rebuild. For a smaller, well-defined part, a lighter approach may be enough, extending or wrapping the existing system rather than replacing it. That route is covered under legacy software modernisation. Because of the fragility of DBF files, with FoxPro it is more often an intermediate step than the final destination.

Analysing forms and screensReading procedural codeInterviews with usersMaking business rules explicitModern architectureTesting against legacy behaviour

Approach 03

Phased transition with data conversion and validation

Never all at once, always module by module

The new application grows module by module alongside the FoxPro application. Each module only goes live once its data conversion has been validated: record counts, totals and key fields are compared against the original DBF tables. Users work with both systems for as long as needed, and the FoxPro application remains as a safety net until a given process has proven stable.

Only once all modules have been taken over is the old environment decommissioned. A read-only archive of the final DBF state is retained, in case an old report or historical correction is ever needed.

Module by moduleValidation suiteParallel runningRollback pathCut-over per processRead-only archive

What you have at the end.

A working web application on a modern database, a decommissioned FoxPro environment and an organisation no longer dependent on file locks on a network drive.

Modern web application

Accessible through the browser, no longer tied to a specific PC or network drive.

Proper database

A relational database instead of DBF files, with transactions and concurrency that scale with the number of users.

Migration report

Which tables and records have been migrated, which discrepancies were found and how they were resolved.

Decommissioning plan

When and how the FoxPro environment is switched off, and which read-only archive remains.

Managed service (optional)

Monitoring, backups, updates and further development under a maintenance contract.

Risks we address explicitly.

Replacing FoxPro affects not only technology but also security, knowledge and accessibility. Four risks that sit at the top of every project.

Security

Double end-of-life risk

The application has been without support since January 2015, and often runs on a version of Windows that no longer receives patches either. We move the new application to a current, supported platform, so that security risk at both the application and operating system level disappears.

Data

Corruption and data loss

DBF files are vulnerable to damage from network interruptions, simultaneous writes or an application that does not shut down cleanly. We carry out a data audit beforehand and run a validation suite that compares every migration run against the original.

Skills

No FoxPro developers left to hire

The group of people still fluent in FoxPro is shrinking. Even hiring a temporary developer does not solve the underlying platform risk; it only postpones it. We reconstruct the business logic so that the knowledge no longer sits with a single scarce specialist.

Access

No web access or remote working

FoxPro is a Windows desktop application, often limited to a single PC or a small network with no mobile or remote access. The new web application works from any location and on any device by default, with standard user permissions instead of file locks.

How a FoxPro project works.

01Introduction→ 02Discovery & data export→ 03Build & data conversion→ 04Cut-over & management

Step 01

Introduction

Which FoxPro application you run, how many users work with it, and where the acute pain lies. A no-obligation conversation with IT and operations.

Step 02

Discovery & data export

We map the DBF tables, carry out a data audit, interview key users and reconstruct the business logic behind the screens.

Step 03

Build & data conversion

Working modules delivered in sprints, with a validation suite for every conversion run and parallel running alongside the existing FoxPro application.

Step 04

Cut-over & decommissioning

Phased transition module by module, with the old environment eventually switched off and a read-only archive of the final DBF state remaining available.

From FoxPro and DBF to a modern stack.

FoxPro systems vary considerably in size and complexity, but the underlying risks, DBF files without concurrency protection and a language without an active developer pool, are almost always the same. Below is an overview of where we are starting from and where we are building towards.

Where we are starting from

FoxProVisual FoxProDBF tablesFPT memo filesCDX/IDX indexesWindows in compatibility mode

Target stack, frontend & backend

Next.jsAstroReactNode.jsPython.NET 8PostgreSQL

Migration, infrastructure & integration

ETL conversion scriptsData validation suiteAuth0Azure ADDockerGCP/AWSTerraform

Frequently asked questions.

How long can a FoxPro application safely keep running?

That depends on how much risk your organisation can tolerate, not on how stable the system appears. Visual FoxPro has had no support since January 2015: no updates, no patches, and no vendor still responding. Often the application also runs on a version of Windows that has itself been end-of-life for years. As long as nothing from outside touches it and the DBF files do not become corrupt, it can keep going for a long time, until the moment it no longer does.

What if the DBF files are already partially damaged?

That is more often the reason people get in touch than an exception. We start with a data audit: which tables still open normally, which memo or index files throw errors, which records are missing or duplicated. With specialised recovery tools, the great majority of damaged DBF data can usually still be salvaged. Where that is not possible, we document which records are missing, so you can make an informed choice about any supplementation from older reports.

Can't we simply hire a FoxPro developer to keep it running?

That eases the problem temporarily, but it does not remove the underlying risk. FoxPro developers are scarce and becoming scarcer, so the cost and lead time of finding someone keep rising. Even with an experienced developer on board, the application still runs on a platform Microsoft no longer patches and on DBF files without concurrency protection. A temporary developer buys time, not security.

Why is the risk with FoxPro greater than with other legacy systems?

With many legacy systems, mainly the language has become outdated, while the data sits in a proper database. With FoxPro it is different: DBF files are not a database server but loose table files, without transactions, without serious concurrency control and without a built-in repair function. That makes corruption more likely as the number of users grows. We see comparable language and knowledge risks with a Delphi application or an AS/400 system, but there the database layer is usually more robust.

How do you make sure we are not left without a working system during the transition?

Never switch over all at once. After the discovery phase and the initial data export, we build module by module while the FoxPro application remains in use. Each module is validated against the old data before users work with it, and the legacy system remains as a safety net until a sub-process has demonstrably been running stably. Only once everything has been transferred do we switch off the old environment and keep a read-only archive of it.

What happens to reports and exports that are currently generated from FoxPro?

We inventory these during the discovery phase as part of the business logic, not as an afterthought. A nightly export to the accounts department, a monthly report for management, or a manual correction routine have often quietly become part of the process over many years. We map them out through interviews and observation of actual use, and build the equivalent report in the new application before the old one is switched off.

Do we retain ownership of the new application and the data?

Yes, entirely. The code, infrastructure, documentation and credentials are registered in your name, in a repository you manage yourself or which is handed over at the end of the engagement. The migrated data also remains yours, with a documented export format. If you choose our post-delivery management layer, that ownership position does not change: management is a service you can stop, not an arrangement that locks you in.

Talk to us about your FoxPro system.

A free, half-hour introductory call. We listen to what is running today, how the DBF files are set up, and what has prompted you to look at it now.

Schedule an introductory call Email fabian.vandijk@appfront.nl