Email migration to Microsoft 365: methods

Kloudeal Journal · Business guide

Migrating email to Microsoft 365 requires a method compatible with the source system and the data the business must retain. This guide compares common scenarios and explains account, domain, transfer and service acceptance preparation.

Editorial review: 16 October 2026 · Reading time: 26 min

01Source

Exchange, Google Workspace, IMAP and local archives.

02Preparation

Identities, mailboxes, access and domain.

03Launch

Testing, email transition and subsequent support.

Contents of this guide

What changes according to source

Source	Typically transferable content	Main consideration
Exchange Server	Email, calendars, contacts, tasks and much Exchange information.	Version, support, coexistence, permissions, Active Directory and method.
Google Workspace	Gmail, calendars, contacts, rules and other components through specific procedures.	Google permissions, mapping, routing and special-item validation.
IMAP	Email messages and folders.	Excludes contacts, calendars and tasks.
POP3	Depends on actual historical data location.	Email may reside only in Outlook, PST files or other clients.
HCL Domino / Notes	Email, calendars and contacts through compatible solutions.	Separate email from Domino applications and databases.
Microsoft 365	Cross-tenant Exchange Online mailboxes.	Identity mapping, domains, licences, coexistence and permissions.

There is no universal Office 365 email migration procedure. Source capabilities determine appropriate method and expected fidelity.

Planning an email migration?

With the source system, mailbox count, sizes, domains and target date, we can review the project and identify methods and tools to assess.

Request an email migration assessment

Preparing an email migration around departmental work

Identify each address’s function before migrating. Personal mailboxes, shared mailboxes and application accounts need different treatment. Document recipients, alternative addresses, delegations and dependent processes before method selection; mailbox size lists do not reveal everything.

Consider an administration address receiving invoices and allowing several people to reply. Validation extends beyond locating historical messages. Authorised users must open the mailbox and perform agreed actions, while unrelated accounts remain excluded. Also test any system sending confirmations through that address.

Record incidents by user, affected address and failed action. Delegation issues differ from delivery failures or uncopied messages. Classification prevents broad email changes where the cause is one permission or application setting.

What to check on the first destination working day

Acceptance combines transfer and service validation. Review reports, errors and historical samples, then test sending, replies and reception with internal and external recipients, shared mailboxes and employee devices. Document enough detail for another person to repeat checks.

During support, watch less visible processes: web forms, printers, management systems and automated alerts. User email may work while applications retain previous provider settings. Confirm those senders and hand over configuration, outstanding incidents and escalation procedures.

Office 365, Microsoft 365 and Exchange Online: clarifying names

Many businesses still use the term Office 365 for Microsoft’s cloud environment, making “migrate email to Office 365” a common search. In current terminology, Microsoft 365 is the broader platform and Exchange Online is the business email cloud service. Exchange Online provides:

Service	Example
Mailboxes	User email.
Calendars	Meetings and availability.
Contacts	Personal and organisational contacts.
Shared Mailboxes	ventas@empresa.com, soporte@empresa.com.
Rooms / Equipment	Meeting rooms and other resources.
Mail flow	Rules, connectors and routing.
Online Archive	Additional archive where supported by the plan.

We use Office 365 terminology because users still recognise it, while technically focusing on migrating mailboxes to Exchange Online within Microsoft 365.

What email migration can actually include

Clarify what users mean by a mailbox: messages, folders, calendars, contacts, tasks, delegations, historical archives and shared access may need different technical mechanisms.

Element	Can it be included?	Primarily depends on
Messages	Yes.	Source and tool.
Folders	Yes.	Source.
Calendar	Yes, for many sources.	Unavailable through standard IMAP.
Contacts	Yes, for many sources.	Unavailable through standard IMAP.
Tasks	According to source and method.	Particularly relevant to Exchange and Google.
Rules	According to tool and source.	Outside IMAP scope.
Delegations	According to source and procedure.	Require correct identity mapping.
Shared Mailboxes	Yes, where present at source or designed at destination.	Content and permissions.
Archive	According to platform and licensing.	Volume, tool and destination plan.
Public Folders	In specific projects.	Source, structure and method.

