Microsoft 365 Migration Services

What a Microsoft 365 migration actually moves

A Microsoft 365 migration is rarely one move. It is several workloads with different rules, run on one timeline.

• Exchange and email. Mailboxes, shared mailboxes, distribution lists, calendars, and mail flow move into Exchange Online. The work that decides success is mail coexistence and the MX cutover, so messages route correctly while both environments are live.
• Files and SharePoint. Document libraries, site collections, and the permissions attached to them move into SharePoint Online. Unmapped permissions and undocumented customizations are where these moves stall, not the file copy.
• OneDrive. Personal and home-drive content moves into OneDrive for Business, with the redirection and sync rules that keep people working through the change.
• Teams. Channels, files, and the SharePoint sites behind them move together, because a Teams migration that ignores the underlying SharePoint structure breaks links after cutover.
• Identity underneath all of it. Accounts, groups, and access have to resolve before content moves, or people lose access on day one.

i3solutions’ Microsoft 365 Migration Services Models

We offer our clients a variety of Microsoft 365 migration models to choose from, depending on their corporate environment and migration needs. These include:

Migration paths, and how we choose one

• Cutover migration moves everyone in a single window. It suits smaller estates, roughly a few hundred mailboxes or fewer, where a short, well-rehearsed switch is lower risk than a long coexistence.
• Staged migration moves the estate in waves, validating each wave before the next. It suits larger or regulated estates where you cannot afford a single high-risk weekend.
• Hybrid migration keeps on-premises and cloud running together for an extended period. It suits organizations that need to move gradually, keep some workloads on-premises, or maintain coexistence during a long program.
• Tenant-to-tenant migration moves between two Microsoft 365 tenants, the pattern after a merger or divestiture. A divestiture that splits one tenant in two is a Microsoft 365 carve out migration, which carries its own sequencing and transition service agreement constraints. Here the hard part is identity and domain mapping and cross-tenant access, not copying mailboxes. A cross-tenant move needs an identity and domain map up front and a wave-based cutover that validates each wave.

We choose the path from your estate size, your compliance constraints, and your tolerance for coexistence, and we decide the end state before anything moves. The common failure we are called in to fix is a migration that started by copying content before identity and governance were settled, which is exactly where post-merger integrations stall.

Who provides Google Workspace to Microsoft 365 migration services?

Leaving Google Workspace splits into separate mail and file migrations, run by different Microsoft tools with different published exclusions, and a team that plans it as a single project discovers the second set of exclusions late. i3solutions plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based engineers, and a Google Workspace source changes the work in three specific ways. Microsoft’s native path is two tools, not one: Exchange Online moves mail, rules, calendar and contacts, while Migration Manager moves Google Drive and shared drives into OneDrive and SharePoint. Each tool publishes exclusions that decide scope before anyone quotes a schedule. And one Microsoft constraint ends the conversation for a large share of regulated buyers: Google Workspace migration is not currently available for Office 365 US Government GCC High or DoD. If the destination tenant is GCC High, the native route does not exist and you are planning a different program. i3solutions runs migrations against named control families across CMMC, HIPAA, SOC 2, and NIST 800-171, producing artifacts auditors can review.

What the native tools move, and what they leave behind

The mail side is Exchange Online. Per Microsoft’s Google Workspace migration article, mail and rules, calendar and contacts are in scope, and the exclusions are named:

• Vacation settings and automatic reply settings are not migrated.
• Room bookings are not migrated. Shared calendars and event colors are not migrated.
• A maximum of three email addresses per contact are migrated. Gmail tags, contact URLs and custom tags are not.
• Rules migrate but arrive turned off by default, so somebody has to verify and enable them per user.
• The largest single message that can be migrated follows your transport configuration, and the default limit is 35 MB.
• Throughput for contacts and calendars depends entirely on the quota restrictions applied to your service account on the Google side, which is a source-tenant setting, not something the destination can tune.

