DEV Community: Hayim Romanovsky

Migrating Lotus Notes to SQL Server: mapping documents to tables

Hayim Romanovsky — Fri, 06 Nov 2026 08:00:19 +0000

Originally published at migrationparity.com.

The inventory script finished at two in the morning and told me our twenty-year-old
NSF contained not one schema but three. Documents saved before 2008 had one set of
items, documents from the middle years another, recent ones a third — same form name
on all of them. SQL Server was going to want one answer, and the database had nine
thousand opinions.

That tension — a bag-of-items document store on one side, tables with columns on the
other — is the whole project. The export itself is a solved problem; any tool can walk
an NSF and emit rows. What follows is where the mapping decisions actually live, from
a ~9,000-document workflow application I took to .NET with a SQL Server backend.

Columns come from documents, not from the form

The form designer shows you what a new document would get. It says nothing about
what the existing nine thousand are carrying. A Notes document keeps every item it
was ever saved with, under whichever revision of the form existed that year — fields
that occur only in 2003–2007, fields renamed twice, one field whose name contains a
typo made around 1998 that could never be fixed because thousands of documents
already had it. The typo goes in the mapping table like everything else.

So the schema comes from an item census: scan all documents, collect item names,
types, value counts, fill rates. Cluster by generation. The SQL schema is designed
against the union, with an explicit rule per generation — convert, default, or
consciously drop. Anything built from the current form design alone loses data
without telling you.

Multi-value items want child tables

Notes lets any field hold a list. Approvers, categories, linked batch numbers —
one item, five values, no ceremony. SQL has three ways to take this and two of them
are traps. Concatenating with semicolons means every future query does string
surgery. Columns named Approver1 through Approver8 work until the ninth approver.

The boring correct answer is a child table per genuinely multi-valued item:
document_id, position, value. Position matters — in Notes workflows the order
of a names list often is the approval order, and flattening it to a set quietly
rewrites the business process. Where a multi-value field turned out to hold one value
in 99% of documents, I kept it as a column and moved the exceptions into the child
table during cleanup, each one eyeballed. There were eleven.

The response hierarchy is already a foreign key

Notes documents form trees: main document, responses, responses-to-responses. Under
the hood each response carries $REF — the 32-character UNID of its parent. That is
a parent key wearing a trench coat.

The mapping is mechanical — parent_id column, foreign key, done — but two things
bite. First, UNIDs must survive the migration as a column (unique-indexed), because
every doc link anyone ever pasted into an email or another document addresses the
UNID, and because your own migration needs the old identity to be re-runnable.
Second, orphans exist: responses whose parent was deleted years ago. Our database
had a few dozen. Decide their fate in the mapping spec — adopt, archive, or drop —
not at 2 a.m. when the foreign-key constraint fails.

Rich text is a file format, attachments are a separate estate

I covered rich text in detail in
what actually breaks in a Notes migration:
treat it as a document tree, convert to disciplined HTML, extract embedded objects.
For the SQL mapping the decision is narrower — rich text does not go into SQL
Server beyond the HTML body. Images, attachments and OLE objects go to real file
storage with reference rows.

One trap deserves its own paragraph. If the Domino server uses DAOS, the NSF you
copied for testing does not contain the attachments at all — it contains tickets
pointing into a directory of .nlo files on the server. Ours held 32 GB across
roughly sixty thousand of them. A migration rehearsed against a bare NSF copy
reports success and delivers a database where every paperclip icon leads nowhere.

Names are not users

Every author, approver and reader in the NSF is recorded as a hierarchical Notes
name — CN=Dana Levy/OU=QA/O=ACME — not as a login your new system knows. People
married, transferred departments, retired in 2011 and are still named on open
documents. SQL wants a users table with stable IDs; your HR system joins to Notes
names only by string matching, if at all.

Budget a name-resolution pass as a first-class migration table: Notes name →
canonical person → new system account, with a human owner for the unmatched
residue. It looks like a utility script. It is two weeks.

Reader fields become row-level security, or your migration is a breach

Reader and author items make documents invisible at the engine level; export them
to SQL without reproducing that and on day one everyone reads everything —
confidential cases included. Nothing will look broken. In SQL Server the honest
equivalent is row-level security predicates driven by the same person/role mapping
as above, tested by logging in as sampled real identities on both systems and
diffing what each one sees.

