Lotus Notes & Domino: out of the NSF, with the rules intact
A Notes application is documents, forms, views, agents and a security model braided together. We unbraid them into a modern stack — without flattening the documents or leaking the secrets.
What actually breaks in Notes migrations
Every Notes-to-anything vendor demo shows documents flowing into the new system. What the demo does not show:
- Schema-less reality. A form defines what new documents look like — old documents keep whatever fields they were saved with across 25 years of form versions. A fixed target schema meets thousands of documents that predate it.
- Rich text. Embedded images, attachments, OLE-embedded spreadsheets, collapsible sections, doc links pointing at other databases — naive HTML conversion loses structure, naive text export loses everything.
- Reader/author fields. Document-level visibility enforced by the database engine. Migrate the data without the access model and confidential records become public on day one.
- Views are logic. Selection formulas, categorized columns and @-formula computed values are business rules users experience as "the application". They must be reproduced, not screenshotted.
- Agents and workflow. Scheduled LotusScript that reassigns, notifies, escalates. Some of it is the process; some has been silently failing since 2013. Telling one from the other is assessment work.
- Roles. ACL roles referenced in forms, views and formulas fan out into hundreds of per-user, per-state decisions that must be mapped onto the new system's authorization model explicitly.
We wrote up the field version of this list — from a real ~9,000-document workflow migration — in Lotus Notes/Domino to .NET: what actually breaks.
Our approach
-
Estate assessment
Databases inventoried and usage-measured; the living core separated from archives and clones. Per-application: forms, views, agents, ACLs, roles, external dependencies, and a migrate/archive/retire verdict with effort attached.
-
Model extraction
For applications being rebuilt: the implicit document model is made explicit — field-by-field mapping into a relational schema, rich text conversion rules, response hierarchies as real relations, reader/author fields as row-level security policies.
-
Migration with per-document verification
Scripted export pipelines (not one-off wizard runs) move documents, attachments and metadata; every document is checked against the source — counts, field coverage, attachment integrity, access-control equivalence for sampled identities.
-
Coexistence, then retirement
The new .NET application takes over writes; Domino stays as a readable reference until a full business cycle passes. Then it becomes a static, searchable archive — and the license line disappears.
Frequently asked questions
Domino is still sold and supported by HCL. Why migrate?
True — Domino is not dead software, and if it serves you well, keeping it is legitimate. Companies migrate for other reasons: license cost concentrated on a shrinking user base, no remaining Notes developers on staff or on the market, integration friction with everything modern, and the risk of one platform holding decades of documents hostage. Our job is the migration being safe, not talking you into it — the assessment sometimes concludes "stay, but archive properly".
What is so hard about getting documents out of an NSF?
Export is easy; fidelity is hard. Notes documents are schema-less bags of items — two documents in one form can carry different fields. Rich text holds embedded images, attachments, OLE objects, doc links and section formatting that naive exports flatten into mush. Response hierarchies, profile documents and computed fields add structure that CSV simply cannot carry. We map all of it into an explicit relational model, with per-document verification against the source.
What happens to reader and author fields — our document-level security?
This is the part most migrations get dangerously wrong. In Notes, reader fields make documents invisible to unauthorized users at the database level; a migration that ignores them publishes confidential records to everyone with app access. We extract the effective access rules (ACLs, roles, reader/author items, group expansions) and reproduce them as row-level authorization in the new system — then test with real user identities from both sides.
We have hundreds of databases and agents. Do they all need rebuilding?
Almost never. Notes environments accumulate: in practice a large share of databases are stale archives, template clones and abandoned experiments. The assessment measures actual usage, splits the estate into migrate / archive / retire, and inventories which agents encode real business logic versus housekeeping. You pay for rebuilding the living core, not the graveyard.
Can Domino stay read-only during and after the migration?
Yes, and it usually should. We migrate write workflows first, keep the Domino application readable as a frozen reference (or export it into a searchable archive), and retire the server only after a full business cycle proves nothing still depends on it. Interoperability bridges — including COM-based access to live Notes data during the transition — let the old and new systems coexist for as long as the cutover needs.
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.