Migration questions,
answered plainly.

Yes, that is the intended first workload. The planned tooling reads Exchange Online mailboxes through Microsoft Graph and is designed to move messages with their folders, folder hierarchy, original dates, read state, flags and attachments. Shared mailboxes are planned too, with their members and permissions mapped to the destination, as are distribution lists, aliases and forwarding settings.

Delegation — send-as, send-on-behalf, full access — and calendar permissions are planned where the destination mail server can represent them. Online archive mailboxes are under evaluation, because how fully current Microsoft APIs expose them needs to be confirmed. Microsoft has announced the retirement of Exchange Web Services in Exchange Online, so the design does not rely on it.

Yes, as a planned capability: messages, full mailbox history, attachments, sent mail and labels, read through the Gmail API with access authorized by a Workspace super administrator. The complication is labels. A Gmail message can carry several labels at once, while a folder-based mailbox puts each message in one place. Before transfer the administrator chooses a rule — copy the message into a folder per label, place it by label priority, or keep only system folders and turn labels into tags where the destination supports them — and the assessment shows how many messages each choice affects.

Gmail settings such as filters, signatures and send-as addresses are under evaluation, because not every setting has an equivalent at the destination.

Yes, from both platforms, as planned capabilities. For calendars the design covers individual events, recurring series including exceptions (the one Tuesday that moved), attendees and their responses, reminders, time zones, shared and secondary calendars, and sharing permissions where supported. Room and resource calendars are inventoried so they can be re-created as bookable resources.

Contacts include personal contacts, contact folders or groups, and, where accessible, shared directory data. The company directory itself is not copied as contacts: at the destination it is generated from the user accounts the migration creates.

Meeting history is preserved as events, but past meetings will not be “live” in the way they were — for example, a Teams or Meet link in an old invitation still points to the old platform.

Yes, as a planned capability. Each user’s OneDrive is designed to move to their personal storage at the destination with its folder structure, supported metadata such as created and modified times, and sharing with internal users and groups mapped to destination permissions. Files shared between users are reconciled so they are owned once and shared, not duplicated. Large files are handled with chunked, resumable transfers.

Version history is under evaluation: earlier versions can be read from the source, but moving them all multiplies the volume and the transfer time, and the destination has to be able to store them as versions. The assessment is intended to show the cost of including them so the decision is informed.

Yes, as planned. My Drive files are designed to move to each user’s personal storage, and Shared Drives to shared team or department storage. Folder structure, sharing with internal users and groups, ownership and supported metadata are mapped. Two Google-specific points need decisions: files owned by suspended or departed users, which still exist and still count, need a new owner; and “anyone with the link” sharing has to be either re-created under the destination’s sharing policy or deliberately retired.

Uploaded files — PDFs, images, Office documents — move as they are. Native Google Docs, Sheets and Slides have to be converted; see below.

Document libraries are planned to migrate, including the libraries behind Microsoft Teams, with their folder structures, files and supported sharing permissions. Standard metadata is planned; custom columns, content types and managed metadata are under evaluation, because whether they can be represented depends on the destination file platform.

SharePoint is more than file storage, and the rest is a different matter. Site pages, lists, Power Automate flows, Power Apps, web parts and site designs are not file content and are not planned to migrate as working features. The assessment is intended to list them so the organization can decide what replaces them. Libraries where permission inheritance has been broken at many levels are flagged for review, because reproducing a permission structure nobody understands is rarely what anyone wants.

Yes — they have to be, because native Google files have no form outside Google. The planned tooling exports each Doc, Sheet and Slides file through Google’s API into a standard format the administrator chooses (Office Open XML or OpenDocument), validates that the converted file opens and renders in the destination’s editor, and records what it can detect did not convert.

Ordinary documents, spreadsheets and presentations generally convert well. What may not transfer perfectly: Google-specific spreadsheet functions such as IMPORTRANGE and GOOGLEFINANCE, Apps Script automation, add-ons, linked charts, embedded Forms, smart chips, some comments and suggestions depending on format, layout details, and revision history, which does not export as files. Google also limits the size of converted exports, so very large native files may need manual handling. The original stays in Google until decommissioning, so poor conversions can be revisited.

This is the area of greatest uncertainty, and it is under evaluation for both platforms. The structure of collaboration — teams, channels, spaces and their membership — is planned to be inventoried and re-created. Files shared in Teams live in SharePoint and files shared in Google Chat live in Drive, so both are planned to move with file content.

The conversations themselves are harder. Microsoft treats bulk access to Teams message content as a protected capability, with separate approval and, for some APIs, licensing or metered charges. Google’s programmatic access to Chat history is narrower than its access to mail and files. Even where messages can be exported, reactions, edits, app cards and embedded content may not carry over. Office Unbound does not promise complete Teams or Chat history. A realistic plan for many organizations is to keep an export of history for reference or compliance and begin new conversations on the destination.

They do not move. Neither Entra ID nor Google exports users’ password hashes or the secrets behind their authenticator apps and security keys through ordinary migration APIs — and a platform that did would be less secure for it. Users will set a password at the destination, or sign in through a single sign-on arrangement the organization chooses, and enroll their MFA methods again.

