FoxPro Modernization:
Move VFP data and logic to a supported stack.

Visual FoxPro 9 left Microsoft extended support in January 2015, and Microsoft said in 2007 there would be no VFP 10. Many FoxPro applications still run because DBF tables and the VFP runtime are stable. The realistic paths are to stay and harden, bridge the data to SQL, or migrate. The assessment decides which one fits your code.

Book a free 1-hour consultation →

At a glance

Legacy sources: Visual FoxPro 9 · Visual FoxPro 3 to 8 · FoxPro 2.x for DOS and Windows · DBF, CDX, and FPT files · PRG programs · SCX forms and FRX reports · VFP OLE DB provider and ODBC driver
Modern targets: SQL Server · PostgreSQL · C# on .NET 10 · ASP.NET Core web UI · Windows desktop UI · Supported reporting engine · Hybrid bridge to VFP data
First step: Free 1-hour consultation, then a fixed-scope assessment
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery

What to know before you modernize

What FoxPro is and why it is still running

FoxPro began as an xBase database language, ran on DOS and Windows as FoxPro 2.x, and became Visual FoxPro with the version 3 release. It combined a programming language, a local database engine, a form designer, and a report writer in one product, so a single developer could deliver a complete data-entry application. Data sits in .DBF tables with .CDX index files and .FPT memo files, often grouped in a database container, and code sits in .PRG programs. Applications built this way tend to be small, fast on local data, and tightly coupled to their tables. They stay in service in accounting, distribution, healthcare billing, government, and manufacturing back offices because they work and because the business rules are buried in the code. The risk is rarely the language. It is the missing support, the 32-bit runtime, and the shrinking pool of people who can read it.

Which FoxPro you have, and what it implies

The version decides the first phase. FoxPro 2.x for DOS is a DOS program with text-mode screens and @ SAY/GET input. It cannot run on 64-bit Windows without an emulator or a virtual machine, which puts it closer to the work described on our MS-DOS modernization page. FoxPro 2.x for Windows and Visual FoxPro 3 through 6 are older 32-bit and mixed-era code, often carrying early object models and ActiveX controls that no longer install. Visual FoxPro 9, including Service Pack 2, is the final release and the one most teams still run. We read the project and the data, not the manual: the version stamp in the project file, the controls in use, the data-access style, and whether the code is table-driven or object-oriented. A DOS-era application and a VFP 9 class library are different jobs even though both are called FoxPro.

MS-DOS modernization →

Support status: what Microsoft said and when

Microsoft's lifecycle page lists Visual FoxPro 9.0 under the Fixed Lifecycle Policy, with a listing start of December 2004, mainstream support ending January 2010, and extended support ending January 2015. In March 2007 the VFP team announced there would be no VFP 10, that Service Pack 2 would follow, and that the Sedna add-on work would be released to the community at no charge. Microsoft's FAQ also states that VFP will remain 32-bit and run in 32-bit compatibility mode, and that the 2 GB limit applies per table. A security update for VFP 9 SP2 is still downloadable from Microsoft, but its page lists operating systems that stop at Windows 7 and Windows Server 2008 R2. So the product is out of support, has no successor from Microsoft, and has no published statement about current Windows versions. Staying is a risk decision, not a technical impossibility.

What breaks or blocks on modern Windows

Microsoft's Win32 documentation says 32-bit applications run on 64-bit Windows through WOW64, so a VFP 9 executable and its runtime can still start on a current 64-bit PC. Windows 11 itself requires a 64-bit processor. What blocks is the surroundings. Microsoft states VFP will remain 32-bit and ships no 64-bit version, and the same documentation says a 64-bit process cannot load a 32-bit DLL. The provider (VfpOleDB.dll) loads inside the calling process, so check its bitness against the tool that calls it: a 64-bit Excel, Power BI, or .NET service may be unable to open DBF data through it. Installers for the provider and older ActiveX controls can also fail on new machines. The DBF files live on a file share, so locking behavior on that share matters too. We test these on your target machines before recommending anything.

Moving DBF data to SQL Server or PostgreSQL

