What should a Lotus Notes migration project plan include?

A practical plan should cover source discovery, mailbox and NSF inventory, target readiness, identity and authentication, mailbox mapping, filters, pilot migration, batch scheduling, incremental passes, cutover, validation, rollback considerations, user communication, and post-migration support.

Should I migrate all Lotus Notes users at once?

Not necessarily. For most organizations, a controlled pilot followed by staged batches is easier to validate and troubleshoot than moving every mailbox in one operation. Batch size should reflect mailbox volume, bandwidth, support capacity, and the migration window.

Does EdbMails support incremental NSF migration?

Yes. Current EdbMails NSF migration pages describe incremental migration for repeat runs from the same migration computer to the same target, transferring new or updated items while avoiding duplicate migration of previously transferred items.

Can EdbMails automatically map NSF mailboxes to Microsoft 365?

Yes. Current EdbMails NSF to Microsoft 365 documentation describes automatic mailbox and folder mapping, with an option to map mailboxes manually when required.

Can EdbMails migrate multiple NSF files?

Yes. EdbMails' current NSF migration pages describe loading and processing multiple offline NSF files, including batch-oriented workflows.

What should be included in an NSF migration pilot?

Choose a small but representative group: a normal user, a large mailbox, users with calendars and contacts, a mailbox with custom folders, and any higher-risk archive or special-case mailbox. Validate folder structure, representative items, attachments, contacts, calendars, logs, and target usability before expanding the rollout.

How should I plan the final cutover from Lotus Notes to Microsoft 365?

Define the last source-change window, final incremental migration, mail-flow or DNS changes where applicable, user sign-in timing, support coverage, and a clear validation checklist. The exact cutover sequence depends on the organization's Notes/Domino architecture and target mail-flow design.

Does mailbox migration also migrate custom Lotus Notes applications?

No assumption should be made that a mailbox migration recreates custom Notes applications. Custom Domino applications can contain forms, views, workflows, code, and business logic that need a separate application-assessment and modernization plan.

What should be validated after Lotus Notes migration?

Check mailbox mapping, folder hierarchy, representative messages, attachments, contacts, calendars, tasks or other required items, target item counts where meaningful, migration logs, user access, and any business-critical folders. Keep the source data until the migration has been accepted.

How can I reduce migration risk?

Preserve source backups, inventory the environment, resolve identity and target-mailbox issues before migration, run a representative pilot, migrate in controlled batches, use incremental passes where supported, monitor logs, keep a rollback path, and avoid decommissioning the source before validation.

Reseller
Products
EdbMails

All-in-one Recovery and Migration
- EDB Recovery and Migration
- OST, PST, MBOX, NSF, EML, MSG
- Office 365, Exchange Migration
- SharePoint, OneDrive & Teams
- Google Workspace Migration
- IMAP Migration
- Duplicate Remover
- EdbMails Data Recovery
- Backup Solutions
All Products
EDB Recovery and Migration

EdbMails lets you recover corrupted, damaged, and offline Exchange EDB files, convert EDB mailboxes to PST format, and directly migrate mailbox data to Office 365 and live Exchange Server.

EDB to PST

Recover corrupted, damaged, offline EDB files and convert Exchange EDB mailboxes to PST file format

Public Folder to Exchange

Migrate public folders from an Exchange offline EDB file to live Exchange Server

EDB to Live Exchange Migration

Directly migrate offline Exchange database (EDB) files to live Exchange server

Archive Mailbox to Office 365

Migrate archive mailboxes from offline EDB files directly to Office 365

EDB to Office 365 Migration

Directly migrate offline Exchange database (EDB) files to Office 365

Public Folder to Office 365

Migrate public folders from an offline Exchange EDB file to Office 365

OST, PST, MBOX, NSF, EML, MSG Export and Migration

EdbMails lets you to recover OST and PST files, export OST, PST, MBOX, NSF, EML, and MSG files to PST files, and directly migrate OST, PST, MBOX, and NSF mailbox data to Office 365 and live Exchange Server.

OST Recovery and Migration

Recover offline OST files, convert OST to PST, and migrate OST to Office 365 and Exchange Server