The short version of the mapping

In the NSF	In SQL Server
Form (all historical generations)	Table designed against the item union
Item	Column, with per-generation conversion rule
Multi-value item	Child table with position
Response / `$REF`	`parent_id` FK; UNID kept as unique column
Rich text	HTML body + files in storage, reference rows
DAOS attachment	File in storage — only reachable via the server
Notes hierarchical name	Row in a name-resolution table
Reader / author fields	Row-level security predicates
Document history item	Verbatim text, appended-to, never rewritten

The last row is deliberate. Our application carried its whole audit trail as one
ever-growing text item per document. The temptation is to parse it into neat event
rows. Parse a copy if you want the analytics — but keep the original text column
byte-for-byte, because it is the only record auditors already trust, and the parser
will be wrong about 1997.

The export tool finished its part in an afternoon. The mapping spec — the real
deliverable — was forty pages, and every page was one of the rows above arguing
with twenty years of actual documents.

This is the kind of mapping our
Lotus Notes / Domino migration service
produces before any code is written — and the parity harness then proves the result
against the live NSF, document by document. If you are sizing such a move, start
with the assessment.

Case study: the 1997 insurance system that stopped printing on Windows 11

Hayim Romanovsky — Fri, 06 Nov 2026 08:00:16 +0000

Originally published at migrationparity.com.

The inquiry came through the site's contact form on a Monday: a small insurance
firm in the American South, still running the agency management system it bought
in 1997. The software worked. The data was fine. But on the office's new
Windows 11 laptop, under the vDos DOS emulator, every report ended in the same red
box — "Couldn't access temporary file" — and nothing had printed for months. The
old Windows XP machine, where everything worked, had just refused to boot.

The owner didn't want a migration. They wanted their balance sheet.

What was actually running

It was a Clipper-built agency management package from 1997 — vendor long gone, no
source code, modules for marketing, accounting and document imaging. Reports go
through an embedded R&R Report Writer runtime from 1995. Printing was designed for
an HP LaserJet on a serial port, speaking PCL. The office's current printer is a
Wi-Fi inkjet that has never heard of PCL.

The installation media the client could share was the original distribution: nine
spanned diskette images, straight from the era when software arrived in a cardboard
box. I installed it into a clean vDos sandbox on my side and had their exact error
on the screen the same evening — without any printer attached at all. That
mattered: the printer was innocent.

The actual fault, three layers down

The report module failed before it ever reached printing. The main executable is
built with Blinker 3.30, a DOS extender; when it launches the report engine it swaps
itself out of memory and execs the child process. That swap-run mechanism needs a
DPMI host — a memory-management service that real DOS setups of the era, and the
NTVDM layer in Windows XP, quietly provided.

vDos doesn't provide one. The swap fails silently, the report engine never starts,
and the application reports the only thing it can see: the output file its child
never produced. "Couldn't access temporary file" — technically true, maximally
misleading. It took a 49-byte stub program planted in place of the report engine to
prove the engine was never being called at all.

The fix was small — finding it was the job

Once the cause was pinned down, the remedy fit in a small kit the client installed
themselves from a two-step README: a memory-management host that loads before the
application, and a rendering layer that catches the application's print jobs and
turns each one into a PDF — from there, any modern printer. The 1990s printer
profiles inside the application stayed untouched; PCL is just a language, and it
got a translator.

Two days of that week went into the diagnosis — reproducing the environment,
instrumenting a binary with no source, ruling out the printer, the config and the
emulator one by one. The installation took the client about a minute. That ratio
is normal for this kind of work; it's also why the fix survives Windows updates
instead of being a lucky tweak.

No reinstall, no data conversion, no settings changed inside the application. The
client's verdict, verbatim: "This ran perfectly… probably under DOS 6.0."

The numbers


Time from first email to confirmed fix	8 days
Remote sessions / calls needed	0 — email and screenshots only
Price	a few hundred dollars, fixed — half up front, no-fix-no-fee
Change to the client's data or workflow	none
Follow-up utilities since	2 small ones, same by-email pattern

A week later the client was entering policies again and running the system
side-by-side with the books through year end. The agency's thirty years of customer history
stayed exactly where it has always lived — in DBF tables a
free analyzer can read in your browser.

