Migrate from HCL Domino mail to grommunio

Migrate from HCL Domino mail to grommunio: what moves and what stays

Domino sites whose users want Outlook on a self-hosted server can use grommunio, which serves Outlook through MAPI/HTTP, Exchange Web Services and Exchange ActiveSync. Domino applications do not move with mail. The mail, calendar and contact data can be migrated, but the Notes databases, workflows and agents that users rely on stay on Domino unless they are rebuilt or replaced. That split is the first decision the project team should record. In most projects the internal messaging team owns the work and brings in an implementation partner for the migration tooling, directory changes and cutover. The short answer on effort and risk is that mailbox movement is the more predictable part, while the directory and the application inventory carry most of the risk. grommunio expects LDAP or Active Directory as the directory source, so the team must confirm early which directory will replace the Domino Directory for authentication and address lookup. Ask the vendor and your own environment to confirm the supported Notes-to-grommunio extraction path, since the published migration documentation focuses on Exchange.

Before scheduling any mailbox moves, inventory the Notes applications that users open daily, list which mail rules, delegations and shared mail files depend on Domino features, and decide whether each application stays on Domino, moves to another platform, or is retired. Confirm how users will reach those applications after cutover, because Outlook will not open them. Plan a coexistence period for free/busy and shared calendars, and test it with a pilot group. DeployOpen plans and implements grommunio inside the client's own infrastructure, including the directory integration, migration runs, backups and documentation, under a fixed scope agreed in writing before work starts. DeployOpen does not publish a price list, so cost depends on the number of mailboxes, the directory design, the application inventory and the cutover approach. A quote follows from that written scope.

Which Domino mail and calendar capabilities map cleanly to grommunio

This table compares the main Domino mail and calendar capabilities with the grommunio component or feature that covers them, and marks each row as clean, needs rework or gap. Read the status column first, then confirm each rework or gap item against your own Notes applications and client profiles before planning cutover. Most mail and calendar needs map across, while Notes applications and NRPC-dependent features stay outside the migration.

Domino capability	grommunio component or path	Status
Mail storage and delivery	Gromox delivers mail and stores mailboxes; SQLite holds individual mailboxes	Clean
Calendar and meeting invitations	Gromox calendar objects reached through Outlook, EWS or CalDAV via grommunio-dav	Needs rework: confirm recurring meeting series and delegate rules after import
Contacts	Gromox contacts, reachable through Outlook and CardDAV via grommunio-dav	Needs rework: map Domino personal address book fields to Exchange contact fields
Mail folders and rules	Folder hierarchy imports through the PST route; server-side rules need manual review	Needs rework: rebuild Notes rules and folder-based agents in Outlook
LDAP or Active Directory directory	grommunio uses LDAP or Active Directory; the Exchange script requires the same directory	Needs rework: Domino Directory groups and mail-in records must be re-sourced
Outlook desktop access	MAPI/HTTP, RPC/HTTP and EWS through Gromox; Outlook clients stay in use	Clean
Native iOS and Android mobile access	grommunio-sync provides Exchange ActiveSync for native mobile clients	Clean
Notes applications, workflows and NRPC features	No grommunio equivalent; Notes databases and NRPC-dependent features remain on Domino	Gap: confirm each application with the client before scoping

Which mailbox data, directory records and integrations need a documented path

A Domino to grommunio move touches more than mail files. Mailbox content, calendars, contacts, the directory, mail routing and Notes applications that call mail each need an owner and a documented path before cutover. The grommunio tooling documented for Exchange sets the reference pattern, and every Domino-specific step has to be confirmed with the tooling you choose and rehearsed on a copy of production.

Mailbox content and folder structure

Mail items, folders, read and flag states, and attachments are the core payload. The documented grommunio path moves data as PST files, converted with gromox-pff2mt and loaded with gromox-mt2exm, so the Domino export must produce a format that lands cleanly in that chain. Ask your migration tool vendor how it writes Notes folder hierarchies, nested folders and large attachments, then compare item counts per user on a test copy. Several mailboxes will likely be unusually large, so plan them as separate runs.