The data layer is the most valuable and most portable part of a FoxPro system. A DBF table maps cleanly to a relational table, but a good migration is not a copy. It resolves field types and widths, null handling, code pages, memo fields in .FPT files, deleted-but-not-packed records, and index expressions that encoded business rules. Referential integrity that lived only in the program code has to be found and turned into constraints. The Microsoft VFP provider documentation notes that a SQL Server linked server over the provider supports queries only, not inserts, updates, or deletes, so a linked server is a read path, not a sync path. The community VFPX Upsizing Wizard, an updated version of the VFP 9.0 SP2 wizard, is one starting tool. We write repeatable load scripts, rehearse them against a copy, and reconcile row counts and totals before any cutover. SQL Server and PostgreSQL are both sound targets; the choice follows your existing database estate and licensing.

Forms and reports: SCX, FRX, and what replaces them

Forms and reports are where the most manual work sits. SCX and FRX files are stored as tables, and they hold layout, control properties, and often embedded code and data expressions. Forms with a lot of event code convert poorly in bulk, because VFP's tight coupling of controls to open tables has no direct equivalent in a web or .NET desktop framework. The usual approach is to separate screens from rules: pull the business logic from form methods into a testable layer first, then rebuild the screens against it. Reports are inventoried by purpose, because many FRX layouts duplicate each other or are no longer run. Those that remain are rebuilt in a supported reporting engine, with PDF and Excel output as first-class outputs. Visual FoxPro screens that exist only to feed a nightly print run are often better replaced by a query and a scheduled report than by a faithful copy of the screen.

The realistic paths and when each is right

There are five. Stay and harden keeps VFP running with backups, locked-down shares, a documented build, and a second person who can compile it; it is right when the application is stable and the risk is manageable. Run in a virtual machine freezes the environment for a short time; it suits DOS-era programs or a stalled project, and the virtualization page covers it. Bridge moves the DBF data to SQL Server or PostgreSQL first, keeps the VFP forms attached through ODBC or remote views, and lets new work happen outside VFP. Migrate rewrites the logic and screens on a current stack, in phases. Rewrite from scratch is the highest risk and is justified only when the existing rules are not worth keeping. The strangler-fig article explains why we favor incremental moves. The assessment recommends one path in writing.

Rewrite vs strangler fig →

Choosing the target stack

Most FoxPro migrations land on C# and .NET 10 with SQL Server or PostgreSQL, because the skills are common, the tooling is supported, and a data-centric application maps well to it. The UI choice is separate: an ASP.NET Core web front end fits multi-site access and browser reach, while a Windows desktop client suits data-entry operators who live in the keyboard and want the dense screens they know. Other stacks are reasonable if your team already works in them; the criterion is who will maintain it in five years, not which language is fashionable. Reporting needs its own decision, because FRX layouts rarely port directly. Where the domain is audit-heavy or needs a history of changes, event sourcing and CQRS may be worth considering for part of the system, but a plain relational model is the default. The assessment names the target and gives the reasons for it, including any option we think you should rule out.

Event sourcing and CQRS book →

Parity testing and keeping the system running

FoxPro systems rarely have automated tests, so behavior is the specification. We build parity checks from the running system: the same input records through the old and new code, and a comparison of totals, ledger balances, invoices, and report output. Rushmore, the VFP query optimizer, uses indexes whose expressions must match exactly, and the VFP documentation says a query is optimized only when its condition exactly matches an index expression, so performance characteristics can change after a move. Collation and code-page differences change sort order and case matching between DBF and a SQL database, and those mismatches show up in reports first. A parallel run, with VFP still the system of record and the new code reading the same data, lets users compare before anything is switched. Cutover happens module by module in windows you choose, with a documented rollback to the VFP application until the new path has run clean through a full business cycle.

When not to migrate

Some FoxPro applications should stay. If the application is stable, is used by a handful of internal people, runs on a machine you control, and the DBF files are well under the 2 GB table limit, the cost of a migration may exceed the risk. In that case, stabilize it: move the files to a managed server with sane locking, back them up, keep the source and build tools safe, and document the build. Plan for the day the 32-bit runtime stops working with a new Windows release, because Microsoft has published no statement on that. Migration becomes the better answer when the data must be shared with other systems, when compliance requires audit and access control that DBF cannot provide, when the last developer is leaving, or when you need web or mobile access. We will tell you which side of that line you are on.

