Nextcloud groupware: Mail, Calendar and Contacts

Mail stays where it is. The IMAP server that holds your mailboxes today keeps holding them, and Nextcloud Mail acts as a client that connects to it. Calendars and contacts are different: they are stored in Nextcloud and reached by desktop and mobile clients through CalDAV and CardDAV. This split is the first design decision to document, because it determines which team owns which data, which backups matter, and where a user's calendar lives if the mail server changes later. Confirm with your mail administrators whether the IMAP and SMTP endpoints, TLS settings and authentication methods your users already rely on are supported by the Mail app version you plan to run.

Authentication follows the directory. Users sign in to Nextcloud through the directory or identity provider configured for the instance. Nextcloud's LDAP app lets LDAP and Active Directory users appear in Nextcloud and log in with their directory credentials, and Nextcloud also documents OpenID Connect and SAML user authentication backends. The directory team should decide which backend applies, which groups grant access to the groupware apps, and how account disablement in the directory propagates to Nextcloud sessions and to the mailbox connection. Ask the directory team to confirm that a disabled account stops working in Mail, Calendar and Contacts at the same time, since the IMAP credentials and the Nextcloud login may be checked by different systems.

What changes for the mail server team. For most deployments the mail server itself does not change. The mail team should expect new client connections from the Nextcloud server, so they need to review connection limits, TLS certificate trust between the Nextcloud host and the IMAP and SMTP services, and how sent mail is authenticated and attributed. If users will send from Nextcloud, confirm that the outbound path meets your existing SPF, DKIM and DMARC policy. Also confirm whether the mail team will support Sieve or other server-side rules, since those are configured on the mail server rather than in Nextcloud.

What changes for the client rollout. Calendar and contact sync depend on CalDAV and CardDAV support in each client, so the rollout plan should list the desktop and mobile clients your users actually run, test each one against your instance, and record the sync behavior for recurring events, shared calendars and address book updates. Confirm the exact client support list with the Nextcloud app documentation for the release you plan to deploy rather than relying on general statements about CalDAV compatibility. Plan a pilot group across the operating systems and mobile platforms in use, and decide early how users will be told to replace an existing calendar or contact account without creating duplicate entries.

The decisions that matter most for calendars and contacts are which records move, which system is authoritative for each one, and how users keep scheduling while the move happens. The wave planning, pilot groups and mail cutover order are covered in the migrating group, so this section focuses on the data itself. Start with an inventory of every source: personal calendars, shared team calendars, room and equipment calendars, subscribed holiday feeds, personal contact books, and shared address books or distribution lists. For each one, record the owner, the approximate item count, and whether anything writes to it automatically from another system. Then confirm the import formats Nextcloud accepts for your data and the source systems that have a documented migration route. Check both against the current Nextcloud documentation before you choose a method, because supported formats and source systems change between releases.

Duplicate handling needs a decision before the first test import. Many calendar and contact exports carry the same item from more than one place, such as a meeting that exists in an organizer's calendar and in each attendee's copy, or a contact stored in a personal book and a shared book. Find out whether the import keeps the original unique identifiers in each event and contact record, because a re-run that preserves those identifiers updates existing items instead of creating copies. Test with one mailbox and one shared calendar, then count items before and after. Set a clear rule for contacts that share an email address, such as merge, keep both or keep the newer record, and apply it the same way for every user. Resource calendars need a separate check so that imported bookings do not create double reservations for rooms or equipment.

Free/busy continuity is the part of the cutover that colleagues notice first. If calendars move to Nextcloud while the old system still answers availability queries, people may see stale or missing time, and meeting invitations can be sent into the wrong slots. Decide whether the move happens for all users at once or by group, and for each group decide which system publishes free/busy information during the overlap. Confirm how Nextcloud Calendar exposes availability and whether your existing mail or calendar platform can query it, since this depends on the versions and configuration of both sides. A common approach is to freeze new event creation in the old system for a short, agreed window, run a final delta import, then switch the publishing source. Record the time of the switch so support staff can explain any gap to users.