PST Recovery and Migration

Recover Outlook PST files , Export PST to PST, migrate PST to Office 365 and Exchange Server

MBOX Export and Migration

Export MBOX to PST, migrate MBOX to Office 365 and Exchange Server

NSF Export and Migration

Export NSF to PST, migrate NSF to Office 365 and Exchange Server

EML to PST Export

Convert EML files to Outlook PST files

PST to MSG Export

Convert Outlook PST file to MSG file format

MSG to PST Export

Export MSG files to Outlook PST files

Office 365, Exchange Migration

EdbMails lets you securely migrate mailboxes across Microsoft 365, Exchange, Google Workspace (G Suite), and IMAP-supported servers such as Outlook, Gmail, Zimbra, Zoho Mail, and cPanel, ensuring zero downtime.

Office 365 Migration

Migrate between Office 365 tenants, Office 365 to Exchange, Office 365 to PST, PST files to Office 365.

Exchange Migration

Migrate between any Exchange Servers, Exchange to Office 365, Exchange to PST, PST files to Exchange.

Tenant to Tenant Migration

Migrate Mailboxes, Public Folders, Archive Mailboxes between Office 365 Tenants.

Exchange to Office 365

Migrate Mailboxes, Public Folders, Archive Mailboxes from live Exchange server to Office 365.

Office 365 to IMAP

Migrate Office 365 to IMAP, Office 365 to Gmail, Office 365 to Outlook, Office 365 to Zoho etc.

Exchange to IMAP

Migrate from live Exchange Server to IMAP servers such as Gmail, Outlook, and Zoho Mail.

Public Folder to Office 365

Migrate Public Folders between Office 365 tenants with complete folder hierarchy and mailbox data integrity.

Exchange to PST

Export live Exchange Server mailboxes, public folders, and archive mailboxes to Outlook PST files.

SharePoint, OneDrive & Microsoft Teams Migration

EdbMails lets you migrate SharePoint sites, OneDrive data, Microsoft Teams, teams, channels, chats, permissions, and documents between Microsoft 365 tenants while maintaining the existing folder structure and data integrity.

SharePoint Online Migration

Migrate documents, lists, files and folders from SharePoint sites.

OneDrive for Business Migration

Migrate documents, lists, files, folders, private chats from OneDrive.

Microsoft Teams Migration

Migrate Teams, chats, channels, documents, files and folders etc.

Google Workspace / G Suite Migration

EdbMails offers secure Google Workspace migration to Office 365, Exchange, or IMAP, and export to PST covering emails, contacts, calendars and tasks.

Google Workspace Migration

Migrate emails, calendars, contacts, tasks from Google Workspace to Google Workspace, office 365, Exchange and IMAP. Export to PST

Google Workspace to Office 365

Migrate emails, calendars, contacts, tasks from Google Workspace / G Suite to Office 365

Google Workspace to Exchange Server

Migrate emails, calendars, contacts, tasks from Google Workspace / G Suite to on-Premise Exchange Server

Google Workspace to IMAP

Migrate emails, calendars, contacts, tasks from Google Workspace / G Suite to IMAP, Outlook, Zimbra, Zoho etc.

Google Workspace to Google Workspace

Migrate emails, calendars, contacts, tasks between two Google Workspace / G Suite tenants

Google Workspace to PST

Export emails, calendars, contacts, tasks from Google Workspace / G Suite to Outlook PST files

IMAP Migration

EdbMails IMAP Migration tool lets you easily migrate emails from IMAP servers such as Outlook, Gmail, Zoho Mail, Zimbra, cPanel, and more. Supports IMAP to IMAP, Office 365, Exchange Server, PST, and bulk PST to IMAP migration.

IMAP Email Backup & Migration

Backup and migrate emails from IMAP servers to PST, Office 365, and On-Premises Exchange Server

IMAP to Office 365

Migrate emails, folders, and attachments from IMAP servers to Office 365

IMAP to Exchange

Migrate emails, folders, and attachments from IMAP servers to on-premises Exchange Server

IMAP to PST

Export emails, folders, and attachments from IMAP servers to Outlook PST files for backup

