What to do with your Domino applications when you migrate

The email migration is usually the visible part of leaving Domino. The harder decisions are waiting behind the inbox: old Notes databases, approval workflows, document libraries, forms, internal tools and custom applications that have quietly supported the business for years.

For a legal, industrial, construction, manufacturing or professional services firm, those applications can hold contract records, project documents, quality processes and approval history. Moving messages does not resolve what should happen to any of them. An NSF to SharePoint migration can preserve content and documents, but it cannot carry Domino application logic into SharePoint unchanged.

Use three decisions for every application: Retire, Replace, Rebuild. There are also two useful shortcuts inside those decisions. Archive is a way to retire an application while keeping its records. Lift is the cheapest form of replacement when content can move with little new logic. This three-bucket framework keeps the project focused on business need instead of treating every NSF as a development project.

Begin with an inventory. For each database, record its owner, purpose, active users, last-used date, data volume, attachment volume and retention needs. Classify it as content-only or workflow-heavy, then flag rich text, response hierarchies, document links, active agents and complex access controls. Business owners should confirm the disposition and the reason for it.

Retire: Apps the Business No Longer Needs

If nobody owns an application and nobody has opened it in a year, it goes. That rule forces an explicit challenge to systems that remain online only because no one has made a decision. Confirm legal and records-retention obligations first, document the approval, then remove the application from the migration scope.

Retirement does not always mean deletion. Archive is the shortcut inside Retire. Use it when the application no longer performs an active business process but its records still need to be searched, reviewed or retained. A good archive preserves useful content without recreating the old Notes interface.

For SharePoint, that may mean storing records as HTML or PDF alongside their original attachments, with selected legacy metadata mapped to library columns. Users get a stable, read-only reference that can be filtered and searched. The business avoids paying to rebuild forms, views and workflow logic that it no longer uses.

Define archive acceptance criteria before export. Identify who may read the archive, which dates and author fields must remain visible, how attachments will be opened and what search behavior users need. An archive is successful when an authorized user can retrieve and understand a historical record without the Domino application.

Replace: Workflows the Destination Platform Already Handles

Many Domino applications support a valid process but no longer justify custom code. Replace these with capabilities already available on the destination platform or with a dedicated SaaS tool. In Microsoft 365, SharePoint libraries can hold document-centric content, SharePoint lists can manage structured records, and Power Apps and Power Automate can handle forms, approvals and routing.

Lift is the shortcut inside Replace. It is the cheapest form of replacement: move a content-heavy database into a SharePoint library or list, map the important metadata, and create only the views users need. It fits applications made mostly of attachments, simple fields and light filtering. It does not fit an NSF whose value depends on agents, formulas, complex permissions or multi-stage workflow.

Choose the target according to the work, not the shape of the old database. Libraries suit file-first processes. Lists suit structured records, filtering and reporting. Power Platform adds forms and workflow where the standard SharePoint experience is not enough. A dedicated SaaS product can be the better replacement when the process is common and the product already covers it.

A direct move into one oversized list can leave users with slow or confusing views. Split distinct workstreams into suitable lists or libraries, index the fields people filter most often, such as status, date or customer, and avoid recreating every legacy view. Heavy attachments may belong in dedicated libraries with appropriate lifecycle rules.

Replacement also changes access. Domino groups, nested roles and application-level rules do not map automatically to Microsoft 365. Map roles to Microsoft Entra ID or Microsoft 365 groups, define read, edit and approval rights, and have the business owner review them before release. Do not inherit broad defaults simply because they are convenient.

Rebuild: Business-Critical Logic Worth the Investment

Reserve rebuilding for applications that still support an important process and cannot be replaced safely. This is an expensive path because the team is creating and testing a new application, not merely moving records.

A rebuild may be warranted when an NSF contains essential routing, calculations, role-dependent screens, integrations or business rules that cannot be met by a standard destination tool. In Microsoft 365, the result might combine SharePoint, Power Apps and Power Automate, or it may require a separate web application. The right design depends on the process, not on reproducing Notes screen by screen.

Treat each rebuild as a product decision. Assign a business owner, document the current rules, identify what may be simplified, and define measurable acceptance criteria. Separate required behavior from familiar behavior. A view that users recognize is not automatically a requirement, while an approval path that controls contractual or operational risk may be.