Do not promise fidelity beyond source capabilities. IMAP-only interfaces do not expose calendars and contacts through that protocol. Tools cannot retrieve data that IMAP does not provide. Exchange and Google Workspace support richer mechanisms preserving additional components.

Assessment before email migration

Email assessment answers questions directly affecting architecture and pricing.

Area	What we need to understand
User mailboxes	Count, size and active users.
Shared Mailboxes	Count, size, owners and delegations.
Archives	Users accessing them and volume.
Rooms / Equipment	Resources to retain.
Domains	Primary SMTP, aliases and secondary domains.
Calendars and contacts	Existence and access method.
Applications	Systems sending or reading email.
DNS	Current MX, Autodiscover, SPF, DKIM and DMARC.
Identity	Cloud-only, Active Directory or existing Microsoft 365 tenant.
Target date	Available window and business restrictions.

Use these details to select batch migration, longer coexistence or concentrated cutover.

Migrating Exchange Server to Exchange Online

Migration from on-premises Exchange Server to Exchange Online can preserve more information than IMAP because both share Exchange architecture. Microsoft provides routes according to version, mailbox numbers and coexistence requirements.

Factor	Why it matters
Exchange version	Determines support and available routes.
Mailbox count	Influences cutover versus gradual migration.
Coexistence	May favour hybrid deployment.
Active Directory	Affects identity and recipient administration.
Certificates	Important for connectivity and hybrid services.
Autodiscover	Affects clients and configuration.
Applications	May rely on local Exchange or SMTP relay.

Official reference: Microsoft – Ways to migrate multiple email accounts to Microsoft 365 or Office 365.

Exchange Server 2016 and 2019 in 2026: an important change

This requires a specific update. Exchange Server 2016 and Exchange Server 2019 reached their standard support end on 14 October 2025. Microsoft recommends moving to Microsoft 365 or Exchange Server Subscription Edition (SE). Businesses retaining Exchange 2016 or 2019 in 2026 should consider lifecycle and security alongside functional improvement.

Can these versions still be migrated?

Microsoft documents routes to Microsoft 365, while unsupported production Exchange carries implications. Review strategy against: current build, available updates, ESU programme participation, hybrid architecture and the route to Microsoft 365 or Exchange SE. Official reference: Microsoft – Exchange Server 2016 and 2019 End of Support Roadmap.

Still using Exchange Server 2016 or 2019?

General support has ended. Review version, patches, Active Directory, applications and components to retain or retire before simply moving mailboxes.

Review Exchange Server migration

Exchange cutover migration

In a cutover migration moves the Exchange organisation in a concentrated transition. Microsoft documents technical support up to 2,000 mailboxes but indicates that practical timings generally favour around 150 or fewer. Fewer than 150 users does not automatically justify cutover.

Also review applications, calendars, Active Directory, resources, coexistence and other requirements. When it may suit. Organisations where: long coexistence is unnecessary, user numbers are manageable and every dependency can change within a controlled window. When it may be less suitable. If local and cloud users must coexist for weeks, share free/busy or migrate in numerous waves, assess hybrid options.

Official reference: Microsoft – Exchange cutover migration.

Hybrid Migration and Minimal Hybrid

Hybrid configuration connects Exchange Server and Exchange Online for gradual transition and coexistence of local and cloud mailboxes. Full Hybrid. May suit longer coexistence periods. Minimal Hybrid. Microsoft also provides Minimal Hybrid for selected scenarios using Hybrid Configuration Wizard without maintaining full long-term hybrid configuration.

Staged OutlookAnywhere is no longer a generic recommendation. Microsoft retired Staged OutlookAnywhere onboarding on 8 May 2025. Older articles recommending it as the standard batch method need review. Assess supported hybrid routes and current versions for new gradual migrations. Official reference: Microsoft – Staged migration retirement information.

Migrating Google Workspace to Exchange Online

Microsoft currently provides automated migration from Google Workspace to Exchange Online through Exchange Admin Center, covering:

Google Workspace	Exchange Online
Gmail	Email and folders.
Google Calendar	Exchange calendars.
Google Contacts	Contacts.
Rules	Within the method’s documented capabilities.