Calendars, meetings and recurrence

Calendar items are the most fragile part of a mail migration. Recurring meetings, exceptions, time zones, delegate rights and meeting responses can change silently when converted between Notes and MAPI structures. Document which calendar objects are migrated as data and which users must recreate, such as shared calendars and room bookings. Verify a sample of recurring series in Outlook after the test load, since a successful import does not prove that series still behave correctly.

Contacts and personal address books

Personal contacts in Notes sit in a different store from the corporate directory, and they usually carry custom fields that Outlook does not display by default. Decide whether contacts move with the mailbox or are exported to a CSV or vCard file for review. Confirm that grommunio-dav serves CardDAV for phones and desktop clients, and test that contact groups and photos survive the conversion.

Directory source of truth

The documented Exchange script requires grommunio to use the same LDAP or Active Directory as the source system. Domino Directory has been the authority for users, groups and mail routing, so you must name the replacement directory, map each Domino group type to a group in LDAP or Active Directory, and assign mailbox owners before any data moves. Confirm with your team how nested groups, distribution lists and external contacts will be represented, and who maintains them after cutover.

Mail flow, relay and routing

Inbound and outbound SMTP paths, MX records, relay hosts, and rules for external partners and scanners all depend on Domino routing. Write down which domains, aliases and forwarding rules move to grommunio, and in what order. Run coexistence tests so that mail sent during cutover reaches the correct mailbox, and confirm how bounces, journaling and any mail-based approvals behave during the switch.

Notes applications that call mail

Workflow databases, approval forms and scheduled agents often send mail or read calendars through Notes APIs. Moving the mailbox does not move these applications, so each integration needs an inventory entry, an owner and a decision: keep Domino for the application, replace its mail calls with SMTP or an API, or retire it. Test every outbound notification from a copy of the application against the new mail server before the Domino mailbox is switched off.

Migration sequence from Domino inventory to decommission

This sequence moves Domino mail and calendars to grommunio in controlled stages, so each stage produces evidence before the next one starts. Notes applications that are not part of the mail move stay on Domino until they have their own plan.

Inventory users, mail files, delegations and groups
Export a full inventory of Domino mail users, mail database paths and sizes, delegations, shared and resource calendars, and the directory groups that drive distribution lists and access. Your Domino administrator and mail owners confirm each item, and the Notes application owners mark which databases are mail-only and which are applications that stay behind. Done means a signed inventory that names an owner for every mailbox and every group, plus a list of applications excluded from the move.
Map the directory to LDAP or Active Directory
Decide which directory grommunio will use as its user and group source, because the Exchange import path depends on sharing the same LDAP or Active Directory with the source system. Map Domino Directory users, groups and aliases to directory objects, and document how SMTP addresses, primary names and group membership will resolve after cutover. Confirm the mapping with your directory team and test sign-in with a pilot account. Done means a directory mapping document and a test log showing that the pilot users authenticate and receive the expected groups.
Build and accept a pilot mailbox set
Choose a small group of mailboxes that cover typical cases, such as a user with delegation, a user with a shared calendar and a user who uses a mobile device. Extract their mail and calendar data, import it into grommunio, and check folder structure, message counts, calendar entries and recurring meetings against the source. Connect a native client and an Outlook client to confirm MAPI/HTTP, EWS or ActiveSync behavior for your environment. Done means a pilot acceptance log signed by the pilot users and the migration lead, listing each failure and its fix.
Run a parallel period with routing and free/busy checks
Run Domino and grommunio side by side while mail routing sends pilot users to the new platform and everyone else stays on Domino. Test inbound and outbound mail between the two systems, delegation, and how free/busy lookups resolve across the boundary. Free/busy behavior between the two systems is a configuration point to confirm in your environment, not something to assume. Done means a routing test record and a free/busy test record that show every scheduling scenario in the pilot working both ways.
Execute a staged cutover with a runbook
Move users in waves, each governed by a written cutover runbook that lists the freeze window, final incremental sync, MX or routing change, rollback trigger, and the people who approve each step. The migration script runs under an account that can read the source and write to grommunio, and its logs record successes and failures so a run can resume. Keep the source mailboxes read-only after each wave. Done means a completed runbook per wave with sign-off, and a wave report that lists any mailbox still needing rework.
Archive and decommission Domino mail
Once every mail user is confirmed on grommunio and the rollback window closes, export a retained archive of the Domino mail files in a format your records policy accepts, and store it under access controls with an index. Remove the Domino mail routing, scheduled jobs and mail templates, while leaving the Notes applications that were excluded from the move on their own supported footing. Confirm retention and legal hold requirements with your records and legal teams before deleting any source data. Done means a verified retained archive, a decommission record, and a list of Notes applications that remain on Domino with named owners.

