There's a category of migration that other consultancies quietly decline, and Lotus Notes to Office 365 migration sits near the top of it. We just wrapped the mail phase of one: a 2,800-seat public-sector organization on Domino 8.5.3, running Notes mail since the late nineties, with 190 Notes applications of varying decrepitude and a user population that had heard "we're finally leaving Notes" three times before and believed none of them. Mail, calendar, and directory are done — zero data loss, verified — and the application long tail is now a project of its own. These are the field notes.
The first thing to understand about a Domino migration is that "email migration" is the wrong mental model. Notes is not an email system; it's an application platform that happens to include mail. The mail file is an NSF database. The expense-approval workflow from 2004 is also an NSF database. The two problems look identical in a file listing and have almost nothing in common as migration work. Every failed Notes migration we've been called into post-mortem made the same mistake: they scoped the mail and discovered the applications after the business case was signed.
So we scope it as three projects wearing one budget: mail and calendar (predictable, tool-driven), directory and coexistence (fiddly, invisible when done right), and applications (the actual long pole, and the reason the Domino servers will outlive the mail cutover by a year). Here's each.
Mail and calendar: what survives the NSF, and what doesn't
The good news is that mail body fidelity out of NSF is a solved problem — the specialist tools (more on tooling below) convert Notes rich text to HTML competently, preserve attachments, and keep folder structures. The honest news is the exception list, which we now hand clients on day one:
- Doclinks. Notes messages are full of doclinks — those little yellow page icons linking to documents in other Notes databases. Tools convert them to Notes-protocol URLs (
notes://server/database) or plain text. They only resolve if the Notes client stays installed and the target database still exists. For anything pointing at databases you're retiring, they're dead. We report doclink counts per mailbox during assessment so nobody is surprised. - Encrypted mail. Messages encrypted with the user's Notes ID cannot be read by any migration tool — that's the point of encryption. The choices are: have users decrypt them in-place pre-migration (some tools automate a decrypt pass with the user's ID file), or leave them behind with a documented exception. Our client had 40,000-odd encrypted items concentrated in about 60 mailboxes — legal and HR, naturally. We ran the assisted decrypt for those users; everyone else's handful stayed behind by signed-off policy.
- Calendar recurrence. Notes supports custom recurrence patterns Exchange simply cannot express — "every third Thursday except when it rains" scheduling. The tools translate what they can and convert the rest to individual appointments or drop the exceptions. Repeating meetings rescheduled many times are the fidelity minefield. Our standing advice: migrate calendars fully, then have executive assistants re-create the twenty most business-critical recurring meetings fresh in Outlook post-cutover. Twenty minutes of EA time beats a quarter of "the board meeting vanished" tickets.
- Personal address books and archives.
names.nsfand local archive NSFs live on workstations, not the Domino server. If the scope says "server data," say loudly that local archives need a separate workstation-side collection pass — we swept them with a login script and staged them for a second migration wave.
Throughput planning looks like any other Office 365 onboarding: we sustained roughly 350 mailboxes a week in steady state, gated less by the tools than by Domino server I/O on 2009-era hardware and by the client's change-management appetite. Across the program: 2,800 mailboxes, about 4.1 TB of NSF mail, and a verification report per mailbox — item counts by folder, source versus target — because "zero data loss" is a claim you should have to prove, especially to a government records officer.
Directory synchronization and the coexistence months
Nobody cutover-migrates 2,800 seats in a weekend, which means for several months you run two mail systems that must behave as one. That rests on two legs.
First, identity. Notes-era Active Directories are frequently half-populated — this one had AD accounts for login but mail attributes that lived entirely in the Domino Directory. Before any coexistence tool can work, every user needs a clean AD object with correct mail attributes, because Azure AD Connect synchronizes AD, not Domino, into Office 365. We built a reconciliation pass: export the Domino Directory, match on employee ID (not display name — Notes display names are an art form; "John Smith/Sales/ACME" matches nothing), and stamp AD with the SMTP addresses, aliases, and forwarding data. That six-week data-quality slog was the least glamorous and single most valuable work in the program.
Second, mail routing and lookups during coexistence. Migrated users get mail forwarded from their Notes person document; unmigrated users are represented in Exchange Online as mail contacts pointing back at Domino; SMTP namespace stays shared. The specialist coexistence tools keep the two directories synchronized on a schedule so the GAL and the Domino Directory both show everybody, all the time. Calendar free/busy between Domino and Exchange is possible with the coexistence products, but it's the most fragile piece of the whole architecture — we set the expectation that cross-system free/busy is best-effort during the window, and then we compress the window. Short coexistence beats clever coexistence. Migrating in departmental waves so that teams who schedule together move together eliminated most cross-system calendaring pain by design rather than by engineering.
One war story for the file: our first pilot weekend, forwarding from Domino to Office 365 worked flawlessly in testing and failed for exactly one pilot user in production. Four hours of tracing later — a second, forgotten person document in a secondary Domino directory, with no forwarding address, matched first by router lookup order. The fix took ninety seconds. The lesson is permanent: Domino estates that have lived for twenty years contain duplicate and shadow directory entries, and your assessment scripts need to hunt them before the router finds them for you.
The applications: rebuild, retire, or SharePoint
Now the part that kills timelines. The client's 190 Notes applications broke down, after a real assessment (usage stats from the Domino logs, owner interviews, last-modified analysis), roughly like this:
| Disposition | Count | Notes |
|---|---|---|
| Retire outright | 96 | No opens in 12 months, or owner confirmed obsolete |
| Archive read-only | 41 | Records-retention holds; kept on a shrinking Domino farm or exported to PDF/CSV |
| Move to SharePoint Online | 38 | Document libraries, team discussion databases, simple form-and-view apps |
| Rebuild properly | 15 | Real workflow applications with logic worth keeping |
Half the estate retired with a signature — that's typical, and it's why the assessment pays for itself. The document-library-shaped databases map to SharePoint Online well enough, and tooling exists to move the content with metadata. The genuine workflow applications are the honest conversation: there is no magic converter that turns fifteen years of LotusScript into a modern app. Anyone who says otherwise is selling the demo. Those get rebuilt — some in SharePoint with workflow, some as small .NET applications, a couple absorbed into line-of-business systems that had overtaken them anyway — one at a time, prioritized by the business, on a roadmap that runs well past the mail cutover.
Which leads to the strategic point we make in every steering committee: decouple the mail cutover from application retirement. Mail can be done in two quarters. The application tail takes as long as it takes. Keeping 2,800 mail users hostage to a 2004 expense-workflow rewrite is how Notes migrations become five-year legends. Move the mail, shrink the Domino farm to an application-only footprint (fewer servers, fewer licenses, most of the savings), and burn the tail down separately.
Tooling: what we actually use
Honest tooling notes, since this is the most-asked question. The Notes migration market has real specialist products — Quest's Migrator for Notes to Exchange and Binary Tree's CMT suite are the ones we've used in anger — and they've spent a decade on exactly the ugly corners above: rich-text conversion, recurrence translation, ID-file-driven decryption, and Domino directory coexistence. For a complex estate with a long coexistence window, the specialist tooling earns its licensing cost in the directory-sync and calendar work alone; that's what carried this engagement.
We use BitTitan MigrationWiz constantly on other workloads — it's been our default for Exchange-to-Office-365 and Google Apps cutover projects, and it's the tool behind a large share of the 15,000-plus mailboxes we've moved — and it can serve smaller or simpler Notes mail moves where coexistence needs are modest. The selection question is not "which tool is best" but "how long must the two systems pretend to be one, and how ugly is the calendar data." Short coexistence and clean data widen your options; a long window with heavy cross-system scheduling pushes you to the specialist suites. And whatever you pick: pilot with fifty real mailboxes including the worst calendar offenders you can find, and demand per-mailbox verification reporting. Migration tools are judged on their exception handling, not their happy path.
If you're facing this
If your organization is still on Notes and Domino, you are not as stuck as the last three failed attempts made it feel — but the project is won or lost in the assessment, months before any mailbox moves. We've taken government and enterprise estates off Domino with verified zero data loss and a defensible plan for the application tail. Get in touch; we're happy to look at your Domino logs and tell you what your 190 databases really are.