This differs from generic IMAP. Treating Gmail solely as IMAP misses specific calendar, contact and other migration mechanisms. Google environment preparation. Configure: administrative access, Google Cloud project and permissions where required, destination users, domains, routing and Exchange Online prerequisites.

Users can migrate in batches. This supports phased projects and temporary coexistence or routing where required. Official reference: Microsoft – Automated Google Workspace migration to Microsoft 365.

Google Workspace delegations, rooms, resources and tasks

Microsoft’s evolving Google Workspace migration documentation also covers elements historically requiring manual work. Specific procedures address:

Google element	Current Microsoft handling
Mailbox permissions	Specific procedure.
Delegates	Mapping into Exchange Online.
Rooms	Documented procedure.
Resources	Documented procedure.
Tasks	Specific procedure.

These Google-specific capabilities should not be assumed for generic IMAP providers. Official reference: Microsoft – Migration of Permissions, Delegates, Rooms, Resources and Tasks from Google Workspace.

Migrating IMAP email to Office 365

An IMAP → Exchange Online is common with hosting providers and platforms exposing Internet Message Access Protocol mailboxes. It transfers messages effectively, with limits that should be explained beforehand.

Element	Does IMAP migrate it?
Email	Yes.
Email folders	Yes.
Contacts	No.
Calendar	No.
Tasks	No.
Rules	Not through IMAP.
Delegations	Not through IMAP.

Current native IMAP migration limits. Microsoft’s current procedure documents limits including:

Limit	Documented value
Items per mailbox	Up to 500,000 items.
Maximum migrated message size	35 MB.

Microsoft processes newest messages first. Recheck these limits before projects because they may change. Destination mailboxes must exist first. Create users and provision Exchange Online mailboxes before IMAP migration.

Source concurrency matters

Hosting providers may limit connections by user, IP or server. Source throughput may constrain performance even if Exchange can receive quickly. Test throughput before committing large-project schedules. Official reference: Microsoft – What you need to know about migrating IMAP mailboxes.

Have IMAP accounts and uncertainty about preservation?

We can review provider, sizes and calendar/contact usage before treating every user data type as included.

Assess IMAP to Microsoft 365 migration

Migrating POP3 email to Microsoft 365

POP3 needs different assessment, primarily to identify where data resides. Traditional POP clients download messages and may remove server copies. A 15 GB Outlook mailbox could leave only 500 MB at the hosting provider. Before pricing POP migration.

Identify whether:

Situation	Potential strategy
Provider supports IMAP and retains everything	Assess IMAP migration.
Email resides in PST files	Assess PST import or processing.
History is spread across computers	Discovery and collection are needed first.
Server and local stores contain different data	Design consolidation avoiding duplicates.

POP can therefore require more work than apparently equivalent IMAP migration.

Zimbra, cPanel, Dovecot and other providers

Zimbra may provide more than IMAP, while cPanel hosting may restrict practical access to IMAP/POP. Provider brand alone does not define scope. Check: available protocols and APIs, calendar and contact locations, export formats and specialist tool support.

Example. If usable Zimbra access is IMAP-only, email migrates through IMAP despite calendar capabilities. A tool with specialist calendar and contact access can support a different scope.

HCL Domino / Notes migration

HCL Domino and HCL Notes are current names for the platform often called Lotus Domino, Lotus Notes or IBM Notes. Separate mailboxes from business applications developed on the platform.

Component	Potential destination
Email	Exchange Online.
Calendar	Exchange Online through a compatible tool.
Contacts	Exchange Online through a compatible procedure.
Directory / Groups	Appropriate Microsoft object design.
Domino Applications	Separate modernisation or replacement project.
NSF Databases	Depends on content and function.

A Domino application does not migrate into Outlook. It may need a new application, Power Platform, SharePoint, Dynamics, Azure or another solution. Prepare two inventories: email and collaboration on one side and applications and databases on the other.

Moving mailboxes between Microsoft 365 tenants