PST to IMAP

Migrate emails, folders, and attachments from bulk PST files to IMAP servers

Duplicate Remover

EdbMails Duplicate Remover lets you easily remove duplicate items from Office 365 and Exchange Server, and from IMAP, Outlook, Gmail, Zimbra, Zoho Mail, etc., ensuring a clean and organized mailbox.

Remove Duplicates

Easily clean up your Office 365, Exchange, Outlook and IMAP accounts by removing duplicate emails.

Remove Duplicates from Office 365

Remove duplicate emails, calendars, contacts, journal tasks, etc. from Office 365.

Remove Duplicates from Exchange Server

Remove duplicate emails, calendars, contacts, journal tasks, etc. from live Exchange Server.

Remove Duplicates from IMAP, Outlook

Remove duplicate emails, attachments from IMAP, Outlook, Gmail, Zimbra, Zoho Mail etc.

Exchange, SharePoint, OneDrive, Teams and Office 365 Backup

EdbMails enables secure, automated backup and recovery for Microsoft 365 services including Exchange Online, SharePoint, OneDrive, Teams, and Live Exchange Server with complete data protection and restore flexibility.

Office 365 Backup

Incremental, Granular, Encrypted and Compressed Office 365 Mailboxes Backup

Exchange Server Backup

Incremental, Granular, Encrypted and Compressed Exchange Mailboxes Backup

SharePoint, OneDrive & Teams Backup

Backup Online site collections, Team sites, Office 365 groups, all documents etc.

EdbMails Data Recovery

EdbMails Data Recovery Software lets you recover permanently deleted data, including photos, videos, documents, and archived files, from partitions on hard drives, SSDs, USB drives, SD cards, and external storage devices.

EdbMails Data Recovery

Recover and restore permanently deleted data from hard drives, SSDs, USB drives, SD cards, and etc.

Whitepaper

Request a Demo

Sign Up

Lotus Notes Migration Project Plan & Checklist

Plan each stage of your Lotus Notes migration before cutover

Build a structured Lotus Notes or HCL Notes migration plan covering source discovery, mailbox assessment, target preparation, user mapping, pilot migration, batch scheduling, incremental passes, final cutover, and post-migration validation. A defined plan helps IT teams organize the migration and identify exceptions before they affect the production move.

Just $89 Onwards

NSF to PST Converter NSF to Office 365 Migration NSF to Exchange Migration EDB to PST Converter MBOX to PST Converter OST to PST Converter

NSF to PST Converter Now on Azure Marketplace!

Product Menu

Build a practical Lotus Notes migration plan from discovery to validation

A successful Lotus Notes or HCL Notes migration is more than copying NSF mailbox data to a new platform. The project should define scope, inventory the source, prepare Microsoft 365 or Exchange, validate identity and mailbox mapping, run a representative pilot, migrate in controlled batches, perform incremental passes, execute cutover, and verify the result before the Notes environment is retired. This plan provides a practical framework that IT teams can adapt to small, medium, or enterprise migration projects.

Discover
Pilot
Cutover

Inventory users, NSF files, data types, and exceptions

Start with an inventory rather than assuming every Notes user has the same need. Record mailbox owners, NSF paths, mailbox sizes, archive files, date ranges, contacts, calendars, custom folders, shared data, security requirements, and mailboxes without active owners.

Run a representative migration pilot

Migrate a small set that represents the real environment: ordinary users, a larger mailbox, users with contacts and calendars, mailboxes with custom folders, and at least one higher-risk archive. Validate the target before increasing the migration volume.

Use staged batches and a controlled final cutover

Migrate historical data in advance where practical, use incremental passes for new or updated items, then complete the final synchronization, mail-flow transition, user sign-in, verification, and support activities during the agreed cutover window.

< Lotus Notes and HCL Notes NSF database file

Migration project phases at a glance

Separate assessment, preparation, migration, cutover, and validation instead of treating the project as one long transfer

Phase 1 — Discover and assess

Inventory Notes users, NSF mailboxes, archives, data volume, message age, contacts, calendars, custom folders, shared content, network paths, and exception cases. Identify what is in scope and what belongs to a separate custom-application modernization project.

