Migration · Process
A migration in stages,
each one verifiable.
From the first read of the source tenant to the day it is switched off, the planned Office Unbound migration moves through defined stages, each with an output that can be checked and, where the stakes are high, an approval before the next begins.
Project status The process described here is the design for Phase 5 migration tooling, which is planned and not available. It applies to both Microsoft 365 and Google Workspace sources.
Why stages
Because the alternative is finding out on a Monday morning.
A platform migration fails in predictable ways. Data that nobody knew about turns up late. A permission model that looked equivalent turns out not to be. The bulk copy finishes, but by then a week of new mail has arrived at the old system. DNS is changed at five in the afternoon with a TTL of a day, and half the internet keeps delivering to the old servers. None of these is exotic; all of them are avoided by doing the work in an order that exposes problems while they are still cheap.
The stages below are the order Office Unbound’s migration tooling is being designed around. They are the same for both source platforms, though what happens inside them differs — see the Microsoft 365 and Google Workspace pages for the source-specific detail. Coexistence is listed after verification because it is planned for and judged there, but in practice it runs alongside the transfer for as long as some users have moved and others have not.
The stages, end to end
Each stage with what it does and what it produces. All planned.
Assessment
The source tenant is connected with least-privilege, read-oriented access and inventoried: users, groups, domains, mailboxes, drives, libraries and collaboration workloads; volumes and item counts; supported, partial and unsupported content; risks. Output: an assessment report and a readiness summary, ending at an administrator approval gate. More on the assessment engine.
Planning and mapping
Every source identity is mapped to a destination account; aliases, shared mailboxes, groups and permissions are translated; conversion decisions are made, such as how Gmail labels become folders and which format native Google documents convert to. Users are grouped into waves — by department, by dependency, by risk. Shared mailboxes and their delegates, and assistants and the people whose calendars they manage, are kept in the same wave. Output: an approved plan.
Pilot
A small group of real users — ideally including someone with a large mailbox, someone who lives in shared files and someone skeptical — is migrated end to end and works on the destination for long enough to find problems. Transfer rates observed in the pilot replace the estimates in the assessment. Output: a pilot report, a revised plan and a decision to proceed.
Staged transfer
The bulk of the data moves in waves, scheduled around business hours and the source platform’s API limits. Users keep working in the source system throughout; nothing is switched yet. Each batch is verified as it completes, and failed items are retried or recorded. Output: destination copies of each wave’s data, with per-item results.
Delta synchronization
Shortly before cutover, a further pass picks up what changed since the bulk transfer: new and moved messages, edited and new files, changed calendar events. Where the source provides change tracking, only the changes are read. Where a change cannot be detected reliably — some deletions, for example — the plan says how it is handled. Output: a destination that is current to within the last pass.
Cutover
Mail delivery and user access switch to Office Unbound on a scheduled, communicated date. The DNS work is planned days in advance (detail below). A final delta pass runs, users sign in to the destination, and devices and clients are reconfigured. Output: users working on the destination, with the source still intact.
Verification
Source and destination are compared formally — counts, sizes, checksums where available, sampling and user acceptance — and the results recorded. Some verification happens at every earlier stage; this is the stage where it is signed off. Output: a verification report.
Coexistence
For organizations that migrate in waves over weeks rather than one weekend, both systems run side by side and mail has to reach people wherever their mailbox currently is. Coexistence is planned in stage 2, operated throughout, and ended deliberately. Output: a defined end date for running both.
Decommissioning
Only after verification is signed off and an agreed holding period has passed is the source reduced: forwarding removed, licenses released, accounts and finally the tenant or subscription closed. Many organizations keep a compliance export of the source before closing it. Decommissioning is its own approval. Output: a completion report.
Cutover, DNS and MX
The few minutes that matter most, prepared for days.
Mail follows DNS. When the MX record for a domain changes, sending servers begin delivering to the new system — but only once their cached copy of the old record expires. The time-to-live (TTL) on that record decides how long that takes, and it is set by the organization, not by Office Unbound or the receiving servers. The planned cutover assistant therefore works backwards from the cutover time: TTLs on the records that will change are lowered well ahead, by at least the current TTL, so that on the day the change propagates quickly. They are raised again once the new records are confirmed.
| Record | What it does | At cutover |
|---|---|---|
| MX | Where other mail servers deliver your domain’s mail. | Changed to point at the Office Unbound mail service; TTL lowered beforehand. |
| SPF (TXT) | Which servers may send mail for the domain. | Destination added before cutover; source removed only after decommissioning, while it may still send. |
| DKIM | Keys receivers use to verify message signatures. | New selectors published for the destination; old keys left in place until the source stops sending. |
| DMARC | Policy for mail that fails SPF and DKIM, and where reports go. | Reviewed so the transition does not trip an enforcing policy; reports watched closely. |
| Autodiscovery | Lets mail clients and phones find server settings. | Repointed so reconfigured clients find the destination; behavior depends on client and protocol. |
| Other service records | Records for calendar, contacts, chat or verification by the source provider. | Listed in the assessment and changed or retired on the plan’s schedule. |
Even with low TTLs, some senders cache longer than they should, and mail queued before the change still arrives at the old system. That is why the source mailboxes stay live through cutover and why the final delta synchronization runs after the MX change, not before it.
What “verified” is meant to mean
Verification is a set of specific comparisons with stated limits, not a green tick. Each check below is planned; together they are intended to give an administrator evidence to sign off against.
| Check | What is compared | What it cannot tell you | Status |
|---|---|---|---|
| Counts | Messages per folder, events per calendar, contacts, files and folders per drive and library — source against destination. | That the right items arrived; two different sets can have the same count. | Planned |
| Sizes | Total and per-item sizes, within expected tolerances for format differences. | Mail and converted files legitimately change size in transit, so sizes flag outliers rather than prove equality. | Planned |
| Checksums | Content hashes for files where the source API reports one, recomputed at the destination. | Not available for every item; native Google documents and most mail have no source hash to compare. | Planned |
| Sampling | A random and a targeted selection of items opened and compared field by field: dates, senders, attendees, recurrences, attachments, permissions. | Sampling finds systematic problems; it does not prove the absence of individual ones. | Planned |
| Permissions | Who could reach each shared mailbox, calendar, folder and library before and after. | Permissions that have no destination equivalent are reported, not reproduced. | Planned |
| User acceptance | Pilot and wave users confirm their own mail, calendar and files look as expected, through a short checklist. | Depends on people taking part; it is the only check that knows what “right” looks like to the user. | Planned |
Every discrepancy is meant to be recorded against the item it concerns, explained where possible, and either fixed by a retry or accepted by a named administrator in the final report.
Coexistence, honestly
Running two systems is possible. Making them feel like one is harder.
When an organization moves in waves, some people are on Office Unbound and some are still on Microsoft 365 or Google Workspace, sometimes for weeks. The two most visible effects are mail routing and calendars.
Mail routing during transition
All of a domain’s mail arrives wherever its MX record points. Before cutover that is the source, so mail for users who have already moved has to be forwarded from their source mailbox to their destination one. After MX moves to Office Unbound, the reverse applies: mail for users not yet migrated has to be routed back to the source. Both platforms have mechanisms for per-user forwarding and routing, and the destination is being designed to support this kind of split delivery, but it is configuration with failure modes — loops, rejected forwards, SPF and DMARC complications — and the plan is intended to set it up and test it explicitly rather than assume it works.
Free/busy across systems
Inside one platform, booking a meeting shows when colleagues are free. Across two different platforms that lookup does not happen by itself. Whether Office Unbound can exchange free/busy information with Exchange Online or Google Calendar during a transition depends on the protocols each side supports and the mail and calendar server finally selected, and it is Under evaluation. The safer assumption is that people on different sides will see each other as having no availability information, and that waves should be shaped so people who schedule each other most move together.
Everything else
Meeting invitations still flow between systems as email. The address book needs to include people on both sides. Shared mailboxes and files should move with the people who use them most. Chat between the two sides is generally not bridged. The shorter the coexistence period, the fewer of these compromises anyone notices.
Rollback and recovery planning
Each stage of the plan is intended to come with a documented way back and an honest statement of what that way back does not cover. The main safeguard is structural: the source is never modified or switched off until the migration is verified and decommissioning is approved, so before cutover there is always a working system to return to.
After cutover, recovery becomes a plan rather than a button. Moving MX back to the source is possible; it does not move the mail that arrived at Office Unbound in the meantime, which would need its own reverse transfer. The planned tooling is intended to keep the records needed to do that, and to make the limits plain before anyone relies on them.
- Messages users sent from the new system to external recipients
- Replies external senders delivered to the new system
- DNS answers already cached by other servers and resolvers
- Phones and desktop clients reconfigured by users
- New files, edits and events created at the destination
- Notifications and invitations already received by other people
- Licenses released or accounts deleted at the source
The migration control center
The planned administrative workspace where each of these stages is run, watched and recorded. One project per source tenant; for MSPs, one per customer.
Plan
Source selection and connection; tenant inventory; user account mapping; workload selection; compatibility assessment; scheduling of waves and transfer windows; cutover planning.
Run
Progress tracking for the project; per-user and per-service status; error reporting item by item; retry of failed items; administrative notifications when a batch completes, stalls or crosses an error threshold.
Prove
Data integrity checks; approval records at each gate; a migration audit trail of who connected, approved and ran what; verification and final completion reports.
Everything in the control center is planned. It is part of the Phase 5 migration platform, alongside the assessment engine, and depends on the core services being in place first.
Planning a migration?
Tell us your source platform, rough size and whether you would move in one step or in waves. It helps decide which stages are prototyped first.