The file side is Migration Manager, whose six-step workflow is connect, scan and assess, copy to the migrations list, review destination paths, map identities, then migrate and monitor (Microsoft Learn, Migrate Google Workspace to Microsoft 365 with Migration Manager). Its published ceilings and exclusions are where file-count estimates go wrong:

• The maximum supported file size for Google to Microsoft 365 is 250 GB.
• A destination path URL over 400 characters fails, which is a real constraint on deep shared-drive folder trees (Microsoft Learn, Unsupported file types in Migration Manager).
• Google Sites and Google Maps are not migrated. Unorganized or orphaned files are not scanned at all, so they are neither migrated nor shown in any report.
• Google Docs, Sheets and Slides are converted by the Google Export API into .docx, .xlsx and .pptx. Google Drawings become PNG files by default.
• The item that catches teams out: unsupported files do not change the final status of the task. A scan whose only failures are unsupported files can still read Ready to migrate, and a migration can still read Completed. The item-level errors are the record of what moved, not the green task status.

The retention work that happens before a single mailbox moves

Microsoft strongly recommends disabling all messaging records management and archival policies before attempting any data migration, because messages those policies delete or archive get flagged as missing by the migration tool. Microsoft’s own words for the result are “perceived data loss rather than actual data loss, which makes it much harder to identify actual data loss during any content verification checks.” In a regulated estate, switching retention off is a change-controlled act with a named approver and an end date, not a checkbox in a runbook.

The source side has its own order of operations. Per Google Vault Help, How retention works, holds take precedence over retention rules, and when a hold is deleted the data becomes immediately subject to whatever retention rules apply. Decide what stays held and what is released before the source tenant is decommissioned, because after decommissioning the question is unanswerable.

The Google Workspace Data Export tool is a planned activity, not a safety net, and its own documented windows are the reason. Google Workspace documentation requires a super administrator account at least 30 days old with 2-Step Verification enabled, states that a Google Workspace export typically takes 72 hours but can take up to 14 days, is available no earlier than 48 hours after it starts, and is automatically deleted 60 days from the beginning of the export. It also states that organizations with FedRAMP Authorization or more than 1,000 users should contact Google Workspace support before using the tool. An enterprise estate is above that line by definition, so the fallback export is a scheduled, supported activity with its own lead time.

Identity and mail routing, which is where the schedule is really set

The documented prerequisites are ordered, and each one has an owner outside the migration team:

• Two subdomains are added in the Google Admin console as user alias domains, one routing mail to Microsoft 365 and one routing mail to Google Workspace. A subdomain of your primary domain verifies automatically. Microsoft states the migration cannot complete if an unverified routing domain is used, and names the built-in tenant onmicrosoft.com domain as a choice that occasionally causes issues it is not able to assist with.
• Every user has to exist as a mail user in Microsoft 365 before the batch runs, with ExternalEmailAddress pointing at the Google routing domain and a proxy address on the Microsoft routing domain. Where Microsoft Entra Connect provisioned those mail users, it may need to be turned off so the migration can convert them into mailboxes.
• On the Google side the migration administrator needs resourcemanager.projects.create and iam.ServiceAccounts.create, granted through the Project Creator and Service Accounts Creator roles, to create the project, the service account and the service key and to enable the Gmail, Calendar and Contacts APIs. Microsoft’s Exchange Online prerequisites article notes that those role assignments can take up to 15 minutes to propagate, and that the stated Exchange Online minimum for the administrator running the migration is the Recipient Management role group.
• Migration Manager needs Global admin, OneDrive or SharePoint admin, or the Microsoft 365 Migration Administrator role at the destination, and an account with Read access at the source. Microsoft 365 Migration Manager Lite, which skips scanning, destination review and identity mapping, is enabled by default only for Microsoft 365 tenants with fewer than 300 licenses, so an enterprise runs the full workflow and owns every step of it.
• Identity mapping automaps on exact name match, and Microsoft states plainly that in most cases automapping is unlikely to map all the identities. The batch CSV upload is not validated. Unmapped identities become wrong permissions and wrong file metadata at the destination, and that is found after cutover rather than before it.