Phase 2 — Prepare the destination

Create or validate target users and mailboxes, confirm licensing, authentication, administrative permissions, mailbox mapping rules, target folder strategy, and network capacity. Resolve identity mismatches before the migration window.

Phase 3 — Pilot, migrate, cut over, validate

Use a pilot to prove the workflow, migrate users in controlled waves, perform incremental passes where supported, complete the final cutover, and validate mailbox content and user access before retiring the source.

Phase 1: Discover the Lotus Notes environment

Good discovery prevents mailbox mapping, licensing, data-volume, and cutover surprises later

Identify active users and mailbox owners

Build a user list that distinguishes active employees, shared mailboxes, departed users, service accounts, executives, legal-hold mailboxes, and mailboxes that no longer need migration. A clean user inventory is the foundation for source-to-target mapping.

Inventory NSF files and archives

Record the primary NSF path, archive NSF files, approximate size, last-modified date, source system, and whether the file resides locally, on a file share, or in a Domino environment. Multiple NSF archives for one user should be identified before migration rather than discovered during cutover.

Understand mailbox content and date ranges

Determine whether the project requires all historical mail or only a defined date range. Check whether contacts, calendars, tasks, notes, journals, and attachments are in scope, because business users may consider these items just as important as email.

Find damaged or inaccessible NSF files early

Preview representative NSF files before scheduling the migration. Move corrupt or damaged databases into a separate NSF Recovery Tool workstream instead of discovering unreadable mailboxes during the production migration wave.

Identify custom Notes applications

Mailbox migration and custom Domino application migration are different projects. Forms, views, workflows, agents, scripts, databases, and business logic inside a custom Notes application require separate assessment. Do not assume that an email migration recreates those application functions in Microsoft 365 or Exchange.

Estimate migration volume and duration

Use mailbox count, total data volume, attachment profile, network bandwidth, source performance, destination throttling, and support capacity to estimate wave sizes. Treat the estimate as a planning range, then refine it after the pilot provides real throughput data.

Phase 2: Define scope and success criteria

Decide what “migration complete” means before the first mailbox is moved

Define what will be migrated

Document whether the scope includes primary mail, archives, contacts, calendars, tasks, notes, journals, shared data, public folders, and specific date ranges. Mark excluded data explicitly so that users do not interpret a planned exclusion as a migration failure.

Define measurable acceptance checks

Decide how the project will verify success: folder presence, representative message and attachment checks, calendar and contact checks, target item counts where meaningful, migration-log review, user sign-in, and business-owner confirmation.

Define rollback and source-retention rules

Keep the original NSF files and source environment available until the migrated data is accepted. Document what would trigger a pause, re-run, rollback, or extended coexistence period rather than improvising after users report a problem.

Phase 3: Prepare Microsoft 365 or Exchange

Resolve destination readiness before migration data begins to flow

Create and license target mailboxes

Ensure that each in-scope Notes user has the correct destination identity and mailbox. The current EdbMails Lotus Notes to Microsoft 365 workflow supports target mailbox preparation and can work with target mailboxes that are created and licensed in advance; its existing documentation also describes automated mailbox creation and licensing options in applicable Microsoft 365 workflows.

Confirm modern authentication and administrative access

Current EdbMails Microsoft 365 NSF migration documentation describes OAuth-based modern authentication and automatic or manual Entra ID application registration. Confirm the administrator account, required permissions, MFA policy, and registration method before the production window.

Prepare mailbox mapping

Match each Notes/NSF source to the correct destination mailbox. Current EdbMails documentation supports automatic mapping and manual mapping. Resolve differences in naming, SMTP addresses, aliases, disabled accounts, or renamed users before production migration.

Choose folder and filtering rules

Decide whether all folders and historical data should move. EdbMails' NSF migration pages describe filters based on criteria such as date, sender or recipient, subject, message content, attachments, and include/exclude folder selection in applicable workflows.

Check target-discovery limitations before a large project

Current EdbMails Lotus Notes to Microsoft 365 documentation notes that Microsoft API behavior can limit the automatic target-mailbox list shown in some scenarios. For larger target environments, use the documented CSV option when required rather than waiting until migration day to discover a mailbox-listing issue.