What drives migration cost and duration, and how to keep each down

This table lists the main factors that raise effort when moving Domino mail and calendars to grommunio, with the reason each one matters and how to reduce it. Use it to check a written quote: each row names what the provider should state before work starts.

Driver	Why it changes effort	How to keep it down and what to ask for
Mailbox count and size	Each mailbox is extracted, converted and loaded separately, so total volume and the largest mailboxes set the run time and the storage needed on the grommunio server.	Archive or purge old mail before extraction, and ask the provider for a per-mailbox run plan with batch sizes and storage sizing for the target.
Local replicas and archives	Notes users often keep local replicas (.nsf copies) and local archives that are not on the server, so extraction must reach files on laptops and may find items the server never held.	Inventory replicas and archives early with a short survey, and ask whether the quote covers collecting local files or only server-side mail.
Groups, delegation and shared mail	Mail-in databases, shared mailboxes, delegates and group-based access must be recreated as mailboxes, permissions or distribution lists, which needs manual decisions for each case.	List every shared database and delegate before scoping, and ask the provider to state how each access pattern will be mapped in grommunio.
Directory cleanup	Domino Directory entries, orphaned accounts and mismatched names must be fixed before users can be matched to LDAP or Active Directory accounts, and the migration script requires the same directory as grommunio.	Clean stale accounts and naming rules before the cutover window, and ask whether directory reconciliation is included or billed separately.
Mobile devices	Each phone or tablet must be reconfigured for ActiveSync or other clients, and users often hold devices that were never documented.	Count devices from the mobile management or ActiveSync records, and ask how device reconfiguration and user support are scoped.
Integrations and applications	Mail-enabled Notes applications, agents, gateways, scanners and printers that send through Domino or read its mail can each need changes or testing.	Build a list of every system that sends or receives mail through Domino, and ask the provider to confirm which integrations are in the written scope.
Notes applications that remain	Applications that stay on Domino still need a server, access control and a support path, so the team carries two platforms during and after the move.	Decide which applications stay and which move, and ask for the cost of keeping the Domino server running for them in the quote.
Parallel-run length	Running Domino and grommunio side by side means both stay patched and monitored, and free/busy and calendar sync must be verified across both.	Set a short, written coexistence period with exit criteria, and ask how long the provider expects parallel running and who pays for the extra server time.

How the Domino migration differs by size and starting point

A small Domino site with a handful of mail users may be able to start on the free Community package, which grommunio lists for up to 5 users without manufacturer support. That makes the package useful for evaluation and for very small teams that accept self-support. The trade-off is that the package carries no vendor support, so the team needs in-house or contracted expertise for upgrades, backups and incidents.

User ceiling: The Community package covers up to 5 users, so confirm your active mailbox count, including shared and resource mailboxes, before you plan around it.
No manufacturer support: Budget internal or contracted time for patching, restores and troubleshooting Outlook connectivity.
Single host footprint: A small site usually runs the appliance or a manual install on one server, which keeps the first build simple.
Quick path to Outlook: Test MAPI/HTTP and EWS from the Outlook versions your users run before cutover.
Growth check: Once user count approaches the Community limit, the move to a paid tier changes the support model, so plan the step early.