How i3solutions runs one of these

i3solutions has been a Microsoft partner since 1997 and has completed more than 600 Microsoft platform implementations. i3solutions pre-migration SharePoint assessment engagements run four to six weeks, which is the window in which the Drive-side scan findings and the identity map get settled rather than discovered. On a large content migration, the use of ShareGate automation reduced migration downtime from weeks to just hours, avoiding tens of thousands of dollars in lost staff productivity. Regulated-enterprise migration practices typically absorb a 25 to 35 percent overhead on top of the base migration work, which is the control mapping, the audit-trail discipline and the evidence production that a commercial migration does not carry. Scope on a Google Workspace source is driven by mailbox count, Drive and shared-drive volume, how many identities fail automapping, and whether the destination tenant is commercial or government. i3solutions routes a senior U.S.-based engineer to a client call usually within one to two weeks.

If the destination is a government cloud, start with the GCC High migration checklist, because the native Google Workspace path is not available there. If the move is one side of a merger or a divestiture, the sequencing questions are different again and are covered in dual-tenant Microsoft merger and Microsoft 365 carve-out migration. For the directory work underneath all of it, see Entra ID configuration and integration services. The inputs that decide which of those your estate needs are the destination tenant type, the Migration Manager scan report, and how much of the identity map survives automapping. Talk to a senior Microsoft System Integration architect with those in hand.

Benefits of Microsoft 365 Migration Services

Microsoft 365 migration services we provide

Our Microsoft 365 migration services take into account the varying and evolving needs of our clients as they transition from their on-premises or legacy solutions to the cloud. As a result, we provide:

Challenges we solve

i3solutions is highly experienced with Microsoft 365 migration and integration and are able to solve a variety of challenges that commonly interfere with the smooth migration of solutions including:

Security, compliance, and data residency

For regulated and federal organizations, the migration is also a compliance event, and senior, U.S.-based engineers run it for exactly that reason.

• Identity and access. Conditional access, MFA, and least-privilege groups are configured before content moves, so the new environment is governed from day one rather than hardened after the fact.
• Data residency. Where data lives matters for federal and regulated work. We migrate into the tenant configuration your compliance posture requires, including GCC and other regulated environments, and confirm residency before content moves.
• Retention and records. Retention labels, legal holds, and records policies move with the content, so a migration does not quietly drop an obligation you are required to keep.
• Audit evidence. We document the estate, the decisions, and the cutover as artifacts you can hand to an auditor or a board. The standard the work is held to is modernization without audit risk.

What we do for our clients

We have assisted clients in a variety of industries with strategizing on the most beneficial options for their migration projects and implementing their deployment according to plan. Our clients routinely request us to assist with:

How we sequence a cutover

Every i3solutions migration follows the same order, because the order is what prevents day-one failures.

1. Decide the end state. Consolidate to one tenant or operate multi-tenant deliberately. Everything else follows from that decision.
2. Map identity and the estate. Accounts, domains, groups, permissions, customizations, and workflows are inventoried before a plan is built, not discovered mid-cutover.
3. Secure identity and cross-tenant access. People must authenticate and reach what they are entitled to before content migrates.
4. Move content in governed waves. Each wave is validated before the next, so problems surface at wave scale, not estate scale.
5. Stabilize after cutover. Mail flow, sync, permissions, and access are verified, and the old environment is retired on a schedule, not abandoned.

This is the sequence that took the Millennium Challenge Corporation from an unsupported SharePoint 2010 estate to Microsoft 365 with migration downtime measured in hours rather than weeks.

We can handle your Microsoft 365 migration needs

i3solutions’ consultants are highly skilled and experienced. We have been assisting clients for more than 20 years on Microsoft 365 deployments of all sizes and complexity. We can handle your migration needs as well.

Contact us at aski3@i3solutions.com and let our Microsoft 365 consulting team advise you of the migration option that best suits your business needs and budget.