Domino to Microsoft 365 Migration

Avoid unnecessary PST staging

When Microsoft 365 is the final destination, creating PST files for every source mailbox can introduce an additional storage, naming, transport, and import stage. A direct Domino-to-Microsoft-365 workflow can simplify the migration path when the source and destination are both available.

Keep source-to-target mapping explicit

Map each Domino mailbox or NSF source to the correct Microsoft 365 destination. This reduces the ambiguity that can occur when multiple intermediate PST files are created and later imported by a separate process.

Use filters before data enters the target

If policy allows, migrate only the historical period, folders, or mailbox content that the business requires. Filtering at migration time can reduce unnecessary data transfer and target storage.

Use incremental migration for staged projects

Move the bulk of mailbox data before final cutover, then use supported incremental passes to capture new or updated items. This can reduce the amount of data that must move during the final business-impact window.

Review logs and exceptions centrally

Migration logs help administrators identify completed, failed, skipped, or exception items without relying only on user reports after cutover.

Keep a separate path for damaged NSF files

If a source NSF is corrupt or inaccessible, do not force it into the normal production batch. Route it through NSF recovery, validate the recovered data, and then include the validated output in the migration project.

Emails and attachments

Migrate supported messages and attachments together with readable sender, recipient, subject, date, and related message properties from the Domino NSF source.

Contacts

Include supported contact information where it is part of the migration scope. Verify representative contacts in the target rather than assuming email completion covers all user data.

Calendars and appointments

Move supported calendar and appointment data and validate representative meetings, recurring events, and date/time behavior in Microsoft 365.

Tasks, notes, and journals

Current EdbMails NSF migration documentation lists support for additional mailbox-item types such as tasks, notes, and journals in applicable NSF workflows.

Folder hierarchy

Preserve the usable source folder structure so users can find migrated data in a familiar organization and administrators can compare source and target during validation.

Multiple Domino mailboxes

EdbMails supports multi-NSF and batch-oriented migration workflows. For larger projects, use migration waves based on data volume, business priority, and support capacity.

User mailboxes

Map active Domino users to their corresponding licensed Microsoft 365 mailboxes and verify destination identity, sign-in, primary SMTP address, and target mailbox readiness before migration.

Shared mailboxes

Current EdbMails NSF migration documentation includes shared mailbox destinations in applicable Microsoft 365 workflows. Use shared mailboxes for business requirements that fit Microsoft's current licensing and access model.

Public folders

EdbMails also documents migration of supported NSF mail items or folders to Microsoft 365 public folders in applicable workflows. Treat public-folder migration as a planned destination choice rather than a default for every shared source.

Archive or inactive-user strategy

Decide whether departed-user data should move to a licensed mailbox, shared mailbox, archive, PST, or another approved retention destination before the migration wave begins.

Multiple tenants or domains

If the Domino migration is part of a larger consolidation project, document the exact Microsoft 365 tenant and domain for each target mailbox and keep the mapping consistent across all migration passes.

Do not use one target type for every source by default

The correct Microsoft 365 destination depends on ownership, licensing, collaboration needs, retention policy, and whether the source represents an individual, shared function, public data set, or historical archive.

Mapping and folder checks

Confirm that the intended source mailbox reached the correct target and that important source folders appear in the expected destination location.

Content-level checks

Open representative messages and attachments from different dates and folders. Validate contacts, calendars, tasks, notes, or journals if those item types are in scope.

Logs, access, and business acceptance

Review migration logs, confirm Microsoft 365 sign-in and mail flow, document exceptions, and obtain user or business-owner acceptance before retiring the Domino source.

Lotus Notes to Microsoft 365

Use the local/offline NSF guide when individual NSF files are the source rather than a Domino Server migration project.

Lotus Notes to Microsoft 365

NSF Migration Tool

Use the generic product hub for NSF migration features, destinations, mapping, filtering, and migration options.

NSF Migration Tool

Lotus Notes Migration Project Plan

Use the enterprise planning page for discovery, pilot design, migration waves, cutover, and validation.

View Migration Project Plan

Lotus Notes Migration Challenges

Review common NSF discovery, mapping, performance, recovery, coexistence, and validation risks before production migration.

Review Migration Challenges

NSF Recovery Tool

Recover supported mailbox data from damaged or inaccessible NSF files before including them in the migration wave.

Recover NSF Data

Free NSF Viewer

Inspect supported NSF mailbox content during source discovery and before mapping it to Microsoft 365.

Open NSF Viewer