Visual FoxPro to .NET — without losing 30 years of business rules
Your VFP application encodes decades of how your business really works. We move it to a supported stack and prove — record by record, report by report — that nothing changed except the foundation.
The situation you are probably in
The application was written between 1992 and 2005. The developer retired, died, or became a one-person single point of failure. It still runs the plant — orders, inventory, traveler cards, invoicing — better than the ERP that was supposed to replace it. And every year it gets scarier:
- Microsoft ended Visual FoxPro development in 2007; extended support ended in 2015. There is no vendor behind it anymore.
- DBF tables hit the hard 2 GB limit with no warning — when they do, the application simply stops.
- Index (
.cdx) corruption on network shares means someone rebuilds indexes at dawn — until the someone is gone. - IT wants it off the network: unpatched runtimes, SMB file shares, no audit trail, no encryption.
- Each attempt to "just rewrite it" died because nobody could enumerate what the old system actually does.
That last point is the real blocker — and it is precisely the problem we solve differently.
How we migrate FoxPro systems
-
Assessment: map the beast
We inventory every PRG, SCX form, FRX report, table, index expression and external dependency; measure which modules are actually used; and locate the dangerous corners — codepage mismatches, macro-substitution magic, private-variable scoping tricks,
SET DELETED OFFassumptions. Output: a written roadmap with risks and effort, at a fixed price. -
Parity harness: capture today's truth
Before writing new code, we build an automated harness that runs your real workflows on the existing system and records the results — report totals, calculated fields, rounding, sort orders. This becomes the contract the new system must satisfy. Bugs you rely on are preserved deliberately, not rediscovered in production.
-
Data first: DBF to SQL, verifiably
A repeatable pipeline moves DBF + FPT data into SQL Server or PostgreSQL: correct codepage per column (including OEM DOS pages like cp862 Hebrew and cp866 Cyrillic), memo content, date/empty-value semantics, deleted-row policy, index expressions re-implemented as constraints or computed columns. Counts and checksums on every run. The pipeline runs nightly from day one, so the SQL mirror is always fresh.
-
Rebuild in slices on .NET
Modules are rebuilt on .NET 8 — typically a web UI for most users plus focused desktop screens where the plant floor needs them — against the mirrored SQL data. Reports move first (read-only, low risk, instant value: they finally run without locking anyone out). Each slice ships when it passes parity, and users switch one workflow at a time.
-
Cutover and retirement
When the last write module passes parity, FoxPro becomes read-only, then an archive. You get the full parity report — evidence, not assurances — plus documentation the old system never had.
What survives the migration
- Business rules — pricing, rounding, allocation, validation logic, reproduced and now covered by tests.
- Your data, all of it — including memo fields, "deleted" rows you may still need, and text in legacy codepages.
- Reports people trust — same numbers to the cent, or a documented, signed-off explanation of every difference.
- Muscle memory where it matters — keyboard-driven entry screens can stay keyboard-driven; we do not force a tablet UI on a warehouse terminal.
What does not survive: the 2 GB limit, index rebuilds at dawn, the single person who knows where the bodies are buried, and the fear of Windows Update.
Frequently asked questions
Should we rewrite our FoxPro application or convert it automatically?
Automatic FoxPro-to-.NET converters produce code that compiles but is harder to maintain than the original — VFP idioms transliterated into C# with the benefits of neither. We rebuild against a parity harness instead: behavior is preserved because it is tested, not because syntax was mechanically translated. See rewrite vs convert vs wrap.
Visual FoxPro still runs. Why migrate at all?
It runs until it does not. VFP 9 SP2 shipped in 2007 and extended support ended in January 2015. The runtime still works on Windows 11 today, but every OS update is a gamble nobody underwrites, the 2 GB per-table limit is absolute, and the pool of people who can fix a corrupted CDX index at 7 a.m. shrinks every year. The right time to migrate is while the old system still works — that is exactly what makes parity testing possible.
Can the business keep working during the migration?
Yes — that is a hard requirement of our process, not a nice-to-have. The FoxPro application remains the system of record while we build. Data is mirrored to SQL continuously, read-only functions (reports, lookups) move first, and write functions cut over module by module, each gated by parity results. There is no weekend where the plant switches everything at once.
What happens to our DBF data — and our Hebrew, Cyrillic or accented text?
DBF-to-SQL is where FoxPro migrations quietly corrupt data. Codepage bytes are often wrong or absent (DOS-era files usually carry none at all), memo files hold the real content, deleted-but-never-PACKed rows linger, and index expressions embed business logic. We handle each explicitly, with row counts, checksums and field-level diffs proving the transfer. Run our free DBF Analyzer to see what is actually inside your tables.
What about our FRX reports?
FRX report definitions are DBF tables themselves — we extract layouts and expressions from them, agree with you which reports are still alive (in practice a third or more are dead), and rebuild the survivors on a modern reporting engine with output compared against the originals on real data.
How long does a FoxPro migration take?
A typical single-site VFP application — tens to a few hundred forms, a few hundred tables — is a 4–12 month journey, driven mostly by how much of it is still actually used. The assessment gives you a per-module estimate up front, including containment options if a full migration is not yet urgent.
Start with a fixed-price Legacy Assessment
One to two weeks. You get a full inventory of the application and its data, a risk map (what breaks first, what is undocumented, what nobody can rebuild), a data-quality report and a migration roadmap with honest effort estimates — a document you can execute with us or with any other team. Fixed price, agreed before we start.