MigrationParity Migration for the systems everyone else gave up on
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.
Six legacy stacks we maintain in production today — not researched at your expense.
Old and new systems run side by side and get diffed automatically before cutover.
If containing the system is cheaper than replacing it, we say so — smaller project for us.
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.
How a migration runs
Legacy assessment
We read the data and the code: dialects, codepages, indexes, memo files, the rules hidden in reports.
Behavior frozen as tests
Current outputs become executable expectations — including the quirks your staff works around.
Rebuild and diff
The .NET + SQL system is built against those tests and diffed against the live system on real data.
Phased cutover
Module by module, with the legacy system still running until the numbers agree.
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.
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
All articles →-
Harbour in 2026: the first stable release in 15 years, and what it means for your Clipper app
Harbour 3.2.0 shipped in July 2026 — the project's first stable release since 2011. What it changes for companies still running Clipper, and what it honestly does not fix.
-
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.
Start with an assessment, not a rewrite.
Send us the stack you are on and what hurts. You get a written read of your data and code, the realistic options — including the ones that cost you less — and what parity testing would cover. Fixed price, agreed before we start.