Why this is on a migration consultancy's site

Because containment is a legitimate outcome. The decision framework in
rewrite vs convert vs wrap has a branch
most vendors skip: when the system is sound, the business is small and the pain is
environmental, the right engineering is to fix the environment — and keep the
migration conversation for the moment it earns its cost. A repair costing a few
hundred dollars that buys years is a better first step than a $50,000 rewrite that
buys the same years with
more risk. When this client is ready for more — a modern front end, a second user,
the cloud — the path is mapped, and nothing done this week blocks it.

If you have a Clipper-era system that still earns its keep but fights its
environment, that's exactly the shape of problem our
Clipper / xBase service starts with —
assessment first, and sometimes the assessment honestly says: don't migrate yet.

Rewrite vs convert vs wrap: choosing a legacy migration strategy honestly

Hayim Romanovsky — Fri, 06 Nov 2026 07:43:51 +0000

Originally published at migrationparity.com.

Every legacy application owner eventually sits through three contradictory sales pitches:

"Rewrite it" — from a dev shop that has never seen your business rules.
"Convert it automatically" — from a tool vendor whose demo compiles your code to C# in an afternoon.
"Don't touch it, just wrap it" — from whoever will be blamed if the migration fails.

All three strategies are real, and each is correct somewhere. Here is the honest comparison —
including the option the pitches skip.

Rewrite: rebuild behavior on a new stack

A rewrite does not have to mean "start from the requirements and hope". Done properly, the old
system itself is the specification: you capture its actual behavior as an executable
parity harness — reports, totals, edge
cases, bugs included — and rebuild module by module until the diff is empty.

Get: a system you fully own — modern stack, hireable developers, testable code, and the first real documentation the application has ever had (the harness itself).
Pay: the most money and calendar time of the three. The parity harness is 15–25% of the budget before any new code runs — that is the price of "nothing changed except the platform".
Fail mode: the unharnessed rewrite — screens rebuilt from screenshots, rules from memory. This is the version that produced the migration horror story your CFO remembers, and it deserves its reputation.

Convert: transpile the code automatically

Conversion tools parse your Clipper/FoxPro/VB/PowerBuilder code and emit the equivalent in a
modern language. The demo is genuinely impressive: a week in, everything compiles.

Get: speed to "runs on the new platform", preserved logic (including logic nobody understands), and sometimes the only viable path when the codebase is enormous and the budget is not.
Pay: afterwards. The output is your old program wearing a new language — xBase idioms, global state and GOTO-shaped control flow transliterated into C# that no C# developer will enjoy or safely change. You have swapped a maintenance problem you knew for one you do not.
Fail mode: treating conversion as the destination. As a bridge — convert to retire the dead platform today, then refactor with the converted code as a reference — it can be rational. As an endpoint, it usually means paying for the same migration twice.

Wrap: keep the engine, replace the surface

Wrapping keeps the legacy core running and builds new access around it: a web front-end over
the old database, an API layer screen-scraping or driving the old app, new reports reading a
mirrored copy of the data.

Get: fast, cheap, low-risk wins — modern UI for the 20% of workflows that needed it, integration endpoints, reporting freedom. Often the right first move, and sometimes right for years.
Pay: the legacy core is still there — same platform risk, same 2 GB limits, same single point of failure, plus a new synchronization layer to operate. Complexity went up, not down.
Fail mode: the permanent temporary solution. The wrap relieves the pain that was funding the migration, the project stops, and five years later the organization runs two systems forever. Wrap with an explicit expiry date or do not wrap.

The skipped option: contain, then decide

For 16-bit-era xBase systems there is a fourth move the pitches rarely mention because no one
sells licenses for it: containment on an open-source runtime. Recompiling Clipper-dialect
code with Harbour produces a native modern executable on
the same data files — the platform emergency (dying hardware, DOS boxes, 16-bit Windows) ends
in weeks, for a fraction of any other option, without betting the business on a big project.

Containment is not the destination either. It is what buys the calm in which a rewrite can be
done properly instead of heroically.

How to actually choose

