When a migration to Microsoft 365 comes up
Most enquiries we receive have one of four triggers: the company is rolling out Teams and wants email, files and chat from one platform; an old on-premises Exchange Server is due to be switched off; the IMAP mailbox package of a hosting provider no longer covers calendars, shared mailboxes and mobile devices; or after a merger the whole workforce is to move to the platform of the head office. In every case the same applies: Microsoft 365 licences are bought in minutes, the real effort is moving the existing data.
That is the part we take over. You decide on Microsoft 365, we make sure that on the first working day on the new platform everything is there: every email, every event, every contact, every file. How the project runs step by step is described on our process page. If you are still weighing the two platforms, the comparison Google Workspace vs. Microsoft 365 (German) may help.
What arrives 1:1 from which source, and what does not
Microsoft 365 is a clearly defined target, but the sources differ considerably. That is why we tell you in advance what moves automatically on your route:
- From Google Workspace: emails with labels (as folders), calendars with recurring series, contacts and contact groups, Google Drive to OneDrive, and Google Groups. Shared drives to SharePoint are quoted after the discovery analysis. Details in the guide Google Workspace to Microsoft 365 migration.
- From Exchange Server (on-premises): mailboxes with the full folder structure at the fixed price; calendars, contacts and public folders on request, priced by effort. This route has its own page: Exchange Server to cloud migration.
- From IMAP mailboxes (IONOS, STRATO, Telekom, mailbox.org and other hosting providers): emails with folders only. IMAP is a pure mail protocol; calendars or address books that the provider offers separately via CalDAV/CardDAV are discussed separately.
- From Zimbra / Open-Xchange: emails at the fixed price, calendars and contacts on request.
- From archive files (mbox/EML): emails from exports and backups, imported into the matching mailbox. See importing archives (German).
We also have to be honest about what Microsoft 365 as a target does not take over automatically: mailbox access rights and delegation, "send as" rights and inbox rules, the read/unread state and categories (mail arrives as unread), exceptions of individual recurring events, and secondary calendars. These items are listed in the discovery report and in the final report so you can recreate them in the target deliberately instead of discovering them on migration day.
Preparing the target tenant: users, licences, domain
Before any data flows, the Microsoft 365 tenant has to be in place: a licensed user for every mailbox being migrated, your domain verified in the tenant, and an app registration through which our software reads from the source and writes to the target. You obtain the licences directly from Microsoft or your partner; they are not part of our price. Creating users, groups and licence assignments is something we do together with you on request.
Important: the domain is added and verified in the tenant, but the MX records stay on the old system until the cut-over date. Mail flow therefore continues undisturbed during the whole pre-migration. Nothing is installed on end-user devices; Outlook profiles are pointed at the new account only after the switch.
Pre-migration, cut-over and the MX switch
The bulk of the data is transferred in the background, several mailboxes in parallel, while everyone keeps working. Standard folders such as Inbox or Sent Items land in the real system folders in Exchange Online, not in copy folders. Our software respects Microsoft throttling limits automatically, so neither source nor target is overloaded.
On the agreed date, usually at the weekend or in the evening, the MX records are switched to Microsoft 365. A delta sync picks up everything that arrived in the old system since the pre-migration. For your users the switch is a short, planned moment rather than a lost working day. How SPF, DKIM and DMARC should be adjusted alongside is explained in the guide email move without downtime (German). The DNS change itself is made by you or your IT partner; we supply the exact values and accompany the appointment.
Data protection: servers in Germany, no third-party tool
With a migration to Microsoft 365 the target is in the Microsoft cloud anyway; what matters is the path the data takes to get there. Migravault uses no third-party migration services. Our self-developed software runs on our own servers in Germany and the EU, reads from your source and writes into your tenant. Credentials are stored encrypted in a key vault and deleted after the project. On request we sign a data processing agreement under Art. 28 GDPR. Your obligations as controller are summarised in general terms in the guide GDPR-compliant cloud migration (German); this is not legal advice.
What you receive and what it costs
After the free initial analysis you receive a discovery report with the actual inventory, a fixed-price quote and a test migration with two or three real mailboxes, so you see the result in your own tenant before you commit. After the cut-over comes validation per mailbox and folder, documented in the final report. Throughout the project you have one dedicated contact.
The list prices are public: a €200 project fee for cloud sources (€300 for Exchange Server or Zimbra), €29 per mailbox for emails, €5 each for calendars and contacts, €19 per user for personal files up to 50 GB; from 50 mailboxes 10 %, from 100 mailboxes 15 % discount on the per-mailbox total, all net. What drives the price is explained in the guide What does an email migration cost?. Run your own configuration through the price calculator in two minutes and send it as an enquiry.