Before committing, ask grommunio which package fits your user count, support expectations and any shared mailboxes, and confirm the terms in writing with a certified partner.

What usually goes wrong in a Domino to grommunio move

Most failed Domino moves trace back to identity and access problems rather than mailbox copying. The cards below cover the risks that tend to surface during coexistence, cutover and the first weeks of Outlook use, each with a check to run before users notice.

Directory mismatch at cutover

Mailboxes are created against one directory while the grommunio server authenticates against another. The exchange2grommunio.ps1 approach expects grommunio to use the same LDAP or Active Directory as the source Exchange environment, so a Domino Directory that does not map cleanly to LDAP or AD attributes can leave users with mail they cannot open. Before any pilot, confirm which directory is authoritative for names, aliases and SMTP addresses, and test a login and a send for every user type.

Unmapped groups and distribution lists

Notes groups, mail-in databases and nested distribution lists often do not carry over as-is. A list that worked for years in Domino can silently stop delivering after cutover, and senders get no error they will notice. Export a complete list of Domino groups with their members and owners, decide which become directory groups, and send a test message to each list before the cutover window closes.

Lost delegations and shared access

Delegate access, shared calendars and mailbox permissions in Notes do not map one-to-one to Outlook permissions. An executive assistant may lose send-on-behalf rights on the day of cutover, which is hard to spot until a meeting invitation goes out under the wrong name. Record every delegation and shared folder per mailbox before migration, then re-apply and verify them in a test account.

Free/busy gaps during coexistence

While some users sit on Domino and others on grommunio, free/busy lookups can return blank or stale results, and meeting scheduling across the two systems breaks down. Decide how long coexistence lasts, which user groups move together, and whether the calendar of each group is visible across the boundary. Test a meeting invitation from each side to each side before moving the first pilot group.

Client profile rebuilds and mobile re-enrolment

Moving to Outlook means every desktop profile is rebuilt, and phones that used Notes or Traveler-style sync must re-enrol against grommunio-sync for Exchange ActiveSync. Users who skip this step keep stale credentials and stop receiving mail on the device. Plan a short written guide per platform, provide a support queue for profile problems, and confirm that iOS and Android clients connect before the wider rollout.

Notes applications left out of scope

Mail moves are easy to scope, but Notes databases that send workflow mail, read Domino views or call LotusScript agents keep working only while the Domino server runs. When the mail server changes, these applications can fail quietly or stop sending notifications. Inventory each application's dependencies on mail, names and directory lookups before cutover, and decide with the application owners whether each one is retired, rewritten or kept on Domino.

What grommunio's Exchange migration tooling teaches about the plan

The most useful thing grommunio's documentation gives a Domino team is a worked example of how a migration to Gromox is supposed to run. The documented route for Exchange sources is the exchange2grommunio.ps1 script, which exports each mailbox to PST with New-MailboxExportRequest and imports it on the grommunio server over SSH by piping gromox-pff2mt into gromox-mt2exm. The script logs successes and failures, so a run can resume after an interruption instead of starting over. For a Domino project, the lesson is to ask early whether the migration partner will use a per-mailbox export, a per-batch import and a resumable log, and to make those three properties acceptance criteria rather than assumptions.

The same page sets preconditions that shape the architecture before any data moves. grommunio must use the same LDAP or Active Directory as the source, the script runs from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, and a shared folder must be writable by the source side and mountable on the grommunio server. Domino sites should translate these into their own questions: which directory will hold users and groups after Domino Directory stops being the source, which Windows or Linux host will act as the export point, and who approves a share that carries mailbox content between two environments. Each answer changes the schedule, so settle them before the first pilot batch.

