Kloudeal Journal · Business guide
Microsoft 365 migration services should specify source systems, configuration to rebuild and acceptance criteria. This guide explains proposal review and the coordination of email, documents, identities and collaboration.
Data, configuration and service exclusions.
Tools, dependencies and agreed windows.
Validation, documentation and contracted support.
Contents of this guide
Which platform are you migrating from?
| Source | Typical content | Main consideration |
|---|---|---|
| Google Workspace | Gmail, calendars, contacts, Google Drive and Shared Drives. | Separate email from documents and map identities correctly. |
| Exchange Server | Mailboxes, calendars, contacts, shared mailboxes, rooms and permissions. | Version, coexistence, identity, applications and hybrid strategy. |
| HCL Domino / Notes | Email, calendars, contacts and transferable data. | Distinguish email from Domino applications and databases. |
| IMAP | Email and folder structure. | Contacts, calendars and tasks are outside IMAP scope. |
| POP3 | Depends on the actual location of historical email. | Much information may be downloaded to computers or PST files. |
| Microsoft 365 | Exchange, OneDrive, SharePoint, Teams and other scoped components. | Identity, domains, mappings and workload dependencies. |
| File server / NAS | Documents and folders. | Decide what belongs in SharePoint and OneDrive. |
Want to understand your migration requirements?
With the source, approximate users, volume, domains and target date, we can perform an initial review and identify information needed to define scope.
Request a Microsoft 365 migration assessmentComparing Microsoft 365 migration services
Proposals with identical user counts may cover very different work. Compare preliminary analysis, preparation, transfer, validation and support, alongside included workloads and separate projects. Without detail, prices may appear comparable while expected outcomes differ.
For example, mailbox migration may cover content alone or also Outlook access, mobile devices and sending applications. This changes first-day experience and internal effort. Assign owners and delivery conditions to tasks, particularly across providers, IT and business teams.
Explain the practical consequences of exclusions. If an application does not support the method or history exists only on local computers, identify who resolves it and whether it affects scheduling. This enables informed approval with visibility of unresolved dependencies.
Documentation and support the service should leave behind
Handover should explain completed and outstanding work to the operating team. Provide final inventory, destination decisions, transfer reports and test results. Separate accepted differences from incidents requiring correction, with owners and next actions.
Define support channels, coverage and escalation criteria. Newly discovered needs require assessment of impact, solution and scope change before entering the schedule. This prevents undocumented expectations becoming disputes once users work at destination.
What a Microsoft 365 migration service involves
Professional migration coordinates source, destination, identity, licences, tools, domains, security and validation alongside data transfer. Two organisations with 100 email accounts can need very different projects: small IMAP mailboxes without shared calendars versus Exchange Server with 80 GB mailboxes, archives, rooms, delegations, SMTP applications and Active Directory synchronisation.
A reliable assessment distinguishes those scenarios.
| Phase | Expected result |
|---|---|
| Discovery | Understand users, data, domains, applications and exceptions. |
| Design | Determine destinations and transition arrangements for each service. |
| Preparation | Configure tenant, users, licences, security and tools. |
| Pilot | Check the method through actual cases. |
| Premigration | Move information in advance where supported. |
| Cutover | Execute final email, identity or domain changes. |
| Validation | Technically verify included services. |
| Hypercare | Resolve transition-related incidents. |
When migration to Microsoft 365 makes sense
Business needs may include retiring Exchange Server, replacing old email hosting, integrating an acquisition, leaving Google Workspace, modernising HCL Domino or moving local documents to SharePoint and OneDrive. Broader objectives may centralise identity and collaboration in Microsoft’s ecosystem.
Migration works best with a clearly defined future state. Moving everything without reviewing usefulness can mean paying to transfer obsolete information, old accounts and unnecessary structures.
What a Microsoft 365 migration can include
Scope reflects the source. Components differ across platforms and cannot all retain the same fidelity.
| Component | Potential project scope |
|---|---|
| Exchange Online | Email, calendars, contacts, archives, shared mailboxes, rooms and resources according to source. |
| Domains | DNS validation, configuration and coordination. |
| Microsoft Entra ID | User, group and identity preparation according to architecture. |
| OneDrive | Users’ personal work data and content. |
| SharePoint Online | Shared documentation, sites and libraries. |
| Microsoft Teams | Preparation or migration of components according to source and technology. |
| Security | MFA and initial controls according to licensing and scope. |
| Applications | Inventory and reconfiguration of explicitly included integrations. |
| DNS and mail flow | MX, Autodiscover, SPF, DKIM, DMARC and related connectors. |
Explicitly state inclusions and exclusions, particularly for Teams, Domino or Power Platform, where “migration” can mean very different work.
Google Workspace to Microsoft 365 migration
Google Workspace is a source with specific Microsoft migration routes. Separate at least two information groups: email, calendars and contactson one side, and Google Drive / Shared Driveson the other. These workloads may use different tools and processes.
Gmail, calendars and contacts
Microsoft documents a Google Workspace to Exchange Online route supporting batches and transfer into prepared Microsoft 365 mailboxes.
| Google Workspace | Typical destination |
|---|---|
| Gmail | Exchange Online |
| Google Calendar | Exchange Online calendar |
| Google Contacts | Mailbox contacts |
| My Drive | Usually OneDrive |
| Shared Drives | Usually SharePoint |
| Identities | Microsoft Entra ID |
Review users, domains, administrator permissions, APIs, account mapping and MX timing before execution. Official reference: Microsoft – Perform a Google Workspace migration to Microsoft 365. A Google migration also changes working practices. Moving Gmail users to Outlook and Exchange changes more than the server.
It may also change:
| Beforehand | Afterwards |
|---|---|
| Gmail | Outlook / Exchange Online |
| Google Calendar | Outlook Calendar |
| Google Meet | Microsoft Teams where included in strategy |
| Google Drive | OneDrive / SharePoint |
| Google Docs | Microsoft 365 Apps and compatible formats according to content |
Design communication around the changes users actually experience.
Google Drive and Shared Drives migration
Microsoft currently uses Migration Manager for Google Workspace file migration. The workflow connects Google, scans, reviews destinations, maps identities and executes migration. It distinguishes personal and shared drives, which informs OneDrive or SharePoint selection. My Drive does not always equate to OneDrive.
Although both are user-associated storage, My Drive may hold departmental or process-owned content. Identify this to avoid corporate documentation depending on one individual’s account.
Shared Drives
Shared Drives generally align more closely with SharePoint sites or libraries because information belongs to teams or the organisation rather than an individual.
| Before migrating Google Drive | What we review |
|---|---|
| Identities | Google users and groups against Microsoft users and groups. |
| Permissions | Internal and external access. |
| Destination | OneDrive or SharePoint. |
| Shared content | Avoid individual-account dependencies. |
| Google formats | Check handling of platform-specific file types. |
Official reference: Microsoft – Migrate Google Workspace to Microsoft 365 with Migration Manager.
Planning to leave Google Workspace?
We can assess Gmail, calendars, contacts, My Drive, Shared Drives, domains and users separately to define realistic scope and sequencing.
Assess Google Workspace to Microsoft 365 migrationExchange Server to Exchange Online migration
Where the source uses Exchange Server, Microsoft 365 can receive email, calendars, contacts and other mailbox items through native Exchange methods. Architecture depends on Exchange version, user numbers, transition duration and coexistence requirements.
| Element | What we review |
|---|---|
| Exchange version | Determines supported methods and strategy. |
| Mailboxes | Count, size and growth. |
| Archives | Volume and destination licensing. |
| Shared mailboxes | Content and delegations. |
| Rooms and resources | Booking and calendar settings. |
| Permissions | Full Access, Send As and other delegations. |
| Applications | SMTP, relays, authentication and connectors. |
| Identity | Active Directory, UPNs and synchronisation. |
| Coexistence | Duration of on-premises and Exchange Online overlap. |
Cutover, hybrid and other Exchange methods
Microsoft documents several Exchange Server to Exchange Online routes. Cutover. May suit concentrated transition windows, but user count alone does not justify selection. Version and other dependencies still matter. Hybrid migration. Hybrid configuration supports local and cloud mailboxes during progressive moves.
Particularly relevant to coexistence and wave-based migration. Minimal Hybrid / Express Migration. Microsoft documents Minimal Hybrid for organisations using Hybrid Configuration Wizard for a relatively quick transition without long-term hybrid coexistence. Staged OutlookAnywhere. Treat older documentation carefully. Microsoft retired Staged OutlookAnywhere onboarding on 8 May 2025. New progressive onboarding projects from older environments should assess other supported methods, including appropriate hybrid procedures.
Official reference: Microsoft – Staged migration notice. PST. PST files may be appropriate sources but should not automatically replace a complete Exchange Server strategy. Microsoft provides an import service where PST files genuinely contain the information to transfer. Official reference: Microsoft – Ways to migrate multiple email accounts to Microsoft 365.
HCL Domino / HCL Notes to Microsoft 365 migration
Many organisations still use the names Lotus Notes, Lotus Domino or IBM Notes. The family is currently marketed as HCL Notes and HCL Domino. Unlike straightforward IMAP, Domino may contain much more than email.
| Domino component | Potential destination |
|---|---|
| Exchange Online | |
| Calendar | Exchange Online |
| Contacts | Exchange Online |
| Groups | Microsoft 365 objects according to function. |
| Documentation | SharePoint or another repository according to structure. |
| Domino applications | No automatic equivalent; individual assessment required. |
| NSF databases | Entirely dependent on content and usage. |
Separate email and applications during assessment. A Domino application does not become a Microsoft 365 application through mailbox migration. It may need to be: temporarily retained, redesigned, replaced, moved to Power Platform or migrated using specialist technology, according to purpose. Inventory Domino applications and databases separately.
Calendars and collaboration. Assess shared calendars, resources, workflows and Notes functions to understand dependent business processes as well as preserve messages. Official reference: HCL – Notes and Domino product rebranding.
IMAP to Microsoft 365 migration
An IMAP to Exchange Online migration suits sources exposing that protocol, including hosting providers, Dovecot, Courier and certain cPanel environments. Its standard email-reading mechanism is both its strength and limitation: IMAP covers email and folders rather than a complete modern mailbox.
| Element | IMAP migration |
|---|---|
| Messages | Yes |
| Email folders | Yes, according to structure and compatibility. |
| Contacts | No |
| Calendars | No |
| Tasks | No |
| Rules | Not through IMAP |
| Client configuration | No |
Microsoft requires destination mailboxes before IMAP transfer starts. What we review beforehand. In particular: server, port, encryption, authentication, credentials, mailbox sizes, item counts, special folders, provider limits and concurrency restrictions. New messages after an initial pass. Plan for messages still arriving at source during transition.
Depending on the tool, subsequent synchronisation or another cutover strategy may be necessary. Official reference: Microsoft – IMAP migration to Microsoft 365.
Migration from POP3
POP3 needs separate treatment because the server may not retain the full mailbox. Clients often downloaded messages and removed server copies. Recent months may remain online while complete history is spread across computers.
The first question is not how many POP accounts exist.
Ask: Where are all messages that must be retained actually stored?
| Situation | Potential strategy |
|---|---|
| Provider also supports IMAP and retains all email | Assess IMAP migration. |
| History resides in Outlook | Locate PST or other local stores. |
| Data is split across server and local storage | Combine procedures while avoiding duplicates. |
| Data location is unknown | Perform discovery before pricing a standard IMAP migration. |
POP migration may require more operational work than IMAP despite identical user counts.
Zimbra, Dovecot, cPanel and other email systems
“Zimbra to Microsoft 365” or “cPanel to Microsoft 365” does not define a procedure. Identify source interfaces and information to retain. IMAP-only access carries IMAP limitations; APIs, specialist exports or natively supported third-party tools may preserve additional components.
| Information | What we need to understand |
|---|---|
| Available IMAP, API or export. | |
| Calendar | Format and access method. |
| Contacts | Export format. |
| Distribution | Existing lists and groups. |
| Domains | DNS and addresses used. |
Microsoft 365 tenant-to-tenant migration
A Microsoft 365 tenant-to-tenant migration commonly supports mergers, acquisitions, separations and consolidation. It is complex because identical products belong to different directories and organisations. There is no single button to move the entire tenant. Coordinate the workloads.
| Workload | Consideration |
|---|---|
| Exchange Online | Mailboxes, routing, domain, permissions and archives. |
| OneDrive | Identity, content, permissions and sharing. |
| SharePoint | Sites, owners, metadata, permissions and associated teams. |
| Microsoft Teams | Teams, channels, chats, meetings, files and apps according to tool. |
| Microsoft Entra ID | Users, groups, hybrid identity and applications. |
| Domains | Transfer and dependencies. |
| Applications | App Registrations, SSO, SCIM, OAuth and Graph. |
Microsoft native capabilities. Microsoft currently provides dedicated Exchange Online, OneDrive and SharePoint cross-tenant tools. In addition, Microsoft 365 Migration Orchestrator coordinates specific user data including Exchange Online, OneDrive, Teams chats and meetings within documented scope. Microsoft clarifies that it moves content rather than identities; shared data such as SharePoint sites and Teams or channel structures require separate strategies.
Official reference: Microsoft – Migration Orchestrator Overview.
Specialist tools
We can assess Quest On Demand Migration, ShareGate, BitTitan, Cloudiway or AvePoint according to workloads, deltas, coexistence, identity, volume and fidelity requirements.
Need to consolidate or separate Microsoft 365 tenants?
We can review Exchange, OneDrive, SharePoint, Teams, domains, users, groups and applications before tool selection and scope approval.
Assess tenant-to-tenant migrationMigration from file servers, NAS and other repositories
Microsoft 365 migration may include Windows server, NAS or other repository documents. Decide information organisation before copying files.
| Source | Destination decision |
|---|---|
| Personal user folder | May suit OneDrive. |
| Departmental folder | Usually assess SharePoint. |
| Shared project | SharePoint or an associated team according to collaboration needs. |
| Historical archive | Assess migration, archiving or retention outside the active environment. |
Analyse volume, item count, paths, names, permissions, owners and potential exclusions beforehand.
OneDrive and SharePoint are not interchangeable destinations
A practical distinction asks who owns the content.
| OneDrive | SharePoint |
|---|---|
| Information mainly associated with the user. | Information belonging to the organisation or a team. |
| Personal work documents. | Departmental documentation. |
| Individual work in progress. | Shared projects and processes. |
| Occasional sharing. | Structured permissions and collaboration. |
A corporate folder used by ten employees should not automatically move into a department manager’s OneDrive merely because that manager held source permissions.
Users, groups, domains and identity
Data needs destination identities. Prepare users and groups before operations whose permissions, ownership or metadata depend on them. Design reviews include: UPNs, SMTP addresses, domains, duplicate users, old accounts, groups, hybrid identity and dependent applications. Microsoft Entra ID. Microsoft Entra ID is Microsoft’s identity service, formerly Azure Active Directory.
It can operate entirely in cloud or synchronise with on-premises Active Directory in hybrid architecture. The corporate domain. A new-tenant migration may allow verification and preparation beforehand. Tenant-to-tenant transfer requires stricter planning because the same custom domain must be released from source after its dependencies are resolved.
MX, Autodiscover, SPF, DKIM and DMARC
DNS concentrates important email cutover work.
| Record / technology | Function |
|---|---|
| MX | Determines incoming email delivery. |
| Autodiscover | Helps Exchange clients locate services. |
| SPF | Identifies authorised domain senders. |
| DKIM | Signs messages sent from the domain. |
| DMARC | Defines email authentication policy and reporting. |
SPF changes must include more than Microsoft 365. Before cutover, identify other senders: CRM, ERP, web applications, printers, ticketing, newsletters and every service using the corporate domain. Undocumented senders may fail after transition.
Applications and integrations
Integrations are easily omitted from email scope and can generate significant later incidents.
| Integration | Potential change |
|---|---|
| SMTP | Server, authentication, relay and senders. |
| SSO | Microsoft Entra ID, tenant, claims and certificates. |
| OAuth | Consent grants, client ID, secrets or certificates. |
| SCIM | Provisioning and mappings. |
| Microsoft Graph | App Registrations, permissions and tenant ID. |
| Backup | Registration and permissions for the new tenant. |
Identify dependencies during assessment. Reconfiguration may be included or assigned to the application provider, but must have an owner.
Security during migration
Establish destination security before production users arrive. Migration should not leave administrators indefinitely without MFA or tools with excessive permissions. MFA. Microsoft is progressively enforcing MFA across administrative portals and tools. Design administrator multifactor authentication and user access accordingly.
Security Defaults and Conditional Access. Security Defaults offers baseline protection without Entra ID P1/P2. With appropriate licensing and granular needs, Conditional Access applies differentiated policies by users, roles, devices, apps and risk. Migration tool permissions. Quest, BitTitan, ShareGate and other Microsoft API solutions may need elevated read and write access.
Document consent grants and review them at closure. Official reference: Microsoft – Mandatory multifactor authentication.
Migration tools we can use
Technology depends on source and workload; one tool does not suit every project.
| Tool / technology | Typical scenarios |
|---|---|
| Exchange Online Migration | Exchange Server, Google Workspace and IMAP according to supported methods. |
| Exchange Hybrid | Coexistence and progressive Exchange Server migration. |
| Migration Manager | Google Drive, Dropbox, file shares and other supported sources into Microsoft 365. |
| SharePoint Migration Tool | SharePoint Server and file shares. |
| Microsoft cross-tenant | Exchange, OneDrive, SharePoint and Orchestrator according to workload. |
| Quest On Demand Migration | Multi-workload Microsoft 365 tenant migration. |
| BitTitan MigrationWiz | Email and SaaS scenarios according to project. |
| ShareGate | SharePoint, OneDrive, Teams and current tenant migration capabilities. |
| Cloudiway | Cross-platform and tenant-to-tenant scenarios. |
| AvePoint | Enterprise and multi-workload migration. |
| CodeTwo | Exchange-focused projects. |
| PowerShell / Microsoft Graph | Discovery, preparation, automation and validation. |
Select tools after understanding scope to avoid unnecessary features or late discovery of unsupported critical components.
How we deliver a migration project
1. Discovery. Gather source users, mailboxes, domains, repositories, sizes, permissions and applications. 2. Scope definition. Separate migration from reconstruction, clean-up, archiving or independent projects. 3. Design. Define destination tenant, licences, identity, security, file destinations, tools, waves and cutover. 4. Environment preparation. Configure agreed Microsoft 365 elements and tool prerequisites.
5. Tool discovery. Compare platform analysis with the initial inventory. 6. Pilot. Select representative users and data. 7. Premigration. Where multiple passes are supported, transfer as much information as appropriate in advance. 8. Cutover. Execute final operations through a prepared runbook. 9. Validation. Check included services with technical reports and functional tests.
10. Stabilisation. Handle migration incidents during the agreed post-change phase.
Why we run a pilot
A pilot turns estimates into actual measurements.
| Case | What to check |
|---|---|
| Standard mailbox | Normal operation. |
| Large mailbox | Performance. |
| Shared mailbox | Permissions and behaviour. |
| Important calendar | Fidelity when source is not Exchange. |
| User with extensive data | Time and errors. |
| Shared content | Permissions and mapping. |
| Integrated application | Authentication and dependencies. |
A pilot may confirm design or prompt tool, mapping, phase or procedure changes before affecting other users.
The change window
Cutover executes changes that cannot remain indefinitely in parallel.
| Activity | Potential cutover inclusion |
|---|---|
| Final synchronisation | Yes, where delta is supported. |
| MX | Yes. |
| Autodiscover | According to strategy. |
| Domain | Particularly critical for tenant-to-tenant projects. |
| Identity | Planned UPN or access changes. |
| Applications | Changes requiring activation in the destination. |
Record sequence, owners, validation and stop conditions in the runbook.
Validation and support after migration
Project closure should follow validation rather than merely completed tool jobs.
| Area | What we validate |
|---|---|
| Identity | Sign-in and MFA. |
| Incoming email | Reception from the internet. |
| Outgoing email | Delivery and authentication. |
| Calendar | Meeting creation and reception where included. |
| Shared mailboxes | Access and permissions. |
| OneDrive | Content and access. |
| SharePoint | Sites, information and permissions. |
| Teams | Included project components. |
| Applications | Explicitly included integrations. |
| DNS | MX, SPF, DKIM, DMARC and other agreed settings. |
Outlook, mobile devices and user computers
Migration may visibly change clients. Depending on source and transition, users may need reauthentication, new accounts, Outlook profile updates or application reconnection. Distinguish this from tenant work. At Kloudeal we can give client IT teams necessary change information and requirements, but individual workstation or device configuration is included only where explicitly defined in scope.
This matters for large quotations: moving 500 Microsoft 365 mailboxes differs from intervening physically or remotely on 500 computers.
Information needed for a proposal
A complete assessment is unnecessary for an initial enquiry. Useful starting information includes:
| Information | Example |
|---|---|
| Source | Google Workspace, Exchange Server, IMAP, Domino, Microsoft 365… |
| Number of users | 125 |
| Shared mailboxes | 14 |
| Approximate size | 2.6 TB of email |
| Calendars and contacts | Migration required / not applicable. |
| Files | Google Drive, Dropbox, NAS… |
| SharePoint / Teams | Existing or requiring migration. |
| Domains | empresa.com, filial.com. |
| Identity | Cloud-only or Active Directory. |
| Target date | Preferred cutover month or date. |
We can help obtain missing information in the initial phase.
Would you like a proposal?
Tell us the source platform, user count and services to move. We will review the scenario and identify further information needed.
Request a Microsoft 365 migration quotationCommon Microsoft 365 migration mistakes
| Error | Problem | Better approach |
|---|---|---|
| Treating all sources identically | Promising items absent from the protocol. | Design for the platform. |
| Treating IMAP as complete migration | Missing calendars and contacts. | Explain scope beforehand. |
| Pricing POP as IMAP | History may reside on local computers. | Locate data first. |
| Treating Domino as email alone | Applications and databases are overlooked. | Inventory them separately. |
| Using outdated Exchange documentation | Attempting a retired method. | Validate current routes. |
| Combining Google Drive and Gmail | Different workloads and destinations are confused. | Design email and files separately. |
| Overlooking shared mailboxes | Delegation functionality is lost. | Inventory permissions. |
| Overlooking DNS | Email delivery problems. | Prepare a cutover plan. |
| Overlooking SMTP applications | ERP or websites stop sending. | Inventory senders. |
| Skipping the pilot | Limitations emerge with actual users. | Test beforehand. |
| Promising zero interruption | Unrealistic expectations. | Explain anticipated impact. |
| Assuming every PC configuration is included | Scope grows without control. | Separate tenant and endpoint tasks. |
| Closing when the job finishes | Functional problems remain undiscovered. | Validate afterwards. |
Checklist before migrating to Microsoft 365
| Area | Check |
|---|---|
| Source | The exact source is identified. |
| Users | User count and listing are available where possible. |
| Mailboxes | Sizes and special cases are understood. |
| Shared mailboxes | Inventoried with permissions. |
| Calendars | The method’s coverage is understood. |
| Contacts | Inclusions are understood. |
| Files | Repositories identified. |
| OneDrive / SharePoint | Document destinations defined. |
| Domains | Configuration or transfer plan prepared. |
| MX | Change planned. |
| SPF / DKIM / DMARC | Reviewed. |
| SMTP applications | Inventoried. |
| Identity | Cloud-only or hybrid identity defined. |
| Licences | Prepared by user profile. |
| Tool | Selected after assessment. |
| Security | MFA and baseline configuration planned. |
| Pilot | Representative pilot users selected. |
| Cutover | Runbook and owners prepared. |
| Users | Communication prepared. |
| Endpoints | Local configuration owner assigned. |
| Validation | Acceptance criteria agreed. |
| Hypercare | Post-change support planned. |
Frequently asked questions about our Microsoft 365 migration services
What should a Microsoft 365 migration proposal include?
Describe sources, destinations, workloads, preparation, method, validation, support and responsibilities. Exclusions and dependencies should be understandable. User counts alone do not show whether devices, applications, permissions or special data handling are included.
How should two providers’ prices be compared?
Compare equivalent scope and delivered outcomes first. Review preparation, tests, tool licences and assistance, internal work retained and handling of incidents or additional needs. A lower price may represent less service rather than greater efficiency.
What must the business contribute?
Environment information, data owners and process validators, alongside authorised access coordination and operational restrictions. Providers guide analysis, but business decisions and acceptance require the people using and administering the destination.
What should be required for acceptance?
Agree tests beforehand and receive results at completion. Reports should verify included workloads, explain differences and identify outstanding incidents. Operational handover includes documentation and support owners; a completed copy notification does not replace acceptance of intended operation.
Final recommendations: the source determines the migration approach
The general phrase “migrate to Microsoft 365” conceals complexity. Google Workspace requires separate Gmail and Drive strategies and defined identity mapping and document destinations. Exchange Server needs an appropriate coexistence model and a method compatible with current version and architecture.
HCL Domino requires separation of email from business applications and databases. IMAP excludes calendars and contacts. POP3 begins with locating historical messages. Tenant-to-tenant adds dependencies between Exchange, OneDrive, SharePoint, Teams, identity, domains and applications.
Our approach at Kloudeal starts with the source and actual scope, then selects tools and uses pilots, premigration, cutover and validation to control transition. The objective is an operational Microsoft 365 environment supporting the organisation’s required data and services, backed by evidence rather than only a completion percentage.
Need to migrate to Microsoft 365?
Tell us your platform and user count. We can help migrate from Google Workspace, Exchange Server, HCL Domino, IMAP, POP3, Zimbra, other email providers, file servers and other Microsoft 365 tenants. Depending on the project, scope can include Exchange Online, calendars, contacts, shared mailboxes, domains, DNS, OneDrive, SharePoint, Teams, Entra ID, migration tools, pilot testing, cutover, validation and subsequent support.
Request a Microsoft 365 migration assessmentRecommended official documentation
Microsoft – email migration.
- Microsoft – Ways to migrate multiple email accounts to Microsoft 365
- Microsoft – Exchange Server Hybrid Deployments
- Microsoft – Minimal Hybrid / Express Migration
- Microsoft – Staged Migration and OutlookAnywhere Retirement Notice
Google Workspace.
- Microsoft – Google Workspace Mail Migration
- Microsoft – Switch from Google Workspace to Microsoft 365
- Microsoft – Google Workspace to Microsoft 365 with Migration Manager
- Microsoft – Map Google identities with Migration Manager
IMAP.
Microsoft 365 Tenant-to-Tenant.
- Microsoft – Microsoft 365 Migration Overview
- Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
- Microsoft – Migration Orchestrator Overview
- Microsoft – Cross-Tenant Mailbox Migration
- Microsoft – Cross-Tenant OneDrive Migration
- Microsoft – Cross-Tenant SharePoint Migration
Microsoft Entra ID and MFA.
- Microsoft – Microsoft Entra ID Name Change
- Microsoft – Mandatory Multifactor Authentication
- Microsoft – Security Defaults
HCL Domino / Notes.
Preparing a service brief that can be priced and delivered
A useful migration enquiry describes the current environment and the business outcome, even when the technical inventory is incomplete. Start with the platforms in use, approximate user numbers and the services that must continue. Add the reason for the change and any fixed business dates. This gives the provider enough context to propose an assessment and identify the information needed for a reliable scope. It also avoids treating an initial estimate as a commitment based on assumptions nobody has reviewed.
Explain how the organisation works with the source services. A list of email accounts does not show whether employees use shared calendars, local archives, departmental addresses or applications that send notifications. A storage total does not show whether files belong to individuals, teams or an application. Describe representative processes alongside quantities. The provider can then connect the technical inventory to the activities the migration must preserve and identify where a separate design decision is required.
Separate information gathering from implementation
Assessment should produce decisions or clearly assigned open questions. For each uncertainty, state what is missing, how it will be investigated and who can provide the answer. An unknown archive location may require a workstation review. An unclear application dependency may require its supplier. A disputed data owner requires a business decision. These are different tasks with different participants. Recording them prevents the implementation schedule from silently absorbing work that should have been resolved before transfer begins.
Agree how the assessment findings will affect the proposal. A preliminary quotation may need revision after actual volumes, special cases or integrations are confirmed. The important point is that the assumptions are visible and changes are explained. A provider should be able to show which newly confirmed requirement changes the work. The client should be able to decide whether to include it, defer it or assign it elsewhere without losing sight of the intended outcome.
Describe the destination as a working environment
For each service, describe where users will work after the change. Email needs recipients, addresses, access and sending behaviour. Documents need destinations, ownership and an access model. Collaboration needs an agreed structure and a clear explanation of included components. Identity needs a defined account journey. These descriptions should be understandable to the relevant business owner, while technical detail can sit in the supporting design. Both documents should refer to the same scope.
Do not assume that a source feature has a direct destination equivalent. Ask what business function it serves and how that function will be provided. A departmental inbox, an approval process or a shared file area may need a different configuration at the destination. The service brief should distinguish content transfer from adaptation. This helps the client understand why copying the data and preserving the process can require related but separate activities.
Assign responsibilities across teams
Create a responsibility list for the tasks that cross organisational boundaries. The migration provider may prepare the tenant, while internal IT supports devices and an application supplier changes its connection. A departmental owner validates the resulting workflow. State who coordinates these tasks and what evidence confirms completion. This is particularly important where an external dependency can block the change even though the provider’s own transfer jobs are ready.
Clarify the client’s role in access and approval. Technical work needs authorised accounts and the people who can approve the necessary changes. Business decisions need information owners. Acceptance needs participants who understand the normal process. The provider can help structure these activities, but cannot infer every ownership decision from portal data. A realistic plan reserves time for these reviews rather than treating the client as available only for the final sign-off.
Build the pilot around different kinds of work
Select pilot cases from the inventory’s diversity. Include an ordinary user and cases representing archives, shared resources, document permissions or important integrations. The purpose is to examine the chosen method under the conditions that matter to this project. A small sample can be useful if it represents meaningful differences; a larger sample of identical accounts may reveal much less. Document the selection so that the team understands what the pilot does and does not demonstrate.
Give participants concrete actions. Ask them to find known content, open a shared resource, perform a normal communication task or complete the relevant application workflow. Record expected and observed outcomes. Keep the technical reports alongside these results. If the pilot identifies a limitation, describe the effect on the user and the proposed alternative. This turns a compatibility statement into a practical decision about whether the design meets the requirement.
Prepare the change window as a coordinated sequence
The change plan should connect transfer completion to the actions that make the destination operational. Identify the state required before each step, the person performing it and the test confirming success. Domain, DNS, identity and application changes may depend on one another. A clear sequence allows the team to pause before an unresolved condition creates a wider interruption. It also makes the schedule understandable to support teams and business owners who are not operating the migration tool.
User communication should explain the tasks people need to perform and where to request assistance. Send instructions before the affected service changes. If device configuration is assigned to internal IT, give that team the information it needs in time to prepare. Avoid promising that every user experience will be unchanged when the design includes new sign-in steps, different applications or revised document locations. Clear expectations reduce avoidable incidents and make genuine problems easier to identify.
Use a structured handover record
At completion, compare delivered scope with the approved proposal and recorded changes. For each service, retain the relevant transfer results, functional tests and accepted exceptions. State outstanding actions with owners. This lets the client distinguish an unresolved fault from an agreed difference or a new request. The record should be concise enough to use, with supporting detail available when another administrator needs to investigate a particular resource.
Document the operational responsibilities that begin after the project. Identify who administers users, handles access requests, reviews service configuration and receives incidents. Where support has been contracted, state its channel and coverage. Where it has not, the receiving team still needs the information necessary to take over. A completed migration should leave the business with a clear ownership model rather than a collection of reports whose meaning depends on the original operator.
Review retained services and project costs
Before cancelling source subscriptions, confirm which dependencies remain and why. Some applications, archives or transition arrangements may have an agreed retention period. Record the owner and the condition for eventual closure. This prevents either premature retirement or indefinite overlap without accountability. The same review should identify temporary tool access and project resources that are no longer required, while preserving anything needed for accepted follow-up work.
Finally, reconcile recurring services, project charges and approved additions. The client should understand what continues after handover and which tasks were outside the original scope. This financial explanation belongs alongside the operational record because both reflect the decisions made during the project. It helps the business assess the migration as a delivered service, with a known destination and manageable responsibilities, rather than as an isolated data-copying activity.
Use the final review to confirm that every retained dependency has a named owner and a clear reason to remain. Where a date cannot yet be fixed, record the condition that will allow closure. This keeps follow-up work visible and gives the business a practical basis for deciding what happens after the project team has finished.