Question	If the answer is yes →
Is the platform actively collapsing (hardware, OS, drivers)?	Contain first — remove the emergency before deciding anything
Will the business still run on this logic in 10 years?	Rewrite, parity-tested, in slices
Is the codebase huge, the budget small, and the platform dead?	Convert — as a bridge with a refactoring plan, not an endpoint
Is the pain concentrated in access (UI/integration/reporting), not the core?	Wrap — with a written expiry date
Is the application mostly habit?	Retire it — the cheapest migration is an export and an archive

Two patterns from the field, offered as priors: the total cost ranking over a 10-year horizon
is usually retire < contain < rewrite < wrap-forever < convert-then-rewrite-anyway. And the
single best predictor of migration success is not the strategy chosen — it is whether the
current system's behavior was captured as tests before anyone wrote new code.

Our assessment prices all applicable paths for your specific system — including
the ones we would not be hired for. That is deliberate: a roadmap you can sanity-check against
a vendor's pitch is worth more than any pitch.

Lotus Notes/Domino to .NET: what actually breaks

Hayim Romanovsky — Fri, 06 Nov 2026 07:37:31 +0000

Originally published at migrationparity.com.

I recently took a quality-management workflow application — roughly 9,000 documents accumulated
over two decades in a single NSF — from Lotus Notes/Domino to .NET 8 with a SQL backend. The
export part that every migration tool advertises took days. The part that took months was
everything the brochures do not mention.

This is the list I wish I had at the start: the six places a Notes migration actually breaks,
and what to do about each.

1. There is no schema — there are 25 years of schemas

A Notes document is a bag of items. The form defines what new documents get; every old
document keeps whatever fields it was saved with, under whichever version of the form existed
that year. In practice our "one form" was a geological record: fields that appear only in
documents from 2003–2007, fields renamed twice, fields whose type quietly changed from text to
multi-value.

What works: inventory the documents, not the form. Scan every document's item names and
types, cluster by generation, and design the SQL schema against the union — with explicit
migration rules per generation. Any mapping built from the current form design alone will drop
data silently.

2. Rich text is a container format wearing a text costume

Notes rich-text fields hold formatted text — plus embedded images, file attachments, OLE
objects (that spreadsheet someone pasted in 2009), collapsible sections, tables, and doc links
pointing at other documents in other databases. A naive HTML export flattens this into soup;
a text export just deletes it.

What works: treat rich text as a document tree. Convert formatting to sane HTML, extract
attachments and images to real storage with references, and translate doc links into links in
the new system — which means migrating link targets first or maintaining a UNID-to-new-ID
map for the whole estate. Budget real time here: rich-text fidelity was our single largest
line item.

3. Reader fields: the security model that migrations silently drop

Reader and author fields make documents invisible to unauthorized users — enforced by the
database engine itself. Confidential HR cases, supplier complaints, audit findings: in Notes,
users literally cannot see documents they are not named in. Export the documents to SQL,
build a pretty new UI, forget this layer — and on day one every user can read everything.
This is the most dangerous failure mode in Notes migration, because nothing looks broken.

What works: extract the effective access model — ACLs, roles, groups (expanded via the
directory), reader/author items per document — and reproduce it as row-level security in the
new system. Then test it as identities: log in as a sampled set of real users on both systems
and diff what each can see.

4. Roles fan out into hundreds of decisions

The application had a handful of ACL roles — approver, coordinator, quality, admin. Innocent
looking. But roles are referenced in form formulas, view selection formulas, hide-when clauses,
agent logic and workflow-state transitions. Mapped onto the new system's authorization model,
our modest role list exploded into hundreds of individual mapping decisions — who may press
this button in this state, who sees this view, who gets this escalation. It became the go-live
blocker; not because any single decision was hard, but because each one needed a business owner
to say yes.

What works: surface this early. Machine-extract every role reference, generate the decision
matrix in week one, and put a named human owner on it. It is the longest-lead item in the whole
project precisely because it is not a technical task.

5. Views and agents are the application

Users do not experience "documents" — they experience views: selection formulas, categorized
columns, computed values, twisties. And the workflow does not run itself — scheduled agents
reassign, notify, escalate. Some agents encode the real process; some have been failing
silently for a decade and the business adapted around the failure (which means reviving them
faithfully would break the current process!).

What works: rebuild views as queries against the new schema, with the parity discipline of
diffing view contents between systems on frozen data. For agents: inventory, then observe —
which ones actually fired last year, what they changed — before deciding which to reproduce,
which to redesign, and which to let die officially.