Treat the Exchange script as the documented pattern, not as a Domino tool. Nothing in grommunio's documentation supplied for this topic describes an equivalent export from Notes mail files or a Domino-specific import, so the reader should confirm the Notes extraction route, its handling of encrypted and archived mail, and its treatment of calendars and contacts with the migration partner in writing. Ask for a pilot on a representative set of mailboxes, a sample of the resume log from a failed run, and a count reconciliation per mailbox before committing to a full cutover. Those artifacts show whether the Exchange pattern transfers to Domino.

Questions teams ask before moving Domino mail to grommunio

What drives the effort and cost of moving Domino mail to grommunio?

The largest drivers are the number of mailboxes, the volume of mail and calendar history you choose to keep, and how much of your Domino Directory logic must be rebuilt in LDAP or Active Directory. Grommunio's published pricing is per user per month, with a free Community package for up to 5 users without manufacturer support, Basic at 1.99 euros and Plus at 3.99 euros per user per month from 6 users, Business at 5.49 euros from 50 users, and custom Enterprise pricing from 1,000 users, according to the grommunio pricing page. Licenses are sold only through certified partners, so ask which partner is involved. Migration labor, server sizing and any Notes application work sit outside that license line.

How long does a Domino to grommunio mail migration take?

Duration depends on mailbox count, total data volume, the number of groups and shared mailboxes, and how many cutover waves you run. Grommunio's documentation does not give a fixed timeline, so ask for a duration tied to your own mailbox inventory and test results. Pilot a representative set of users first, measure export and import speed on your hardware, then extrapolate. Plan a coexistence window for free/busy and directory lookups, because that window usually drives the calendar work more than raw data movement.

What must our team supply before a migration starts?

You need a current inventory of mailboxes, distribution lists and shared resources, the Domino Directory data that maps users and groups, and a decision on which LDAP or Active Directory will be authoritative. You also need a provisioned grommunio server (appliance, manual or container install, as the grommunio documentation describes) with network access to the source data, and a named owner for the cutover and rollback decision. Ask the vendor or implementation partner to confirm each prerequisite against your environment before scheduling work.

Can our own administrators run this migration without outside help?

Yes, some teams do, provided they have strong Linux, mail server and directory skills and time for testing. Grommunio's documentation covers installation and migration paths, but a Domino migration also involves mapping ACLs, groups, calendars and certificates, which is where most unplanned work appears. A fixed-scope engagement puts those decisions in writing before work starts. Compare the internal effort, including the skills you would need to hire, against a written scope from DeployOpen or another implementer.

Will Outlook keep working after we move to grommunio?

Outlook can continue to work because grommunio's FAQ says organizations can keep their existing Microsoft Outlook clients through MAPI/HTTP, EWS and Exchange ActiveSync support. Grommunio's Gromox server also implements RPC/HTTP (Outlook Anywhere). Confirm the exact Outlook versions, profile behavior, Autodiscover setup and add-ins you depend on in a pilot group before cutover. Mobile users depend on grommunio-sync for Exchange ActiveSync, so test iOS and Android devices as well.

What happens to our Notes applications when mail moves?

Moving mail does not automatically move Notes applications, which stay on Domino unless you replace them separately. Inventory each database, its users, its replication schedule and its integrations with mail, such as workflows that send notifications or read calendars. Decide per application whether it stays on Domino, moves to another platform or is retired. Keep the Domino server reachable for those applications after mail cutover, and confirm that their mail-triggered processes still work.

What should a quote for a grommunio migration include?

A useful quote lists the scope in writing: mailbox and calendar counts, data retention rules, directory mapping to LDAP or Active Directory, the migration method, testing and pilot phases, cutover and rollback steps, and documentation handover. It should separate one-time work (design, migration, testing, training) from recurring items (grommunio licenses, hosting, support retainers and upgrades). Ask for assumptions and exclusions explicitly, including Notes application work, and confirm the licensing partner and whether support is included.