Client reconfiguration is where most user-facing problems appear. Desktop and mobile clients need CalDAV and CardDAV account settings that point to the Nextcloud DAV endpoints, and each user may hold an old profile that still syncs the same data. Plan to remove or disable those profiles after the user has confirmed their new account works, so that items do not appear twice or sync back into the old system. Mobile profiles often need manual steps, so give users a short written procedure and a test checklist that covers creating an event, accepting an invitation, and confirming that a contact appears on the phone. If you use the directory-based sign-in described in the identity guidance, confirm that the clients you support accept the login method you choose. Test each client version your users run, not only the latest one.

A rollback plan protects the cutover if the imported data or the client setup fails. Keep the source calendars and contact books intact and readable until a sign-off date that the business has agreed, and do not delete them during the migration window. Keep a log of what was imported, when, and from which source, so that imported items can be removed from Nextcloud if a rollback is needed. Test the rollback path on the pilot group: confirm that reverting the client profile or the DNS entry restores access to the old system, and confirm which changes made in Nextcloud after cutover would be lost or would need to be exported back. Name the person who can authorize a rollback and the conditions that trigger one, such as missing free/busy data or repeated duplicate creation. Ask your implementation partner to put these steps in the written scope so that the rollback is tested before the production move.

Once Mail, Calendar and Contacts are in daily use, every Nextcloud upgrade becomes a change to mail and scheduling, not only to file sync. Nextcloud does not allow skipping major releases, so a server that is several majors behind must be moved forward one major version at a time, with a verified backup taken before each step. Third-party apps are disabled during an upgrade until their developers confirm compatibility with the target version. For groupware, that last rule matters most: a third-party connector, sync helper or calendar plugin that was working on the current release may simply stop loading after the upgrade, and users will notice first on their phones. Plan the upgrade path as a sequence of steps with a checkpoint at each one, not as a single jump. The bundled apps need a separate test pass for each target version. For each step, run a scripted set of checks against a restored copy of production: send and receive mail through the IMAP account and the Mail app, confirm that attachments, signatures and folder sync behave as before, create and edit events on a shared calendar, check free/busy lookups and resource bookings, and confirm that CalDAV and CardDAV clients still connect and sync contacts with their existing credentials. Repeat the same checks on the desktop and mobile clients your users actually run, because server-side success does not prove client-side success. Record results against the target version so that a failed check can be traced to one specific release. Assign ownership before the first test window opens. In most organizations the Nextcloud administrator owns the upgrade and the backup, the mail administrator owns the IMAP and SMTP side and confirms that mailbox access still works, and a named business owner signs off that calendars and contacts look right. Agree in writing who can halt a rollout and who is on call during the change window. Choose timing that avoids mail-critical periods such as month-end close, payroll runs, regulatory filing deadlines and planned mailbox migrations. Keep a rollback plan that restores both the database and the data directory from the same backup point, and rehearse it at least once on the restored copy. Requirements also change between major versions. Newer releases can drop support for older PHP, database or operating system versions, and the system requirements for the target release must be checked against the stack that is already running, including the database server that holds calendar and contact data. Confirm the exact minimums with the version-specific upgrade pages in the Nextcloud upgrades section before scheduling each step, rather than relying on a table that was current when the groupware was first deployed. If a required component has to change, that work belongs in the same test window as the Nextcloud upgrade itself. Finally, ask any partner or internal team to put the upgrade plan in writing before work begins. The plan should list each target version in order, the backup and restore procedure, the test scripts for mail, calendar and contacts, the list of third-party apps with their compatibility status, the owners and the approved change windows. Ask how long the test window is expected to run and what happens if a check fails on day one of the window. Those answers determine how much of the upgrade is one-time project work and how much recurs with every release, which is the basis for comparing a quote with a retainer for ongoing upgrades.