6. Cutover is a coexistence problem, not an event

Nine thousand documents of living workflow cannot stop for a migration weekend. The old and new
systems overlap: new cases open in .NET while old cases finish their lifecycle in Notes, or
historical documents remain readable in Notes long after writes moved.

What works: plan the bridge deliberately. COM interop against the Notes client (or Domino's
HTTP interfaces) lets the new system read live Notes data during the transition — clunky but
effective; keep the bridge component registered and documented until the last dependency is
gone, then remove it on purpose rather than leaving it as a permanent mystery service. Retire
Domino to read-only, then to archive, only after a full business cycle proves nothing still
reaches for it.

The shape of the effort

For our ~9,000-document application, the honest cost breakdown was approximately:

Workstream	Share of effort
Rich text, attachments, doc links	~30%
Security model + role mapping decisions	~25%
Schema archaeology & document migration	~20%
Views, agents, workflow reproduction	~15%
Coexistence bridge & cutover	~10%

Note what is not on the list: "exporting the documents". That part is a solved problem. The
project is everything around it — which is why per-document licensing of export tools tells
you almost nothing about what a Notes migration will cost.

This experience is packaged as our
Lotus Notes / Domino migration service. If your
estate is bigger than one database — most are — start with the assessment: usage measurement
across databases typically retires half the estate before anything is migrated at all.

Harbour in 2026: the first stable release in 15 years, and what it means for your Clipper app

Hayim Romanovsky — Fri, 06 Nov 2026 07:37:29 +0000

Originally published at migrationparity.com.

In July 2026, the Harbour project shipped version 3.2.0 —
its first stable release since 3.0.0 in 2011. Fifteen years between stable tags is the
kind of fact that sounds like a punchline about dead software. It is the opposite: the 3.2
branch has been alive, maintained and quietly running production systems that whole time —
as an eternal "development snapshot". What changed in July is not the code. It is the label,
and labels matter more than engineers like to admit.

If your company still runs a Clipper-era application, this release is the best news your
legacy stack has had in a decade. Here is why — and where the enthusiasm should stop.

What Harbour is, in one paragraph

Harbour is the open-source successor of the Clipper language: a compiler that takes the same
PRG code Clipper took, compiles it to C, and produces native executables for modern
platforms — 32- and 64-bit Windows, Linux, and more. It reads and writes the same DBF
tables and NTX/CDX indexes through replaceable database drivers, so a ported application
works on the same live data files as the original EXE. The classic Clipper extension
libraries have Harbour counterparts, the build tool (hbmk2) turns the old make ritual into
a one-line command, and the language has grown modern conveniences (classes, hash tables,
multithreading) without abandoning dialect compatibility. Commercial forks (xHarbour and
friends) exist alongside it; Harbour is the community mainline.

Why a version label matters to your business

For engineers, "we've run the dev snapshot in production for years" is normal. For everyone
who signs things, it is a problem:

Procurement and audits. "Our platform is a nightly build of an open-source project" reads very differently from "our platform is Harbour 3.2.0, released 2026". Auditors, insurers and customers' vendor-security questionnaires want a version, a date, a tag.
Reproducible builds. A stable tag means you can pin the exact compiler, archive it, and rebuild the same binary in five years — the foundation of every serious containment plan for a legacy system.
Succession. The developer who eventually inherits your system can download the same documented release, not "the snapshot from the USB stick Misha left".
Signal. A project that cuts a stable release after 15 years is telling you it intends to be here for the next 15. For a language whose commercial vendor died in the 1990s, that continuity signal is the entire value proposition.

What a Harbour port actually looks like

We have ported a production Clipper-family utility — a decades-old codebase over live
DBF/CDX data — to Harbour, building both 32- and 64-bit native Windows executables and
verifying them against the same server-hosted tables the original used. The honest
experience, in proportions:

Most of the code just recompiles. Core xBase logic — database access, index expressions, business rules, SET RELATION chains — carries over untouched. This is what makes a port a containment project rather than a rewrite.
The work concentrates at the edges. Screen handling beyond plain @SAY/GET, printer tricks that assumed an LPT port, inline C or assembler, and third-party .LIB files are where the effort lives. Most classic libraries have Harbour equivalents; truly exotic ones need small shims.
The build system is a gift. hbmk2 app.prg replaces the RTLINK incantations, and the same project file builds x86 and x64 from one source tree.
64-bit is not vanity. It means no 16-bit emulation anywhere in the chain, first-class behavior on current Windows, and — where the data layer is client/server (for example an Advantage-backed system) — access to modern 64-bit client stacks, which in our benchmarking were meaningfully faster than their 32-bit siblings.

A port of this kind is measured in weeks, not quarters — a fraction of any migration —
and at the end the application is the same application: same keystrokes, same data files,
same muscle memory on the plant floor. That sameness is precisely the point. Behavior
preserved by recompilation is behavior you do not have to reverse-engineer later; the
ported binary becomes a scriptable reference implementation for the
parity testing that a future real
migration will need.

What Harbour does not fix

Containment is a strategy, not a destination, and it is worth being blunt about the limits:

It is still xBase. The pool of developers who can extend the system does not grow because the compiler got younger.
It is still DBF (unless you move the data layer to a server backend) — the 2 GB per-table ceiling, the shared-file locking model and the index-corruption folklore come along for the ride.
The UI stays the UI. Your veterans will love that; your new hires and your customers will not. Web access, integrations, audit trails — none of that appears by recompiling.
The clock keeps ticking. A Harbour port removes the platform emergency (16-bit executables, dying hardware, unsupported OSes). The organizational emergency — one person who understands the system, zero tests, undocumented rules — is untouched.

That is why we treat Harbour as step one of two: contain now, on your timeline, cheaply —
then decide between keeping the contained system, wrapping it, or a parity-tested
migration, with the pressure off. The full decision framework is in
rewrite vs convert vs wrap.

Is a port right for your system?

Signals that say yes:

The application still runs the business, and runs it well — the pain is the platform, not the logic.
You are one hardware failure away from an outage (the last DOS-capable PC, a fragile VM, an emulator nobody dares touch).
The source code substantially exists. (Partial loss is survivable; total loss changes the conversation.)
A full migration is desirable eventually but not fundable now.

Signals that say skip straight to migration: the business has outgrown the workflows
themselves, the data already needs to live in SQL for integration reasons, or compliance
requirements (audit trails, access control, encryption) can never be met by a shared-file
database no matter what compiles it.

With 3.2.0 stable, the port option finally comes with a version number your CFO can put in
a risk register. For a 30-year-old system, that is not a small thing.

Our Clipper/xBase practice runs exactly this
two-step: Harbour containment measured in weeks, then — if and when you choose — a
parity-tested migration. The fixed-price assessment tells you which step your system
actually needs first.

Migrating a Clipper/xBase app without losing 30 years of business rules

Hayim Romanovsky — Fri, 06 Nov 2026 07:31:04 +0000

Originally published at migrationparity.com.

Every failed xBase migration I have seen died the same death. Not from bad technology choices —
from a quiet assumption: "we know what the old system does."

Nobody knows what a 30-year-old Clipper application does. Not the company that owns it, not the
operators who use it eight hours a day, and not the developer who wrote it, even when he is
still around. The application is the specification. The PRG files are where the truth
lives, and a third of that truth was never intended: rounding artifacts that customers' invoices
have depended on since 1996, an index collation quirk that determines which duplicate wins, a
date-window trick from the Y2K panic that still silently reclassifies years.

If you rewrite from a requirements document, you are rewriting from fiction. Here is the
methodology that works instead.

Step 0: get the old system somewhere you can run it on demand

You cannot test against a system you are afraid to touch. For DOS-era Clipper this often means
a containment step first: port the code to Harbour — the
open-source Clipper-compatible compiler, which shipped a fresh stable release in July 2026 —
so the same PRG code runs as a native Windows executable against the same DBF/NTX/CDX files.
We have done this with production utilities: most code recompiles; the work concentrates in
screen handling, printing and the occasional inline C or assembler.

The port pays for itself twice. It ends the 16-bit hardware emergency immediately, and it turns
the legacy system into something you can drive from scripts — which is everything for what
comes next.

Step 1: build the parity harness before the new system

A parity harness is three parts:

