Visual FoxPro Migration in 2026: Why It Is a Liability and How to Move Without Breaking the Business

Is Visual FoxPro really unsupported in 2026?

Yes. Microsoft published the lifecycle dates years ago and they have not moved since. Visual FoxPro 9.0 mainstream support ended on January 12, 2010. Extended support ended on January 13, 2015¹. After that point Microsoft was no longer obligated to issue bug fixes for the language. One exception happened later: a single out-of-band security patch in March 2021 for an ActiveX control vulnerability that affected Windows itself, not VFP as a product².

Public CVE records list more than a dozen documented vulnerabilities affecting VFP ActiveX controls, including memory corruption issues in MSCOMCTL.OCX and FPOLE.OCX that allow remote code execution³. None of those will be patched in the VFP runtime. They sit there, indefinitely, in every compiled VFP application that uses the affected components.

Software does not stop working on the day support ends. The risk profile changes on that day, and it keeps changing every year afterward.

What actually breaks first when you stay on VFP?

Three failure modes show up in the field, in roughly this order. None of them announce themselves before they happen.

How big is the VFP installed base in 2026?

The market data confirms what PCG sees in the field. According to Enlyft, more than 5,400 companies worldwide still ran Visual FoxPro in 2025, concentrated in IT services, software, and small to mid-sized businesses of 10 to 50 employees⁵.

Those numbers track with the pattern we see when buyers reach out. A VFP application built in 1998 by a single developer is now running a 30-person manufacturer or a 20-person environmental services firm, and the buyer is one of three people in the building who remembers how it was deployed. The application works. Nobody has touched it in years. The Windows server it runs on is older than several employees.

That last detail is the one that matches every VFP project we have run since the late 1990s. The code is migratable. What gets in the way is that nobody in the building can describe what the code is supposed to do, because the person who wrote it retired in 2017 and the documentation lives on a Word file someone last opened in 2014.

Migrate, integrate, or replace: which path fits your application?

There is no single right answer. The three real options each fit a different situation, and the wrong choice wastes time, budget, and team capacity that the business needs elsewhere.

A third path, integration, is sometimes the realistic short-term move. Wrap the VFP system in a modern API layer so new applications can read and write its data without depending on the VFP runtime. This buys time but does not retire the risk. It is a bridge, not a destination.

What does a real Visual FoxPro to .NET migration look like?

PCG has been running custom software projects since 1995. The migration pattern we use on VFP work has been refined across a long list of legacy rescues. Its shape is consistent. Duration depends on size.

Phase 1: Discovery

Read the source code. Read the production database. Inventory every form, report, stored procedure, scheduled task, and external integration. The deliverable is a written inventory of what the application actually does, not what it was supposed to do. This is also where invented or undocumented business rules surface, because they show up in the code.

Phase 2: Architecture and quote

Decide the target stack, the schema redesign, the integration points, the reporting tool, and the cutover sequence. PCG quotes a fixed price on the migration scope at this point. Not time and materials. Fixed scope, fixed price, with explicit assumptions documented.

Phase 3: Build in parallel

The new .NET application is built alongside the running VFP system. Data flows are mirrored so the new system can be validated against current production results. Users are not asked to test anything until the team can stand behind the numbers.

Phase 4: Module-by-module cutover

Each functional area moves to the new application with a documented rollback path. Reports run in both systems for a defined period and outputs are compared. The VFP application stays live until every module has cleared its checkpoint.

Phase 5: Decommission

Final data export, archive of the legacy system for compliance retention, retirement of the VFP runtime. The decommission step is where compliance officers want documentation, and where the migration provides it.

What gets migrated and what gets rebuilt from scratch?

Not every line of VFP code deserves to move. A careful migration is honest about which parts of the legacy system reflect business value and which parts reflect 1998 workarounds.

What if the original Visual FoxPro developer is gone?

Most VFP migrations PCG quotes start exactly this way. The original developer retired, moved on, or passed away years before anyone thought to capture what they knew about the system. Source code lives on a network share that nobody has touched since the last meaningful change, which is usually dated somewhere between 2012 and 2018. Nobody currently on staff can answer a real question about how a particular calculation works.

This is a discovery problem, and it is solved by reading rather than interviewing. The source code, the compiled executable, the database schema, and the production data together describe what the application does. PCG works through this systematically during Phase 1 and produces a written inventory that the business can sign off on before any rewrite begins. The buyer ends Phase 1 knowing what they own, regardless of whether the migration moves forward.

What drives the scope of a Visual FoxPro migration?

Every migration price and timeline depends on the specific application. Generic answers do not exist in this work, and any quote given before a discovery phase is a guess. Five measurable inputs determine the actual scope of the project.

• Lines of code: Total VFP source size, including stored procedures and triggers. A 50,000-line application is a different project from a 500,000-line one.
• Database size and table count: A 50-table schema with 4 GB of data quotes differently from a 12-table schema with 80 GB of data.
• Report count and complexity: Each VFP report is a small project of its own. Forty reports take longer than ten.
• Integration count: Each external system the application talks to (accounting, payroll, EDI, hardware) adds discovery and rebuild time.
• ActiveX control inventory: Third-party ActiveX controls used in the application drive scope, because each one needs a modern equivalent.

PCG runs a fixed-fee discovery phase before quoting the migration itself. The deliverable from discovery is a written inventory of what the application does, the migration approach, and a fixed scope and timeline based on real numbers from the codebase. Buyers who go through discovery keep the deliverable whether or not they proceed to migration.

How do you avoid breaking the business during the migration?

Parallel operation is non-negotiable. The VFP system stays in production while the new .NET application is built and validated. Data is synchronized between the two systems during the build phase so the new application can be tested against current production results, not stale snapshots.

Cutover happens module by module. Each module clears a defined checkpoint before the next one moves. A documented rollback path exists at every step. If something fails in the new system, the team rolls back to VFP in minutes, not in a weekend war room. The big-bang cutover, where a business migrates everything in one weekend, fails often enough that PCG no longer offers it as an option.

31 years of running custom software projects has taught us one thing about legacy migrations: the technical risk is manageable, and the business continuity risk is what actually sinks projects.

Frequently Asked Questions