Test network and migration-computer readiness

Verify adequate disk space, stable network connectivity, firewall access, source-file permissions, target connectivity, and the Windows computer that will run EdbMails. Use the same migration computer for incremental re-runs when required by the documented EdbMails incremental workflow.

Phase 4: Build a representative pilot

Use the pilot to test real complexity, not only the smallest and easiest mailbox

Select diverse pilot users

Include an ordinary user, a larger mailbox, a mailbox with many folders, a user with important contacts and calendars, and at least one archive-heavy or higher-risk user. Add an executive or business-critical user only after the basic workflow has already been proven.

Measure actual throughput

Record migration duration, source size, item count, destination behavior, errors, retries, and user-verification time. Use the results to refine wave size and support staffing instead of relying only on theoretical bandwidth.

Turn pilot findings into production rules

Update mapping rules, filters, exception handling, user communication, validation scripts, and cutover timing from what the pilot actually revealed. A pilot has little value if the production plan is not changed when it exposes a risk.

Pilot migration checklist

Validate source, target, content, performance, and user experience before expanding the rollout

Source preview

Open the NSF, verify important folders and data types, note any unreadable content, and confirm that the file belongs to the expected user before beginning migration.

Target identity and mapping

Confirm that the selected source mailbox maps to the correct destination account and that the destination user can sign in with the expected identity.

Folder hierarchy and messages

Review Inbox, Sent, archives, and custom folders. Open representative messages and attachments from different time periods instead of validating only the newest data.

Contacts and calendars

If these data types are in scope, validate representative contacts, appointments, recurring events, and meeting information. Do not declare the pilot successful based only on email.

Migration logs and failed items

EdbMails provides migration logs and per-folder status information in its NSF to Microsoft 365 workflow. Review failed or skipped items, determine whether they are expected, and document the remediation path.

User acceptance

Ask pilot users or business owners to confirm that the target mailbox is usable and that the information they rely on is present before using the pilot as the basis for wider deployment.

Phase 5: Design migration waves

Group mailboxes by risk, volume, business dependency, and support needs

Wave users by complexity

Separate straightforward users from large archives, damaged NSF files, executive users, legal cases, shared mailboxes, or other exceptions. Moving the highest-risk users in the same first production wave makes root-cause analysis unnecessarily difficult.

Keep migration and support capacity aligned

A technically possible migration batch can still be operationally too large if the help desk cannot handle post-cutover questions. Size each wave according to the number of users the migration and support teams can verify and assist within the agreed window.

Preserve room for re-runs

Leave time between major waves for retries, incremental passes, exception remediation, and validation. A schedule with no recovery window turns a small migration error into a business outage.

Phase 6: Use incremental migration strategically

Move historical data early, then synchronize new or changed items before cutover

Initial pass

Migrate the bulk of historical mailbox content before the final cutover when the project design allows it. This reduces the amount of data that must be transferred during the final business-impact window.

Incremental re-run

Current EdbMails NSF migration documentation describes incremental migration for subsequent runs from the same migration computer to the same target. New or updated items can be transferred without re-migrating the previously completed data set.

Final synchronization

Schedule the last incremental pass around the source-change freeze or cutover point so that the destination reflects the latest data that is in scope. Record the exact final-sync time for troubleshooting and acceptance.

Do not confuse incremental migration with coexistence

Incremental data transfer helps synchronize changes, but a coexistence design may also require mail routing, calendar interoperability, directory synchronization, or user workflow decisions. Treat those as architecture questions rather than assuming the migration tool alone provides full coexistence.

Monitor throttling and destination response

Large cloud migrations can be affected by destination service limits and network conditions. Watch migration logs and throughput, adjust wave size if needed, and avoid interpreting a temporary service limit as source corruption.

Keep migration state consistent

Because incremental behavior can depend on the migration environment and previous run state, document the migration computer, job, mapping, source path, and target used for each wave. Avoid unnecessary job recreation during an active migration cycle.

Phase 7: Plan the final cutover

Define who changes what, in what order, and how the team decides that cutover is complete