Frozen inputs. A copy of production data at a known point, plus a library of scripted transactions: post an order, receive goods, close a month. In xBase systems the "API" is often the database itself, which is convenient — writing DBF rows is driving the app.
Captured outputs. Everything the business actually consumes: report files, printed invoices redirected to text, month-end totals, the resulting state of every table. Text-mode legacy output is a gift here — it diffs perfectly.
A differ with a memory. Something that runs both systems on the same inputs and produces a human-readable list of differences — and remembers which differences were reviewed and accepted, so the signal never drowns in known noise.

The critical rule: capture behavior, not intentions. If the old system computes 12% of 1850
as 221.99 because of how Clipper's numeric type rounds through an intermediate, then 221.99 is
the correct answer. Your customers have 30 years of paper that says so. You can fix the bug
later — deliberately, with sign-off — but on migration day, faithful means identical.

Step 2: mine the places where rules hide

Business logic in xBase systems does not live only in the obvious calculation routines. The
parity harness must cover the habitats:

Index expressions. UPPER(SUBSTR(CUSTID,1,3)) + DTOS(DUEDATE) is not plumbing — it is the rule for how work is sequenced. Conditional indexes (FOR !PAID) are business filters.
Collation. Index order under a DOS codepage differs from ANSI order for every character beyond ASCII. Reports "sorted by name" can legitimately differ between old and new — decide which truth wins before users find out.
Deleted records. SET DELETED OFF code paths see flagged-deleted rows. Some reports in the wild depend on that accidentally, and have for decades.
Empty vs zero. xBase distinguishes an empty numeric field from 0 in ways that SQL NULL maps onto imperfectly. Aggregates over "empty" columns are a classic parity breaker.
Date arithmetic. Two-digit-year windows, DATE()+30 month-end assumptions, 1900/2000 pivots patched during Y2K by someone in a hurry.
The codepage layer. If the data is cp862 Hebrew or cp866 Cyrillic (usually with no codepage byte set in the DBF header — DOS apps rarely recorded one), then every comparison, sort and print step embeds an encoding assumption. Get it wrong and parity fails everywhere at once, uninformatively.

The assessment phase is largely about finding these habitats in your codebase and making sure
the harness exercises them.

Step 3: migrate in slices, gate each slice on the diff

With the harness in place, the migration itself becomes almost boring — which is the goal:

Move the data to SQL with its own verification (row counts, per-column checksums, codepage round-trips). Keep the pipeline repeatable; run it nightly.
Rebuild one module at a time on the new stack, starting with read-only reports.
Run both systems on the frozen inputs. Diff. Fix. Repeat until the diff is empty or every remaining line has a written, signed-off explanation.
Cut that module over. The legacy system remains the system of record for everything else.

"Done" stops being a feeling and becomes a number: zero unexplained differences across N
scenarios covering M% of last year's transaction volume. Management can see the number move
weekly. When someone asks "is the new system ready?", the answer is a report, not a promise.

What this costs — and what it saves

Building the harness is typically 15–25% of the migration budget, spent before any new-system
code exists. Teams under time pressure are tempted to skip it. What they buy instead is the
expensive kind of testing: production users discovering differences one angry phone call at a
time, for a year.

The harness also outlives the migration. It becomes the regression suite for the new system —
the first automated tests this application has had in its entire multi-decade life.

The uncomfortable summary

The old system is the only complete specification of itself. Treat it as the oracle.
Preserve bugs first, fix them second — separately, visibly, with sign-off.
Contain the platform emergency (Harbour) so you can migrate calmly instead of heroically.
Let a diff decide when you are done. Opinions, including yours and mine, do not count.

This is the methodology behind our Clipper/xBase migration service
and, with different tooling, our FoxPro work. If you want the
short version applied to your system: that is what the assessment is for.

SAP Advantage Database Server after EOL: your realistic options in 2026

Hayim Romanovsky — Fri, 06 Nov 2026 07:31:01 +0000

Originally published at migrationparity.com.

Advantage Database Server was the best xBase-family product most people never heard of: a real
client/server engine over DBF and ADT tables, with transactions, server-side indexes and none
of the file-share corruption folklore that haunts Clipper and FoxPro deployments. Vertical
software vendors loved it — point of sale, logistics, medical, manufacturing — which is why
thousands of businesses run it today without knowing it, under an application bought long ago
from a vendor that may no longer exist.