Microsoft currently provides Cross-Tenant Mailbox Migration for Exchange Online mailbox moves between Microsoft 365 organisations, commonly supporting mergers, acquisitions, carve-outs and consolidation.

This is not a conventional mailbox copy

Microsoft uses Exchange Online PowerShell and MRS. Prepare the destination user as a MailUser with attributes relating it to the source mailbox.

Element	Consideration
Destination MailUser	Must exist and be correctly prepared.
ExchangeGUID	Required for mapping.
Cross-tenant licence	Required under current Microsoft documentation.
Hold	Mailboxes under any type of hold cannot use this method.
Domain	Plan it independently from the mailbox.
Mail routing	Needed during coexistence.

Content Microsoft moves. Microsoft currently documents user-visible content such as: email, contacts, calendars, tasks and notes. Source behaviour. After a successful move, the source mailbox is no longer available as a mailbox and becomes a MailUser for certain coexistence and routing scenarios. Understand the distinction between copying tools and a native mailbox move.

Official reference: Microsoft – Cross-Tenant Mailbox Migration.

Shared mailboxes, rooms and resources

Non-user objects often cause more incidents than standard mailboxes. Shared Mailboxes. Establish:

Information	Why it matters
Size	May affect licensing and method.
Full Access	Users permitted to open the mailbox.
Send As	Users permitted to send as the address.
Send on Behalf	Delegated sending.
Archive	May need specific handling.
Applications	CRM or ticketing may use the address.

Rooms and Resources. Document booking rules, delegates, hours and restrictions. Moving calendar content without functional configuration can leave a technically present resource unusable.

Permissions and delegations

Review relationships between users, for example: Laura has full access to Administration and Pedro can send as facturacion@empresa.com. Both mailboxes may transfer perfectly while the business considers migration unsuccessful if those relationships disappear.

Permission	Use
Full Access	Open an additional mailbox.
Send As	Send using the mailbox identity.
Send on Behalf	Send on behalf of another person or mailbox.
Calendar permissions	Access calendars at different levels.

Preservation or reconstruction of relationships depends on source and product.

Online Archive, PST and historical data

Historical volume can significantly alter a project. Exchange Online Archive. For archive users, check: volume, destination licensing, method and archive mailbox handling. PST files. PSTs may come from older Exchange, POP3 or local Outlook history. Review before import:

Aspect	Reason
Duplicates	Some content may already exist on the server.
Owner	Identify the correct mailbox.
Date	Very old content may have no operational value.
Size	Affects time and storage.

Domains and SMTP addresses

Mailbox migration and domain change are related but separate tasks. Inventory: SMTP domains, primary addresses, aliases, lists, shared mailboxes and applications using the domain. Example. A user may sign in as: jperez@dominiointerno.local and send email as: juan.perez@empresa.com Define their Microsoft 365 identity and retained addresses.

Tenant-to-Tenant. Custom domains need special planning because the same domain cannot remain assigned identically to both tenants. Resolve source dependencies before release.

MX, Autodiscover, SPF, DKIM and DMARC

DNS is integral to email migration.

Record	Function	Review timing
MX	Specifies email delivery destination.	Particularly during cutover.
Autodiscover	Helps Exchange clients locate services.	During preparation and change.
SPF	Declares authorised senders.	Before and after transition.
DKIM	Cryptographically signs outgoing messages.	After domain and corresponding DNS preparation.
DMARC	Specifies domain authentication policy and reporting.	Coordinate with SPF and DKIM.

SPF alone is insufficient. Microsoft currently recommends combining SPF, DKIM and DMARC in email authentication strategy. Remember other senders. Before changing SPF, identify: ERP, CRM, websites, payroll applications, printers, scanners, monitoring, ticketing and marketing services. Some retain direct sending while others change method. Official references:

Applications, devices and SMTP after migration

One major risk is focusing on users while overlooking automated senders. Common examples.

System	Usage example
ERP	Invoices and orders.
CRM	Sales notifications.
HR	Payroll or notices.
Web	Contact forms.
Printers	Scan-to-email.
Monitoring	Technical alerts.
Internal applications	Transactional messages.

Do not automatically carry forward old SMTP settings

