Your factory runs on FoxPro. We make sure it survives the next 20 years.
MigrationParity migrates the systems mainstream agencies will not touch — FoxPro, Clipper, dBase/DBF, Microsoft Access, Lotus Notes/Domino, Advantage Database — to a modern .NET + SQL stack. Not by guessing what the old code does, but by proving, record by record, that the new system does the same thing.
Why these migrations fail — and why ours don't
A 30-year-old xBase or Notes application is not "just old code". It is three decades of business rules nobody wrote down: rounding behavior your accountants rely on, index collation your reports depend on, OEM codepages hiding in the data, workflows that exist only in one retired developer's head. Generic dev shops rewrite the screens, miss the rules, and the plant floor rejects the new system within a week.
We live in these systems
We still operate DBF-based production systems daily — index corruption, memo files, Hebrew and Cyrillic OEM codepages and all. This is maintenance experience, not a research project billed at your expense.
Parity testing, not promises
Before cutover, the old and the new system run the same inputs side by side. Every report, total and edge case is diffed automatically until the output matches — bugs you depend on included.
No big bang
The legacy system keeps running until the numbers prove the replacement is ready. If a stack can be contained cheaply first — Harbour for Clipper, a maintained server for ADS — we will tell you, even when it means a smaller project for us.
What we migrate
Visual FoxPro to .NET
FoxPro 2.x and Visual FoxPro applications rebuilt on .NET + SQL, with the business rules intact.
Clipper / xBase
DOS-era Clipper and xBase systems — contained with Harbour first, then migrated calmly.
dBase / DBF data
DBF tables moved to SQL with codepages, memo files and deleted rows handled correctly.
Microsoft Access
Access front-ends and Jet/ACE databases upsized to SQL Server and rebuilt for the web.
Lotus Notes / Domino
NSF documents, forms and reader-field security reproduced faithfully outside Domino.
Advantage Database (ADS)
Post-EOL strategy for SAP Advantage: freeze, replace the server, or migrate off DBF.
Free tool: DBF Analyzer
Drop a .dbf file and get its full structure in seconds: exact dialect
(dBase III, FoxPro 2.x, Visual FoxPro…), fields, codepage byte, memo and index
dependencies, deleted-record count and corruption warnings.
Everything runs in your browser — the file never leaves your machine.
From the field
-
Rewrite vs convert vs wrap: choosing a legacy migration strategy honestly
The real strategies for a legacy application — parity-tested rewrite, automated conversion, wrapping — compared by cost, risk and what you own afterwards.
-
Lotus Notes/Domino to .NET: what actually breaks
Field notes from migrating a ~9,000-document Notes application to .NET: rich text, reader fields, role mapping — the six places every NSF migration bleeds.
-
SAP Advantage Database Server after EOL: your realistic options in 2026
Advantage Database Server is discontinued. The four realistic paths — freeze, replace the server, migrate the data, retire the app — with benchmark notes.
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.