Tag: FoxPro to .NET

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.

Windows feature updates

Each Windows 11 feature release adjusts the WOW64 32-bit layer, printing subsystem, and font rendering.¹ VFP reports built before 2010 are the most fragile. The application opens fine the morning after the update, then a report fails at month-end.

The 2 GB table ceiling

VFP tables are capped at 2 GB each due to 32-bit addressing.⁴ Inventory, transaction, and audit log tables that grew slowly for years hit the ceiling at the worst possible moment, usually during a busy quarter, and writes start failing without a clean error message.

The talent cliff

FoxPro DevCon ran for the last time in 2009. Developers who built production VFP systems in the late 1990s are retiring. Finding someone who can read 200,000 lines of legacy FoxPro and tell you what it does is a real recruiting problem, and the rate per hour reflects scarcity.

The developers who built these systems are retiring or becoming unreachable. If yours already has, here is what to do when your original developer disappears.

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.

What has changed for Visual FoxPro users in 2026?

Three developments in 2026 have narrowed the runway for businesses still running Visual FoxPro, and none was announced in advance.

• The talent shortage now shows up in the price. As of September 2026, ZipRecruiter salary data puts the average Visual FoxPro developer in the United States near 102,000 dollars a year, reaching 125,000 at the top of the range.⁶ A discontinued skill that commands six figures is a skill almost nobody has left, while the maintenance demand has not gone away.
• Windows 11 keeps shifting the ground under the runtime. Every feature release adjusts the WOW64 32-bit layer, the printing subsystem, and font rendering, and reports built before 2010 break first, usually at month-end rather than on update day.¹
• The 2 GB per-table ceiling is a live failure now, not a theoretical one. Tables that grew slowly for two decades are reaching the limit tied to 32-bit addressing, which Microsoft declined to lift, and writes start failing without a clean error message.⁴

The pattern across these three is the same. Nothing stops on a scheduled date. The options narrow year by year, and the narrowing tends to end abruptly, with a Windows update or a resignation letter.

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.

FoxPro rarely stands alone in a business. If your shop also runs older xBase code, the same decision applies to dBase and Clipper applications still running in 2026, which share FoxPro's 32-bit limits and its shrinking developer pool.

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, then 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.

Every phase length is set by the specific application: lines of code, database size, report and integration count, and how much documentation the team can still recover. A planned migration runs on a predictable schedule because the discovery phase produces a real scope. An emergency migration, triggered after a Windows update has broken production, runs on whatever schedule the broken business can survive. The cost of waiting is not theoretical.

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. Business rules, validation logic, pricing formulas, regulatory calculations, and approval workflows that still match how the business operates get migrated. DBF data converts cleanly to SQL Server via SSIS or scripted ETL, with the schema redesigned rather than copied. VFP reports get rebuilt in SQL Server Reporting Services or a modern reporting tool, keeping visual parity where the user community depends on the layout. Forms are rebuilt one by one in Blazor, WPF, or a web front end, matching the workflow rather than the pixel layout of the originals.

What if the original Visual FoxPro developer is gone?

PCG rescues legacy Visual FoxPro and dBase applications when the original developer is gone. This is the most common situation on FoxPro work: the developer who built the system retired or passed away years ago, and the source code has not been meaningfully touched since somewhere between 2012 and 2018. PCG rebuilds from the evidence that still exists. The source code, the compiled executable, the database schema, and the production data together describe what the application does. PCG reads them systematically during discovery and produces a written inventory the business signs off on before any rewrite begins. The buyer ends discovery knowing exactly what they own, whether or not the migration moves forward.

This is a reading problem, not an interviewing one. The people currently using the application can describe it from the outside, but the authoritative account of what it does lives in the code and the data, and that is where PCG starts. When even the source code is gone, the situation gets harder and carries its own cost and recovery path.

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, whether accounting, payroll, EDI, or 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.

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.