Then SAP, which inherited Advantage through Sybase, walked away: sales ended at the close of
2019, maintenance wound down after, and version 12 is the end of the line. No successor, no
migration tool, no plan. If ADS is under your application, you inherited an orphan.

Here are the four realistic paths, in increasing order of effort.

Option 1: freeze it — properly

Running unsupported software is a risk posture, not automatically a mistake. ADS 11/12 binaries
are stable, and a well-contained installation can serve for years. "Well-contained" is the load-
bearing phrase:

Isolate and pin. A dedicated VM, an OS version you control, snapshots before any patching. Do not let the ADS host ride the general update train.
Guard the installers and licenses. The downloads are gone from official channels. The setup EXEs and license keys you have are irreplaceable artifacts — vault them.
Script verified backups and actually drill restores. ADS supports online backup; use it, and prove quarterly that the restore produces a working server.
Mind the 32-bit client rot. Most deployed ADS clients are 32-bit ODBC/OLE DB stacks. Each Windows release tolerates them a little less; keep a documented, tested client install procedure while it still works.
One arbiter per table, always. ADS owns locking and index maintenance for its tables. The classic self-inflicted outage is a "quick export" or local xBase tool opening the same DBF/CDX files directly while the server is live — that is how indexes corrupt. All access goes through the server, no exceptions, ever.

Freezing buys time. It does not buy a future — the client-driver problem alone guarantees this
posture has an expiry date.

Option 2: replace the server, keep the clients

Because the Advantage wire protocol is stable and well understood, open-source reimplementations
of the server side exist — the OpenADS project being the visible one. The proposition: your
untouched client applications keep connecting exactly as before, while the server under them
becomes maintained, license-free software that can even move the storage onto modern backends.

We benchmarked this path against a real SAP ADS server on production-shaped workloads before
recommending it to anyone, and the honest findings are:

It is not a speed upgrade. Mature ADS is fast; the replacement is comparable, not dramatically better. If raw throughput is your pain, this is not your fix.
(A side note from the same benchmarks: simply moving from the 32-bit ace32 client stack to 64-bit ace64 gave us roughly 1.4–1.7× on client-side throughput — if you are staying on ADS a while and your app can load the 64-bit client, that is free performance.)
The value is longevity, not latency. Maintained code, no license cliff, multi-backend storage options, and an exit from the abandoned-binary problem.
Feature coverage is the gating question. Which ADS features does your application actually use — ADT-specific types, stored procedures, replication, DD security? Compatibility must be tested against a copy of your data with your client binaries, not assumed from a feature matrix.

This option shines when the client application cannot change (vendor gone, source lost) but the
business needs the platform to stop being end-of-life.

Option 3: migrate the data out from under it

ADS data is ultimately DBF (or ADT, which is documented enough to extract). That means the full
DBF migration discipline applies: per-column codepages, memo
files, deleted-row policy, index expressions re-implemented as SQL constraints — plus the
ADS-specific layer of data-dictionary rules, triggers and stored procedures that live on the
server.

The destination is a mainstream engine (SQL Server, PostgreSQL) and a rebuilt or repointed
client. This is the permanent fix, and the only option that improves your position every year
after it ships. It is also the only option that requires touching the application — which is
why it pairs naturally with a planned modernization rather than a panic.

Option 4: retire the application

Said rarely by consultants, so let me say it: some ADS-backed applications no longer earn their
keep. If the vertical app overlaps 80% with your current ERP and the remaining 20% is habit,
the cheapest migration is an export, an archive, and a decommissioning party. The assessment
should always price this path too — if only to make the other numbers honest.

Choosing

Your situation	Sane path
App works, vendor gone, horizon under ~3 years	Freeze properly (option 1)
App must live longer, clients cannot change	Server replacement (option 2), tested on your data
App is yours to change, or modernization is due anyway	Migrate the data out (option 3)
App is mostly habit	Retire (option 4)

Two of these four paths require no changes to your application at all — which surprises most
owners, who assumed EOL meant an immediate, total rewrite. It does not. It means you now need
a deliberate strategy instead of a support contract.

We run this exact decision process, with your data and your client binaries, as a fixed-price
assessment. The output is the table above with your
numbers in it.