When not to modernize →

Start with an assessment for a FoxPro codebase

For a FoxPro codebase the read-only assessment inventories the project files and the VFP version, every DBF, CDX, and FPT file with record counts and sizes against the 2 GB table limit, the database container and any stored procedures, index expressions, SCX forms and FRX reports with usage evidence, PRG programs and class libraries, ActiveX and third-party controls, ODBC, OLE DB, and COM interfaces, scheduled jobs, printer and file-share dependencies, and the deployment and build process. Nothing is run against production and nothing is changed. The result is a written recommendation among stay, virtualize, bridge, and migrate, with a target stack, a data-migration approach, and a phased plan. The assessment fee is quoted after the free 1-hour consultation and is creditable toward a later modernization project.

About the assessment →

Deliverables

  • Written recommendation: stay, virtualize, bridge, or migrate, with reasons
  • Inventory of DBF, CDX, and FPT files, sizes, and index expressions
  • Data migration plan and rehearsed load scripts for SQL Server or PostgreSQL
  • Forms and reports inventory with keep, rebuild, or retire per item
  • Target architecture on .NET 10 with a phased delivery plan
  • Parity test plan and cutover and rollback runbook

Common questions

Does Visual FoxPro 9 still run on Windows 11?

Often it starts, because Microsoft documents that 32-bit applications run on 64-bit Windows through WOW64. But Microsoft ended VFP 9 extended support in January 2015, and the download page for its last security update lists Windows 7 and Server 2008 R2 as supported systems. Microsoft has published no Windows 11 statement, so test your own application, installers, and drivers on the target machine.

Is Visual FoxPro still supported by Microsoft?

No. Microsoft's lifecycle page lists Visual FoxPro 9.0 with mainstream support ending January 2010 and extended support ending January 2015. In March 2007 Microsoft announced there would be no VFP 10. A community project, VFPX, hosts open-source add-ons and tools, but it is not a vendor support contract.

Should we migrate FoxPro to SQL Server, PostgreSQL, or .NET?

These are separate choices. The data usually moves to SQL Server or PostgreSQL, depending on your database estate. The application logic and screens then move to .NET, typically C#, or stay in VFP for a while against the SQL data. You can do the data step first and the application step later, which lowers risk.

Can we keep running the FoxPro application during migration?

Yes. A phased plan keeps VFP as the system of record while the new code is built and compared against it. Cutover happens module by module in windows you choose, with a rollback to the VFP application until the new path has run clean through a full business cycle. We would not recommend a single overnight switch.

Do we have to rewrite everything to leave Visual FoxPro?

No. The data can move to SQL Server or PostgreSQL on its own, and the VFP forms can keep running against it through ODBC or remote views while screens and reports are replaced in stages. Some reports and screens can simply be retired. The assessment identifies which parts are worth carrying over and which are not.

How long does a FoxPro migration take and what does it cost?

It depends on scope. Site-wide, project work ranges from a few weeks (virtualization) to several months (re-architecture). Price and schedule are fixed only after the fixed-scope Legacy Software Assessment, which follows a free 1-hour consultation. The assessment fee is creditable toward a later modernization project.

Why can't my 64-bit Excel or Power BI read my FoxPro data?

The VFP OLE DB provider is a DLL that loads inside the calling process, and Microsoft's Win32 documentation says a 64-bit process cannot load a 32-bit DLL. Microsoft also states VFP stays 32-bit and ships no 64-bit version. If your tool is 64-bit, the practical fixes are a 32-bit client, an export job, or moving the data to SQL Server, which 64-bit tools can read.

Is there a way to modernize FoxPro for DOS?

Yes, but it is a different job from Visual FoxPro. FoxPro for DOS programs need a DOS environment, because 64-bit Windows has no 16-bit subsystem. The options are a virtual machine or emulator to buy time, or a migration of the data and logic to a current stack. Our MS-DOS modernization page covers both.

Sources

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.