Business email migration services
We migrate business email between Microsoft 365, Google Workspace, Exchange and IMAP systems. We plan mailbox transfers, the domain change and checks on access to the new environment, coordinating the work with the people responsible for your email service.
Request email migration Explore our working method
Specialist services
An inventory of accounts and data volumes, selection of the migration strategy and validation of email in the destination. We coordinate the change with the environment’s administrators and define which data each platform and migration method can support.
What can be migrated
Email migration scope depends on the source platform, destination platform and method used. Some environments support the migration of email, folders, calendars and contacts. In others, such as IMAP or POP3, the scope may be more limited and certain items need additional work. We establish these differences before defining the project.
Before the project starts, we identify which information exists, where it is stored and what needs to be retained. We review messages, folders, labels, contacts, calendars, shared mailboxes, aliases, rules, forwarding, groups, permissions and email client settings. This inventory provides the basis for agreeing what the migration should cover.
We also assess items that do not always migrate automatically, such as signatures, local rules, autocomplete entries, PST files, Outlook settings, delegated permissions or data stored only on users’ computers. These items need to be identified so that any separate handling can be included in the plan.
Source and destination platforms
Each email system has its own rules, limitations and tools. Migration from Exchange Server is handled differently from IMAP; migration from Google Workspace has a different scope from POP3; and Microsoft 365 tenant-to-tenant migration requires its own planning. We assess the available methods in the context of the platforms involved and the information that needs to move.
In Microsoft 365, the usual destination is Exchange Online, accessed through Outlook, Outlook on the web, mobile devices and Microsoft 365 applications. In Google Workspace, the destination is usually business Gmail, Google Calendar and Google’s collaboration tools. We can also assess migrations between tenants, domain changes, business consolidations or separations, defining the requirements of the specific project before selecting the approach.
Where the source uses IMAP, email and folders are normally migrated. Where the source uses POP3, we first need to establish whether messages remain on the server or have been downloaded to users’ computers. For older environments such as Zimbra, HCL Notes or hosted email, we analyse the technical options available before defining the method and the data that can be transferred.
Security and continuity
Business email contains client conversations, quotations, invoices, contracts, internal documents and sensitive communications. We therefore review both the mailboxes and the technical configuration needed to send and receive messages correctly. The migration plan needs to address the information being transferred and the service that users will rely on after the change.
One of the most sensitive steps is the business domain. Changing email providers requires a review of MX, SPF, DKIM, DMARC, Autodiscover and other records related to authentication and delivery. Incorrect settings can affect message reception, delivery or the domain’s reputation, so the required changes and their timing need to be planned carefully.
We also review access and permissions. Before migration, it is useful to know who uses each mailbox, which aliases exist, which groups receive email, which shared mailboxes are critical, who has delegated access and which devices need configuration afterwards. This helps identify the work needed beyond the transfer of messages.
The migration process
Implementation is organised into the following phases. The activities, dependencies and checks for each stage are defined within the scope agreed for the project and the environment involved.
Before and after migration
Before migrating email, it is important to establish which accounts remain active, which mailboxes must be retained, which users hold critical data, how much email exists, which contacts and calendars matter, which aliases are used and which devices need configuration afterwards. These details help define the actual work and the checks needed for completion.
Internal communication also needs preparation. Users should know when the change will happen, which platform they will use afterwards, whether Outlook, Gmail or a mobile app needs configuration, what will happen to their old access and whom to contact if they find a problem. These arrangements should be agreed before the cutover.
After migration, the new environment needs to be operational and validated. We review sending and receiving, mailbox access, migrated folders, calendars, contacts, aliases, shared mailboxes, groups, permissions, mobile devices, email clients and domain configuration. The checks are used to assess the result against the data and services included in the agreed scope.
Service follow-up
We agree the scope, responsibilities and priorities with your team. We document the work and the checks carried out. Any additional requirement is assessed before it is incorporated into the project or the support service, so that the implications for the agreed work are understood.
Frequently asked questions
We answer common questions about moving business email to Microsoft 365, Google Workspace, Exchange Online or another platform. We also include links to official documentation for further technical detail, so that the available methods and their limitations can be considered before planning a project.
It is the process of transferring accounts, messages, folders, contacts, calendars and settings from an existing email platform to a new one, such as Microsoft 365, Google Workspace, Exchange Online or another business system. The information transferred depends on the source, destination and migration method selected for the project.
A professional migration also involves reviewing users, domains, DNS, permissions, devices, email clients and continuity requirements. Microsoft summarises its official options in the documentation on ways to migrate email to Microsoft 365.
Yes. We migrate to Microsoft 365 from Gmail, Google Workspace, Exchange, IMAP, POP3, Zimbra, HCL Notes, older servers, hosted email and other providers. We review the source environment first to establish the available method, the information that can be moved and any work needed outside the mailbox transfer.
Before migration, we review accounts, licences, domains, DNS records, data volumes, shared mailboxes, aliases and user requirements. Microsoft provides documentation on mailbox migration to Microsoft 365 and on IMAP mailbox migration to Microsoft 365.
Yes. We can migrate mailboxes, email, contacts, calendars and associated data from Google Workspace to Microsoft 365, after reviewing users, domains, data volumes, permissions and compatibility. That review establishes what can be transferred using the chosen method and which items need separate preparation or configuration in the destination.
Microsoft documents migration of email, contacts and calendars from Google Workspace to Microsoft 365 in its official guide to business email migration from Google Workspace.
Yes. We can also assess migrations to Google Workspace when a business wants to move to business Gmail, Google Calendar and Google’s collaboration tools. The project needs to account for the source platform, the data to be transferred and the access arrangements required by users after the change.
Google documents its data import tool for moving email into Google Workspace from Exchange Online, IMAP-based webmail providers, another Google Workspace account or personal Gmail in its official guide to importing email with the data import tool.
Yes. We can carry out Microsoft 365 tenant-to-tenant migrations for mergers, separations, domain changes, internal reorganisations or environment consolidation. The approach is defined around the tenants involved and the services, users and information that need to move, with the dependencies reviewed before the cutover is planned.
These migrations require more detailed planning because they can affect mailboxes, identities, domains, permissions, OneDrive, SharePoint and other services. Microsoft provides official documentation on Microsoft 365 tenant-to-tenant migrations and on cross-tenant mailbox migration.
In many cases, yes, but it depends on the source platform, destination platform, available tools and the way users have organised their information. We assess these points before the project so that the scope distinguishes what can be transferred directly from items needing a separate process.
For IMAP or POP3 migrations, the scope may be more limited than migration from Exchange or Google Workspace. Before the project, we review which items can migrate directly and which require export, import or manual reconstruction, making those limitations clear when defining the work and its validation criteria.
Yes. We can review shared mailboxes, aliases, groups, forwarding and permissions. Depending on the source and destination platforms, some items can be migrated while others must be recreated or configured again. The review establishes the access and mail flow arrangements that need to be retained after the change.
In Microsoft environments, shared mailboxes, groups, delegated permissions and Exchange Online configuration should be assessed before the change so that their requirements are included in the migration plan.
The objective is to retain the information and validate the outcome. We analyse the environment, carry out tests, monitor the transfer and review migrated data after the change. These checks provide a basis for assessing what has moved and identifying any errors or limitations that need attention.
If a technical limitation exists, we identify it before carrying out the migration. For IMAP migration to Microsoft 365, Microsoft explains requirements and considerations in its official documentation on what you need to know before migrating IMAP mailboxes.
We plan the migration to minimise interruptions. Some projects require a change window, DNS adjustments or reconfiguration of devices and email clients. These activities are coordinated in advance to reduce the impact, with the timing and required actions communicated to the people responsible for the environment and its users.
The most sensitive stage is often changing mail flow and updating the domain’s records. We therefore review MX, SPF, DKIM and DMARC where relevant to the project.
SPF, DKIM and DMARC are email authentication mechanisms that help protect a domain against impersonation and improve message delivery. They need to be considered when changing email providers so that the domain’s sending arrangements and authentication records reflect the services authorised to send email.
Google recommends configuring SPF, DKIM and DMARC for domains that send email, and its official guidelines explain authentication requirements for improving delivery to Gmail. See the Gmail email sender guidelines.
Timing depends on the number of users, data volumes, source and destination platforms, synchronisation speed, connection quality, provider limits and complexity of the environment. These factors need to be reviewed together before a realistic schedule can be agreed for the transfer, cutover and validation of the result.
After the initial assessment, we can estimate the work by phase. For complex projects, pilot tests, batch migrations and validation before the wider change help establish how the migration behaves in the actual environment.
We can review your situation. There are many providers and configurations, and where the platform provides access to data through compatible methods, we assess the most suitable way to migrate it. The review establishes the available options before any commitment is made about the method or scope of transfer.
In many cases, IMAP, exports, connectors, specific tools or phased processes can be used. For IMAP mailboxes, Microsoft documents the process for migration to Microsoft 365 from IMAP-compatible systems.
Yes. After migration, we can help with validation, user configuration, incidents, documentation, basic training and administration of the new email environment. The work is defined around the services changed and the support arrangements agreed for the period after the transfer and cutover have been completed.
We can also review domain authentication, client configuration, permissions, shared mailboxes, aliases, groups, calendars and common user questions after the change, helping the organisation address the remaining configuration and administration tasks within scope.
Request your email migration
Tell us about the current platform, the number of users or resources involved and your priorities. We will review the context to define the next steps and the scope of the proposal for your organisation.
Contact Kloudeal