Coexistence During Office 365 Migration

Coexistence is the controlled period when users, mailboxes, or services remain split between a source environment and Microsoft 365. It is usually needed when a migration runs in batches instead of a single cutover. During that period, mail routing, address visibility, calendar availability, shared resources, and user access must continue to work across both environments.

The design depends on the source and destination. Exchange Server to Exchange Online can use Microsoft hybrid features, while a tenant-to-tenant project needs a separate plan for mail routing, identities, domains, and calendar visibility. EdbMails Office 365 migration software supports mailbox-data migration and subsequent migration passes; it does not configure Microsoft hybrid services, cross-tenant mail flow, directory synchronization, or free/busy sharing.

What coexistence must maintain

A useful coexistence plan starts with user-facing outcomes rather than a product choice. The exact capabilities vary by migration model, but the project team should define how the following services will work before the pilot begins:

• Mail flow: Messages must reach the authoritative mailbox without loops, duplicate delivery, or reliance on an untested forwarding rule.
• Directory visibility: Migrated and not-yet-migrated users should resolve the correct recipient objects, aliases, groups, rooms, and shared mailboxes.
• Calendar availability: If cross-environment scheduling is required, test free/busy lookups and meeting updates in both directions.
• Authentication and client access: Users need clear sign-in instructions and a defined approach for Outlook, mobile devices, and web access.
• Delegated resources: Shared mailboxes, distribution groups, room mailboxes, and permissions require their own ownership and validation plan.

Content migration alone does not create coexistence. Mail flow, identity, directory, DNS, and collaboration settings must be designed and tested separately for the selected route.

Choose the correct coexistence model

Core components of an Office 365 coexistence plan

Mail routing and accepted domains

Document where inbound mail arrives, how messages are routed to users on each side, and which system is authoritative for every recipient. For hybrid Exchange, use the supported connectors and transport configuration created or validated through Microsoft’s hybrid workflow. For tenant-to-tenant projects, define temporary routing only after checking loops, spam controls, transport rules, journaling, and reply behavior.

Identity, directory, and address-list visibility

Decide how source and target user objects, aliases, contacts, groups, and rooms will be represented. Check for duplicate proxy addresses and confirm the authoritative identity source. A mailbox migration tool can map source mailboxes to targets, but it does not replace directory synchronization or identity governance.

Free/busy and meeting continuity

Calendar items copied to a target mailbox do not by themselves provide cross-environment free/busy. Hybrid deployments use Microsoft organization relationships and related services. Cross-tenant or cross-platform projects may need native sharing configuration or a separate coexistence solution. Test new invitations, updates, cancellations, recurring meetings, rooms, and delegate scenarios.

Shared mailboxes, groups, and permissions

Inventory owners, members, Full Access, Send As, Send on Behalf, folder permissions, automapping, moderation, and delivery restrictions. Recreate or configure these settings according to the target design, then validate them independently of mailbox-content counts.

Pre-migration coexistence readiness checklist

• Classify the project as cutover, phased, hybrid, or tenant-to-tenant and name the owner of each coexistence component.
• Inventory mailbox sizes, addresses, aliases, groups, rooms, shared mailboxes, delegates, forwarding, retention, holds, and business-critical applications.
• Prepare and license target accounts as required, then verify source-to-target mappings with full SMTP addresses.
• Confirm the applicable Microsoft 365, Exchange, Entra, network, certificate, and endpoint prerequisites.
• Document mail routing before, during, and after cutover, including rollback conditions and the authoritative mailbox for every batch.
• Lower relevant DNS TTL values in advance only when the approved cutover plan includes DNS changes.
• Select a representative pilot group that includes delegates, shared resources, mobile users, large mailboxes, and users who collaborate across the boundary.
• Define measurable acceptance checks for mail flow, sign-in, Outlook, free/busy, meetings, permissions, and migration reports.

Run coexistence in controlled migration phases

1. Baseline: Record the source configuration, expected mailbox scope, item counts, mail-flow path, dependencies, and rollback state.
2. Pilot: Migrate representative users, keep the existing routing plan in place, and test communication in every required direction.
3. Batch migration: Move related teams together where practical, monitor service limits and reports, and keep a change log for routing and directory updates.
4. Subsequent pass: Process supported new or previously unmigrated items while the approved source-to-target mapping and project context remain unchanged.
5. Cutover: Change domains, MX records, Autodiscover, connectors, or client instructions only after the target batch meets its acceptance criteria.
6. Exit: Remove temporary routing, contacts, connectors, forwarding, and test objects only after business acceptance and dependency review.

How EdbMails fits into the coexistence plan

EdbMails handles the mailbox-data migration portion of the project. Administrators connect to the source and target, load the required mailboxes, verify mappings, apply supported selection options, run migration batches, and review progress and reports.

• Batch selection: Move pilot users or logical groups according to the approved schedule.
• Mapping controls: Review automatic matches or define the intended source-to-target mailbox pairs before migration.
• Incremental processing: A later pass can process supported items that were not migrated previously when the same project context, computer, source, target, and mappings are retained.
• Selective scope: Use supported folder, item-type, and date filters when the migration plan calls for a defined data set.
• Progress and reports: Use migration status and detailed reports to investigate warnings, skipped items, and failures before cutover.

EdbMails does not automatically establish hybrid mail flow, synchronize directories, move a custom domain, configure cross-tenant free/busy, update DNS, or recreate every permission. Keep those tasks in the coexistence workstream and validate them with the responsible Microsoft 365 or Exchange administrator.

Validation before each batch cutover

• Send internal and external test messages to and from migrated and not-yet-migrated users; check headers and message trace where needed.
• Confirm that Outlook, Outlook on the web, mobile access, Autodiscover, and sign-in use the intended mailbox location.
• Test free/busy and meeting creation, updates, cancellations, recurring meetings, delegates, and room booking in both required directions.
• Review representative folders and supported item types, then investigate migration-report warnings, skipped items, and failures.
• Verify shared mailbox access, group delivery, aliases, forwarding, Full Access, Send As, Send on Behalf, and required folder permissions.
• Record business-owner acceptance before changing routing, DNS, licensing, source objects, or coexistence settings.

Use the Office 365 mailbox migration validation guide to structure the data and user-access checks for each batch.

Common coexistence issues to investigate

• Mail reaches the wrong mailbox: Check accepted domains, connectors, forwarding, target addresses, duplicate recipient objects, and the authoritative mailbox location.
• Free/busy is blank or one-way: Review organization relationships, sharing configuration, Autodiscover or availability endpoints, permissions, and the selected coexistence model.
• Users see duplicate recipients: Check synchronized objects, contacts, proxy addresses, address-list scope, and source-of-authority decisions.
• Replies use an unexpected address: Validate primary SMTP addresses, aliases, reply routing, address rewriting, and domain state.
• Delegates lose access: Compare documented permissions with the target configuration and test each required access type.
• A migration rerun creates confusion: Keep mappings stable, review the previous report, correct the reported cause, and use the documented subsequent-pass process.