Before cutover

Confirm the final user list, complete pre-stage migration, resolve failed items, verify target licensing and sign-in, prepare user instructions, schedule support coverage, and freeze unplanned configuration changes.

During cutover

Complete the final incremental pass, apply mail-flow or DNS changes where the architecture requires them, confirm new-message delivery to the target, and enable users according to the agreed sequence. Keep the source available until the validation gates have passed.

After cutover

Verify mail flow, mailbox access, folders, representative data, contacts and calendars, migration logs, and user acceptance. Record open exceptions and assign owners rather than hiding them inside a general “migration complete” status.

Migration validation and acceptance checklist

Validation should be repeatable across every migration wave

Mailbox and folder mapping

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

Representative email and attachments

Open messages from different dates and folders. Check message body, sender and recipient details, dates, attachments, and any business-critical content that users rely on.

Calendar and contact data

Validate the item types included in scope. Review representative appointments, recurring events, contacts, and distribution-related data where applicable.

Logs and item counts

Review EdbMails migration logs and available folder-level counts. Count comparisons help identify anomalies, but the final decision should also include content-level checks because counts alone do not prove completeness.

User sign-in and mail flow

Confirm that users can authenticate to the destination and that new inbound and outbound mail follows the intended production path after cutover.

Business acceptance and source retention

Keep the original NSF files and source system available until the business or project owner accepts the migration. Define the retention or decommission date separately from the technical cutover date.

Common project risks and practical controls

Most migration failures are easier to manage when the risk has an owner and a pre-defined response

Unknown or duplicate NSF sources

Control: Inventory all known mail and archive NSF files, map them to owners, and identify duplicates or stale copies before production migration.

Identity and mapping mismatch

Control: Validate destination accounts, SMTP addresses, mailbox licenses, and mapping before each wave. Use a mapping file or documented manual correction for exceptions.

Corrupt source database

Control: Preview representative NSF files early and route damaged files to the NSF recovery workstream instead of blocking the main migration batch.

Insufficient migration window

Control: Measure real throughput in the pilot, pre-stage historical content, use incremental passes where supported, and leave time for retry and verification.

User confusion after cutover

Control: Provide sign-in instructions, new-client guidance, cutover timing, support contact, and a short explanation of what data was and was not migrated.

Custom Notes application overlooked

Control: Separate mailbox migration from custom application modernization during discovery. Assign each application an owner, business criticality, target, and retirement or remediation plan.

Example migration timeline

Use this as a planning model, then adjust it to mailbox count, complexity, bandwidth, and change-control requirements

Week 1 — Discovery

Inventory users, NSF files, archives, data volume, target accounts, exceptions, custom Notes applications, damaged sources, and project stakeholders.

Week 2 — Target preparation

Prepare Microsoft 365 or Exchange mailboxes, authentication, permissions, mapping, filters, migration computer, network access, and validation scripts.

Week 3 — Pilot

Migrate representative users, measure throughput, review logs, validate data, obtain user feedback, and update the production wave plan.

Weeks 4–5 — Production waves

Pre-stage historical content, run controlled mailbox batches, resolve failed items, and perform incremental passes between waves.

Week 6 — Final cutover

Complete the last synchronization, transition mail flow where required, move remaining users, validate access and new-mail delivery, and provide intensified support.

Post-cutover — Acceptance and decommissioning

Close exceptions, obtain acceptance, retain source data for the agreed period, and decommission or archive legacy Notes infrastructure only after the project exit criteria have been met.

How EdbMails fits into the migration plan

Use the tool for source preview, mapping, filtering, migration, incremental re-runs, and reporting within the wider project process

Preview and source selection

EdbMails provides NSF viewing and selection capabilities so the migration team can inspect supported source mailbox content and choose the mailboxes or folders required for migration.

Mapping, filters, and batch execution

Current EdbMails NSF migration pages describe automatic or manual mailbox mapping, folder mapping, selective migration, filters, and processing of multiple NSF files for Microsoft 365 or Exchange destinations.

Incremental migration and logs

EdbMails supports incremental migration in documented repeat-run scenarios and provides migration logs that help administrators review migration status and folder-level results.