Rebuilding every custom NSF preserves years of accumulated complexity and expands cost. Rebuild only after Retire and Replace have been ruled out, and only when the value of the process supports ongoing ownership, testing and maintenance.

Plan the Data, Attachments, Links and Permissions Together

Whichever bucket an application enters, its data needs a written mapping. For every Domino field, define the destination, data type, rendering method and validation rule. Also decide which values must remain native metadata for filtering and which can be preserved as rendered text.

• Rich text: Test conversion carefully. HTML or PDF snapshots may preserve layout more reliably for archival records.
• Multi-value fields: Map them to suitable choice or managed metadata fields when users need to filter the values.
• Names fields: Resolve active identities to Microsoft Entra ID objects for Microsoft destinations, or preserve plain text when the person no longer has an account.
• Computed values: Flatten them into static exported values unless the new application will reproduce the calculation.
• Document links: Rewrite links for an active application where feasible. In an archive, retain useful reference information and document any links that will no longer work.
• Response hierarchies: Preserve parent-child identifiers in structured metadata, or render the hierarchy as navigable archive content.
• OLE objects and attachments: Convert unsupported objects to standard formats where possible, and flag exceptions for manual review.
• Forms: Decide whether each form is only a historical layout, a data-entry screen that needs replacing or part of logic that requires a rebuild.
• Permissions: Translate business roles instead of copying old access entries blindly, then test the result with representative users.

Run a pilot with representative applications and records. Include a straightforward archive, a database with rich text and attachments, and a workflow-heavy application. Verify created and modified dates, authors, metadata, permissions, search, links, hierarchies and exception logs. A migration report should identify failed items, truncated values and access mismatches rather than hiding them in a success percentage.

The Google Workspace Path

The same Retire, Replace, Rebuild decision applies when Google Workspace is the destination. Drive and shared drives can hold documents and organized content. AppSheet and Apps Script can provide forms, automation and application logic. A content-focused NSF may be replaced with a shared-drive structure, while a process with important custom rules may need an AppSheet solution, Apps Script development or a dedicated SaaS product.

Google Workspace does not remove the need for field mapping, attachment testing, identity translation and permission review. The destination changes, but the migration discipline does not. Cortavo migrates and runs both Microsoft 365 and Google Workspace, so the platform can follow the firm's operating needs.

Validate Before Domino Is Decommissioned

After the pilot, business owners should sign off on content fidelity and process behavior. Freeze changes in the approved source applications, run a final delta migration, apply the chosen retention controls and record where each archive or replacement now lives. Keep Domino available until the team has verified the destination and reconciled exceptions.

The application work should be planned alongside the broader move. Cortavo's complete 2026 Microsoft 365 migration guide covers the wider transition, while its Domino cost and risk assessment helps frame the case for leaving the old environment.

Contact Cortavo to plan your Domino application migration.

Frequently Asked Questions

Can you migrate Lotus Notes and Domino applications to SharePoint?

Yes, for content and documents, with caveats. NSF records, attachments and selected metadata can be mapped into SharePoint lists and libraries after conversion and testing. Domino application logic does not move into SharePoint as-is. Forms, formulas, agents, routing and role-based behavior must be replaced with standard Microsoft 365 capabilities or rebuilt.

What happens to custom Domino applications when you leave Lotus Notes?

Each application should be retired, replaced or rebuilt. Obsolete applications are deleted after the required review. Inactive applications with records that must remain available are archived. Simple active processes move to destination-platform tools or SaaS products, while business-critical custom logic is rebuilt only when replacement is not safe.

Should we rebuild or replace our Domino applications?

Replace first when SharePoint, Power Platform, Google Workspace or a dedicated SaaS tool can meet the business need. Rebuild when the application supports an important process with essential logic that available products cannot reproduce safely. The application needs a named owner and clear success criteria either way.

How do you migrate NSF application data, not just email?

Inventory each NSF, assign its disposition, map every required field and identity, convert unsupported content, and test a representative export. Validate metadata, dates, authors, attachments, forms, document links, hierarchies, search and permissions. Reconcile exceptions before the source is frozen and the final data is moved.

Can Domino applications be moved to Google Workspace?

Content can move to Drive or shared drives after mapping and validation. Application behavior may be replaced or rebuilt with AppSheet, Apps Script or a suitable SaaS tool. As with SharePoint, Domino logic does not transfer unchanged, so the Retire, Replace, Rebuild decision still applies.