Exchange Online has removed Basic Authentication for several protocols, while SMTP AUTH is moving towards modern mechanisms. For new configurations assess:

Method	Potential use
OAuth / Modern Authentication	Compatible applications needing SMTP AUTH.
Microsoft Graph	Modern API-based sending applications.
SMTP Relay	Specific application and device scenarios.
High Volume Email	Large volumes of automated internal email.
External services	Bulk mailing or scenarios unsuitable for Exchange Online.

Selection depends on internal or external recipients, volume, authentication and application architecture. Official references:

MFA and destination security

Migration should adopt modern identity and MFA rather than reproduce old server authentication unchanged. Administrator accounts. Use multifactor authentication and only necessary privileges. Users. Depending on licensing, use Security Defaults or designed Conditional Access policies. Legacy authentication. Avoid new username-and-password dependencies where modern alternatives exist.

Migration tools. Document required application or administrative access, review it afterwards and remove it when no longer needed.

Tools for migrating email to Microsoft 365

The appropriate tool depends principally on source.

Tool / method	Main scenario
Exchange Admin Center	Google Workspace, IMAP and other supported native batches.
Exchange Hybrid	Exchange Server coexistence.
Cross-Tenant Mailbox Migration	Exchange Online → Exchange Online.
Quest On Demand Migration	Tenant-to-tenant and broad Microsoft 365 projects.
BitTitan MigrationWiz	Google, IMAP, Exchange and other email projects.
CodeTwo Office 365 Migration	Guided Exchange and mailbox migration.
Cloudiway	Cross-platform and tenant-to-tenant.
AvePoint	Enterprise multi-workload projects.
PowerShell	Inventory, preparation and automation.

Mailbox count alone does not select tools. Fifty Exchange mailboxes with archives and delegation may need different technology from fifty simple IMAP accounts.

Unsure which tool is needed?

Compare source, required data, mailbox count and schedule before buying migration licences.

Compare options for my email migration

Pilot, prestaging and synchronisation

For complex projects, a pilot reduces uncertainty. Include more than one straightforward user.

Case	What we check
Standard mailbox	Normal operation.
Large mailbox	Throughput and timings.
User with an archive	Historical content.
Shared Mailbox	Content and permissions.
User with delegations	Mailbox relationships.
Complex calendar	Google or Domino outcomes.
User with a connected application	Authentication or SMTP dependencies.

Pre-stage. Many tools copy most email in advance while users remain at source, then synchronise changes in later passes. Methods behave differently. Native cross-tenant migration may move mailboxes while third-party platforms use copy and delta. This significantly changes cutover procedures.

Preparing the cutover window

Document cutover as a runbook.

Phase	Activity
Pre-check	Check users, licences, tools and jobs.
Delta	Run final synchronisation where appropriate.
Mail flow	Change MX or routing.
DNS	Apply planned changes.
Applications	Update sending systems.
Validation	Test internal and external email.
Pilot users	Confirm access and operation.

Lowering TTL before transition. Where DNS is administered and providers permit, review TTLs beforehand to assist changes, according to environment and provider.

Validating email migration

Migration does not end when MX points to Microsoft 365.

Test	Expected result
Login	User authentication succeeds.
Outlook on the web	Mailbox accessible.
Internal email	Correct delivery.
External incoming email	Delivery into Exchange Online.
External outgoing email	Successful, authenticated delivery.
Calendar	Expected information available.
Contacts	Available where included in scope.
Shared Mailboxes	Correct users have access.
Send As	Delegations validated.
Rooms	Bookings work correctly.
Apps	Included systems can send messages.
SPF/DKIM/DMARC	Configuration matches the new architecture.

Content comparison. Where tool statistics exist, review counts, errors and skipped items. A few incompatible items do not necessarily invalidate the migration, but require documentation and assessment.

Outlook, mobiles and computers after migration

Exchange service migration differs from individual device configuration. Users may need to: sign in again, add accounts, recreate profiles, re-register MFA or update clients. Intervention varies by migration. Well-designed Exchange moves may allow Outlook to adapt with little intervention.