What to confirm with grommunio and your own environment before committing

Do not assume the Domino-to-grommunio path works for your mailboxes until you have run it on a pilot group that matches your real data. Start with the export route. The supported grommunio documentation describes a migration from Microsoft Exchange, using PST files and the gromox-pff2mt and gromox-mt2exm tools. Domino has no equivalent script in the supplied material, so confirm with grommunio which Domino export format and tooling they support, whether it is the same PST-based route or a separate IMAP or conversion step, and how Notes-specific items such as encrypted mail, rich text, and delegations are carried across. Ask for the result in writing, and check it against a sample mailbox from each mail client your users run.

Next, test Outlook behaviour on the exact Gromox version you plan to deploy. A grommunio release is a moving target, so do not treat any single version note as settled for your build. Gromox 3.12 is the release that matters for this topic, but confirm the MAPI/HTTP, EWS and Exchange ActiveSync behaviour with the Outlook builds on your standard desktop image, including profile creation, autodiscover, shared mailboxes, and calendar free/busy lookups. Verify rules and delegations separately: send-as, send-on-behalf, out-of-office, and server-side rules often need explicit testing because Domino rules and Outlook rules do not map one to one. Record every gap as a decision for the business owner, not a silent loss. Finally, size the storage and database layer on the pilot. grommunio keeps user metadata in MariaDB and stores individual mailboxes in SQLite, so ask the vendor how both scale with mailbox count, attachment volume, and concurrent Outlook sessions, and measure growth during the pilot. Plan backups for both stores, and confirm restore timing. Confirm the directory dependency too: the Exchange route requires grommunio to use the same LDAP or Active Directory as the source system, so verify your directory design before you commit.

How DeployOpen scopes, runs and supports the Domino to grommunio migration

A Domino to grommunio move touches mail, calendars, directory data and the Notes applications that stay behind, so the work is planned as one fixed scope. The cards below cover how that scope is written, where the work runs, how cutover is rehearsed and what happens after go-live.

Fixed scope agreed in writing

Most engagements are fixed-scope, so the mailbox count, the Domino servers in play, the directory source, the Notes applications that remain and the Outlook client versions are agreed in writing before work starts. Deliverables and timelines follow from that document. Ask for the scope to list which mail files are in and out, which calendar data is migrated and what evidence the team will hand over at the end.

Implementation inside your infrastructure

grommunio is installed in your own data center or cloud accounts, using the appliance images or a manual or container install, and it is connected to your existing LDAP or Active Directory. Nothing is hosted by DeployOpen unless you ask for that separately. Confirm early where backups, the MariaDB user metadata store and the per-mailbox SQLite files will live, since they determine how the platform is restored.

Pilot and cutover runbooks

A pilot moves a small set of mailboxes and calendars so that extraction, import, client connection and free/busy behavior can be checked against real Outlook profiles. The cutover runbook then records the order of mailbox moves, DNS and mail flow changes, rollback steps and the people who approve each stage. Ask for the pilot exit criteria to be written down before the first production batch runs.

Mapping Notes applications that stay behind

Mail moves, but Domino applications often do not. The engagement inventories the Notes databases that remain, records which of them depend on Domino Directory or on user mail, and sets out how they will keep running during and after the move. Confirm with your application owners which databases are retired, which are rewritten and which stay on Domino for the foreseeable future.

Documentation and handover

Each engagement produces operating documentation for the grommunio platform, the directory integration, the migration log and the runbooks used. Migration logs record successes and failures so runs can be resumed or reconciled. Ask which documents you receive, in what format, and whether the handover includes a walkthrough for your administrators and service desk.

Pricing and optional retainers

DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move it are the user count, the number of directory sources, the volume of Notes applications to assess and the cutover window. After go-live, ongoing support, upgrades and continuous testing can be contracted as a retainer, which is recurring, separate from the one-time migration work. Ask for both parts to be quoted separately.

Migrate from HCL Domino mail to grommunio