Explore EdbMails NSF Migration Tool

Related Lotus Notes migration resources

Move from project planning to the exact recovery, conversion, or destination workflow

NSF Migration Tool

Use the general NSF migration hub for source preview, destination choices, mapping, filters, and migration features.

NSF Migration Tool

Lotus Notes to Microsoft 365

Use the destination-specific guide for Microsoft 365 preparation, login, mapping, migration, and verification.

Microsoft 365 Migration

Lotus Notes to Exchange

Use the Exchange-specific workflow when the destination is a supported Exchange Server environment.

Exchange Migration

NSF Recovery Tool

Route corrupt, damaged, or inaccessible NSF files to recovery before they enter the normal migration wave.

Recover NSF Data

Free NSF Viewer

Inspect NSF mailbox data during discovery before deciding whether to recover, convert, or migrate the source.

Open NSF Viewer

What Is an NSF File?

Use the educational guide to understand Notes Storage Facility databases, common NSF types, and destination choices.

Learn About NSF Files

Domino to Microsoft 365

Use the server-source workflow when HCL, IBM, or Lotus Domino Server is the migration source and Microsoft 365 is the destination.

Domino to Microsoft 365

Lotus Notes Migration Challenges

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

Review Migration Challenges

NSF to PST Converter

Use the PST-specific commercial page when Outlook PST is the required output rather than a live Microsoft 365 or Exchange destination.

Convert NSF to PST

Personalized Demo

Free 24/7 Technical Support

NSF Migration Pricing

Frequently asked questions

What should a Lotus Notes migration project plan include?
A practical plan should cover source discovery, mailbox and NSF inventory, target readiness, identity and authentication, mailbox mapping, filters, pilot migration, batch scheduling, incremental passes, cutover, validation, rollback considerations, user communication, and post-migration support.
Should I migrate all Lotus Notes users at once?
Not necessarily. For most organizations, a controlled pilot followed by staged batches is easier to validate and troubleshoot than moving every mailbox in one operation. Batch size should reflect mailbox volume, bandwidth, support capacity, and the migration window.
Does EdbMails support incremental NSF migration?
Yes. Current EdbMails NSF migration pages describe incremental migration for repeat runs from the same migration computer to the same target, transferring new or updated items while avoiding duplicate migration of previously transferred items.
Can EdbMails automatically map NSF mailboxes to Microsoft 365?
Yes. Current EdbMails NSF to Microsoft 365 documentation describes automatic mailbox and folder mapping, with an option to map mailboxes manually when required.
Can EdbMails migrate multiple NSF files?
Yes. EdbMails' current NSF migration pages describe loading and processing multiple offline NSF files, including batch-oriented workflows.

What should be included in an NSF migration pilot?
Choose a small but representative group: a normal user, a large mailbox, users with calendars and contacts, a mailbox with custom folders, and any higher-risk archive or special-case mailbox. Validate folder structure, representative items, attachments, contacts, calendars, logs, and target usability before expanding the rollout.
How should I plan the final cutover from Lotus Notes to Microsoft 365?
Define the last source-change window, final incremental migration, mail-flow or DNS changes where applicable, user sign-in timing, support coverage, and a clear validation checklist. The exact cutover sequence depends on the organization's Notes/Domino architecture and target mail-flow design.
Does mailbox migration also migrate custom Lotus Notes applications?
No assumption should be made that a mailbox migration recreates custom Notes applications. Custom Domino applications can contain forms, views, workflows, code, and business logic that need a separate application-assessment and modernization plan.
What should be validated after Lotus Notes migration?
Check mailbox mapping, folder hierarchy, representative messages, attachments, contacts, calendars, tasks or other required items, target item counts where meaningful, migration logs, user access, and any business-critical folders. Keep the source data until the migration has been accepted.
How can I reduce migration risk?
Preserve source backups, inventory the environment, resolve identity and target-mailbox issues before migration, run a representative pilot, migrate in controlled batches, use incremental passes where supported, monitor logs, keep a rollback path, and avoid decommissioning the source before validation.

Start Your NSF Migration Pilot