A move from an unrelated IMAP provider may require a new Exchange configuration. Kloudeal scope. We can prepare instructions and coordinate necessary actions with client IT. Individual computer or device intervention is included only where explicitly stated in the contracted scope.

How long email migration takes

User count alone cannot determine the schedule.

Factor	Impact
Mailbox count	Increases operational volume.
GB per mailbox	Increases transfer time.
Item count	Can significantly affect throughput.
Source	Exchange, Google and IMAP behave differently.
Source limits	Connection restrictions and throttling can slow transfer.
Archives	Add volume.
Coexistence	May extend total project duration.
Tool	Changes concurrency and delta behaviour.

Estimate after assessment and refine with observed pilot speeds.

What determines email migration pricing

Identical user numbers may produce very different budgets.

Factor	Example
Source type	IMAP, Google, Exchange, Domino…
Mailboxes	Users and shared mailboxes.
Archives	Historical archive migration requirements.
Calendars / contacts	Particularly outside Exchange.
Tool	Licence costs.
Coexistence	Additional configuration.
Domains	Cutover complexity.
Applications	SMTP, SSO or integrations.
Support	Hypercare and subsequent work.

Ten simple IMAP mailboxes require different effort from ten POP mailboxes with fifteen years of local history.

Would you like an assessment?

Provide current provider, approximate mailbox numbers, sizes, shared mailboxes, domains and target date. Calendar, contact and archive details help refine scope.

Request an email migration quotation

Common Office 365 email migration mistakes

Error	Consequence	Better approach
Treating every source as IMAP	Losing fidelity supported by Google or Exchange.	Use specific methods where available.
Expecting calendars through IMAP	Data remains unmigrated.	Define separate handling.
Pricing POP as IMAP	History may reside outside the server.	Locate data first.
Ignoring Exchange 2016/2019 support status	Building a permanent foundation on an obsolete platform.	Review lifecycle and current routes.
Using old staged migration	Following retired documentation.	Assess hybrid or current methods.
Overlooking shared mailboxes	Users lose access or sending capability.	Inventory permissions.
Overlooking archives	Part of the history is excluded.	Include archives in assessment.
Changing MX too early	Email reaches unprepared mailboxes.	Validate destination first.
Changing SPF without inventory	Legitimate applications fail delivery.	Identify all senders.
Reusing old SMTP authentication	Applications become incompatible with current Exchange Online.	Assess OAuth, Graph, relay or other options.
Skipping the pilot	Problems emerge in production.	Test complex cases.
Promising zero impact	Unrealistic expectations.	Explain transition requirements.
Assuming configuration of 300 PCs is included	Uncontrolled scope.	Separate cloud and endpoint migration.
Closing when the job finishes	Undetected incidents.	Functional validation.

Checklist before Microsoft 365 email migration

Check	Recommended state before cutover
Source platform identified	Confirmed.
Exchange version where applicable	Documented.
Users	Inventoried.
Mailbox sizes	Known.
Shared Mailboxes	Inventoried.
Archives	Identified.
Rooms and Resources	Identified.
Contacts	Handling defined.
Calendars	Handling defined.
Permissions	Inventoried.
SMTP aliases	Documented.
Domains	Prepared.
MX	Change prepared.
Autodiscover	Reviewed.
SPF	All senders known.
DKIM	Configuration prepared.
DMARC	Strategy reviewed.
SMTP applications	Inventoried.
Microsoft licences	Prepared.
Migration tool	Selected.
Pilot	Completed.
Runbook	Documented.
Communication	Users informed.
Endpoint configuration owner	Assigned.
Validation	Criteria agreed.
Hypercare	Planned.

Frequently asked questions about Office 365 email migration

What information determines the email migration method?

Source system, data types and continuity needs drive selection, alongside shared mailboxes, archives, delegations and sending applications. Check preservation capabilities and separately required preparation or configuration before deciding.

Are Outlook and mobile devices reconfigured automatically?

Do not assume this without scenario review. Define clients, devices, sign-in arrangements and incident owners. Use those devices in the pilot to identify actual support tasks and prepare instructions before wider change.

How should a migrated shared mailbox be checked?