The planned tooling treats this as a scheduled part of the migration: destination accounts are created from the identity mapping ahead of time, enrollment invitations go out in waves matching the transfer batches, and the control center shows who has enrolled. The aim is that nobody discovers on cutover morning that they cannot sign in.

Yes; it is designed to. A migration can be phased by people — waves of users, usually grouped by department or by who works with whom — and by workload, for example mail and calendars first, files later. A pilot group always goes first. Shared mailboxes and their delegates, and assistants and the managers whose calendars they run, are meant to move in the same wave, because splitting them across platforms breaks delegation.

Phasing trades a smaller risk per step for a longer period of coexistence. The assessment is intended to recommend a phasing based on what it finds.

Yes, for a planned coexistence period, with known compromises. Mail for a domain arrives wherever its MX record points, so during a phased migration mail has to be routed or forwarded to whichever platform each person is on; both source platforms and the planned destination have mechanisms for this, and it is set up and tested as part of the plan. Meeting invitations continue to work between systems because they travel as email.

What does not happen automatically is free/busy lookup across the two platforms — seeing whether a colleague on the other side is free when booking a meeting. Whether that can be offered depends on the mail and calendar server finally selected, and it is under evaluation. Chat between the two sides is generally not bridged. Shorter coexistence periods are easier on everyone.

It depends on what “fails” means, and the design treats each case differently. A failed item — a message that will not import, a file with an invalid name — is recorded with its reason and retried or flagged for manual handling; the rest of the batch carries on. A failed batch can be re-run without repeating what already succeeded. A failed pilot is the process working as intended: it stops the migration before it reaches everyone.

Throughout, the source is left intact. The tooling reads from Microsoft 365 or Google Workspace and does not modify or delete source data, and source access is preserved until verification is signed off and decommissioning is agreed. Before cutover, abandoning a migration means continuing to use the source. After cutover, recovery is a planned procedure rather than an undo: moving MX back is possible, but mail received and sent in the meantime, cached DNS and reconfigured devices are not reversed by it.

By several specific comparisons, each with known limits. Counts of messages per folder, events, contacts, files and folders are compared between source and destination. Sizes are compared within tolerances, since mail and converted documents legitimately change size. Where the source API reports a content hash for a file, the destination copy is checked against it; this is not possible for native Google documents or for most mail. A sample of items is opened and compared field by field — dates, senders, attendees, recurrences, attachments, permissions. And users in the pilot and each wave confirm their own data through a short acceptance checklist.

Discrepancies are recorded against the item concerned and either resolved or accepted by a named administrator in the final report. The process page sets out each check.

No figure is given here, because none would be honest yet — no migration has been run with Office Unbound tooling. What determines duration is well understood, though, and the assessment is designed to estimate it per tenant:

• Total data volume, and especially item count: a million small messages take longer than the same volume in a few large files.
• Source-side API throttling, which Microsoft and Google apply per user, per application and per tenant, and vary over time.
• Whether version history and archives are included.
• How much conversion is needed, mainly for native Google files.
• Network capacity and destination infrastructure.
• The number of waves, and the time each pilot and wave is given for user acceptance.
• Decisions the organization has to make, which are often the slowest part.

Estimates are shown as ranges with their assumptions, and revised once the pilot has measured real transfer rates.

No. The migration tooling does not exist yet. Office Unbound is in Phase 1, architecture and evaluation, which includes designing the migration discovery architecture, permission models, compatibility matrix and report specifications. The assessment engine is planned for Phase 5A and the transfer tooling for Phase 5B, after the destination services exist. No dates are published. Registering for migration updates is the way to hear when early testing begins.

Both Microsoft and Google limit how fast an application can read from their services, to protect their platforms. Microsoft Graph responds to excessive requests with throttling responses that tell the caller to wait; Google applies quotas per user and per project and throttles bursts. These limits are not published as guarantees and can change.

The planned tooling is designed to work within them: honoring the wait times the source specifies, backing off rather than retrying aggressively, spreading load across users, and scheduling heavy transfers outside business hours when the tenant is quieter. Throttling is usually the real limit on migration speed, more than network bandwidth, which is why it features in every estimate.

Generally, the source accounts need to stay active and licensed until their data has been read and verified. On both platforms, removing a user’s license or subscription can make that user’s mailbox and files inaccessible and eventually deleted, on the provider’s schedule. The plan is therefore to release source licenses only during decommissioning, after verification is signed off — which means a period of paying for both platforms that should be budgeted for.

Some source capabilities may have their own requirements: certain Microsoft APIs for Teams message export, for example, carry licensing or metered-usage conditions of their own. The assessment is intended to list the source-side licensing a given migration depends on. Check current terms with Microsoft or Google; Office Unbound cannot state them on their behalf.

An MSP is intended to see a portfolio of migration projects, one per customer, in the same console used to manage those customers on Office Unbound. Across projects: status, readiness summaries, schedules, technician assignments and errors needing attention, so complexity can be compared and resources planned. Inside a project a technician has been assigned to: the full assessment, mappings, progress, verification results and reports, including customer-facing versions.

What an MSP does not see is one customer’s data from another customer’s project. Each project has its own authorization against that customer’s own source tenant; credentials, inventory and transferred data stay inside that customer’s tenant boundary, and technician access follows the platform’s delegated-administration roles. Customers can be required to approve their own migration at each gate. All of this is planned. Office Unbound for MSPs