Check content and required actions with authorised accounts. Validate access and sending permissions plus relevant applications or rules. Correct message copying does not establish working delegation or departmental processes.

What distinguishes a completed migration from a completed copy?

A copy demonstrates scoped transfer. Migration also requires working recipients, access, mail flow and included processes. Acceptance relates tests to known exceptions and owners before deciding source retirement timing.

Final recommendations: email migration involves more than changing MX

Migrating email to Office 365 or Microsoft 365 may seem straightforward, but outcomes depend on understanding the source. Exchange Server offers rich native methods and hybrid coexistence where necessary. In 2026, Exchange 2016/2019 projects must consider their October 2025 general support end.

Google Workspace has specific Microsoft procedures for Gmail, calendars, contacts and other settings, so generic IMAP may discard capabilities. IMAP suits messages and folders but excludes calendars, contacts and tasks. POP3 starts by locating history; Domino requires separating email from business applications.

Tenant-to-tenant adds identity, domain, licensing, routing and compliance dependencies. Commonly overlooked elements include shared mailboxes, permissions, archives, rooms, DNS and automated senders. At Kloudeal we identify the platform, preservation requirements and intended operating model before Exchange Online becomes production.

Then we select methods, pilot, premigrate where supported, coordinate cutover and validate. The objective is that users can send, receive, consult calendars, use shared mailboxes and continue working in Exchange Online with coherent, manageable configuration.

Need to migrate business email to Microsoft 365?

We can help migrate from Exchange Server, Google Workspace, IMAP, POP3, Zimbra, HCL Domino or another Microsoft 365 tenant. Depending on the scenario, scope can include assessment, Exchange Online, users, shared mailboxes, calendars, contacts, archives, domains, DNS, MX, SPF, DKIM, DMARC, tools, pilot testing, cutover, validation and subsequent support. Tell us your platform, approximate mailbox count and target date so we can identify information needed for a proposal.

Request an email migration assessment

Designing an email acceptance pack for the business

An email acceptance pack brings together the evidence needed to decide whether the organisation can work from the destination. It should be organised around actual services and users, with supporting technical reports available for detail. The aim is to answer clear questions: is the required information available, can the correct people access it, does email flow as designed and do the included business processes work? These questions remain useful across different source platforms and migration tools.

Start preparing the pack during assessment rather than after transfer. Identify who can validate ordinary mailboxes, shared addresses, calendar use and automated senders. Record representative cases that those owners recognise. A known invoice, a recurring meeting or a departmental conversation can be more useful than an arbitrary sample because the owner understands its expected behaviour. Technical sampling and business examples complement one another rather than competing as alternative forms of proof.

Define the mailbox inventory in operational terms

For each relevant account or address, record its purpose and owner alongside technical details. Distinguish a personal mailbox from a shared departmental resource or an application identity. Note the access and sending actions that must remain available. The inventory then becomes a reference for testing rather than only a list used to create jobs. It also helps explain why two mailboxes of similar size may need different preparation and validation effort.

Historical repositories need the same clarity. Record where the information is stored and what is included in the agreed transfer. If a local archive is excluded or handled through another procedure, describe the practical consequence and its owner. Users often understand their email history as one body of information even when it is technically spread across several stores. The acceptance record should make those boundaries understandable before someone searches for an item after cutover.

Choose samples that reveal meaningful differences

A useful sample covers older and recent messages, internal and external correspondence and relevant attachments. Include examples from folders or labels that matter to the user. Record the expected destination organisation according to the chosen method. This avoids interpreting every presentation difference as missing content while still requiring a clear explanation for actual omissions. Counts support the review, but a count without scope and method context cannot describe every aspect of preservation.

Where calendars and contacts are included, give them explicit test cases. Ask a user to locate a known contact and complete the normal action associated with it. For a meeting, confirm the expected details and the actions required by the business. Use the selected method’s documented scope as the reference. If an element is rebuilt or handled separately, the acceptance pack should identify that work rather than imply it was automatically included in message transfer.

Validate shared resources with authorised accounts

A shared mailbox test should use the accounts of people who need it. Check opening the resource, finding relevant content and performing the intended sending action. If different users have different responsibilities, test those distinctions. The presence of a destination mailbox does not establish correct delegation. Nor does successful administrator access demonstrate that ordinary users can work with the intended boundaries.

Include a restricted-access check where appropriate. An account outside the department should not gain access simply because permissions were reconstructed broadly to resolve an urgent incident. If a test fails, record the identity and action precisely. The technical team can then investigate mapping or permission configuration without changing unrelated settings. This makes correction more controlled and provides evidence that restoring one person’s access has not unnecessarily widened it for others.

Test mail flow from several perspectives

Prepare sending and receiving tests involving internal and external recipients. Include the primary address, important aliases and departmental addresses. Record where the message arrives and the sender identity presented to the recipient. These observations help distinguish routing, recipient configuration and access problems. A successful internal message is useful evidence, but does not establish that an external customer can reach every business address.

Where the design requires authentication validation, retain relevant results from actual messages. Configuration records show what was intended; message tests show the behaviour observed for a particular sending route. Include the relevant application senders as well as user mailboxes. If different platforms send using the domain, their tests should remain distinct so a success from one source does not conceal an unresolved issue in another.

Follow automated messages from business action to recipient

Ask each application owner to identify the action that generates a message. It may be an invoice, a form submission, a support update or an operational alert. Trigger that action in the agreed test context and verify the resulting delivery. Record which configuration has changed and who maintains it. This checks the complete process instead of assuming that an application works because its SMTP details were updated.

When an automated sender fails, separate message generation from transport and delivery. The application may not have produced a message, may still use an old route or may encounter an authentication problem. A precise record helps assign the issue to the appropriate team. Avoid using a successful user mailbox test as the reason to close an application incident, since the two may rely on different settings and responsibilities.

Include the clients users actually work with

The pilot should reflect the clients and devices included in scope. Ask users to complete the normal sign-in and email journey, following the instructions planned for wider rollout. Record expected reauthentication or configuration actions and distinguish them from failures. This provides a realistic support estimate and gives internal IT a chance to prepare before many people encounter the same transition step.

Make device responsibilities explicit. The provider may migrate the service while the client’s team configures individual computers or mobile devices. Both tasks can be necessary, but one does not imply the other is included. The acceptance pack should identify which team handles the user journey and what evidence confirms readiness. This avoids a gap in which data is available at destination but nobody owns the work required for employees to reach it.

Review exceptions without losing the overall state

Classify outstanding items by impact and next action. A known unsupported item, a failed transfer, an incorrect permission and a new user request need different treatment. Explain each in relation to agreed scope. The owner can then decide whether correction is required before wider change, whether an alternative is acceptable or whether additional work needs a separate decision. A global error count does not provide that business context.

Retain evidence of corrections. Repeat the action that failed and record the new result. If a shared configuration changes, include the related checks needed to confirm that other users or senders still work. This is more useful than simply marking an incident resolved because a setting was edited. It also gives the receiving support team a clear explanation if a similar problem is reported later.

Make closure a deliberate operational decision

Before source retirement, review acceptance by service and the dependencies still using the previous environment. Identify any retained archive, application route or follow-up task with an owner and completion condition. The source should not remain indefinitely without explanation, but it should not be removed merely to demonstrate that transfer jobs have finished. Closure follows the approved evidence and retention decisions relevant to the project.

Hand over the final inventory, important configuration, test results, accepted differences and outstanding actions. Explain the support channel and escalation route for the initial period. The business should know where its email now operates and who is responsible for maintaining it. That is the practical distinction between copied messages and a completed migration service: the destination is understood, usable and supported within the agreed scope.

A final review with the internal support team is useful before the wider completion notice. Walk through the most important user journeys and show where the supporting evidence is stored. Confirm who investigates content questions, who handles permissions and who owns application sending. If an incident remains open, explain its impact and accepted alternative in practical language. This gives support a shared understanding of the delivered service and prevents users receiving conflicting instructions. It also makes the handover independent of the person who ran the migration tool, because another administrator can locate the relevant record and repeat the checks.

The handover owner records this review with the agreed acceptance results and confirms the next action for any outstanding issue.