Google Workspace to Microsoft 365 Migration: A Business Planning Checklist
A Google Workspace to Microsoft 365 migration is a business change as well as a data transfer. Before choosing a date, decide what your staff must be able to do on the first working day after the move. For a Chicago business with a busy office, that may include shared inboxes, meeting calendars, mobile access, and applications that send messages on your behalf.
Seraph Technology Solutions scopes email and collaboration migrations around those requirements. Use this checklist to prepare a useful project brief and identify the decisions that should be made before work begins.
1. Define exactly what is moving
List users, primary addresses, aliases, shared addresses, calendars, contacts, and the business applications connected to email. Record approximate data volumes and identify former employees whose information must be retained. Assign a business owner to each exception so that the migration team is not guessing which data matters.
Treat files and email as separate workstreams. Microsoft’s consolidated migration guidance distinguishes Google mail from Google Drive migration into OneDrive and SharePoint. A proposal that says “email migration” should explicitly state whether files, permissions, and collaboration spaces are included.
2. Match the migration method to the environment
Microsoft documents several migration experiences. Its Exchange batch process can transfer mail, rules, calendars, and contacts, but documented exclusions include shared calendars and some settings. The exact method, tenant capabilities, and current limitations need checking during discovery. Do not assume that every feature you use in Google Workspace will be copied automatically.
Ask for a written list of included workloads, exclusions, and any separate remediation. For example, a shared calendar may need a different approach from a user’s primary calendar. Identify these differences before agreeing to the project price or deadline.
3. Prepare access and ownership
Confirm who controls the Google Workspace tenant, Microsoft 365 tenant, domain registration, and DNS. Name the person authorized to approve changes and the person who can help users during the transition. Provide administrative access through an agreed secure process; a public contact form is not a place to send passwords or recovery codes.
Include applications, printers, scanners, and websites that send email in the inventory. Their owners should participate in planning and testing. Review the necessary licenses and any additional tools before purchasing anything.
4. Run a representative pilot
Select a small group that reflects how the business works: a normal mailbox, a larger mailbox, and users with important calendar or shared-access needs. Agree on test cases before the pilot begins. Check sign-in, internal and external mail, calendar behavior, mobile access, and the workloads included in the scope.
Record failures and resolve their causes before expanding the migration. A pilot should produce evidence and a revised plan, rather than simply a successful progress bar.
5. Agree on the cutover and recovery plan
Choose a change window around business operations. Document the sequence of changes, communication to staff, support coverage, and the conditions that would pause the move. Decide how long the source environment remains available and who can authorize retirement of old services.
Ask what happens if a critical workflow fails. Recovery steps depend on the migration method and how much data has changed after cutover; do not assume that reversing a DNS record restores every part of the old environment.
6. Use automation where it can be verified
Microsoft documents PowerShell commands for preparing and starting migration batches. Repeatable scripts can reduce manual entry and help standardize reporting. They still need the correct tenant, permissions, input data, and a tested change plan.
Seraph’s approach is to automate repeatable work where the environment supports it, then validate the outcome against the agreed requirements. Final scope, acceptance checks, and ongoing ownership belong in the project agreement.
Prepare your migration brief
Send your current and target platforms, number of users, approximate mailbox sizes, shared resources, file-migration requirements, desired timeline, and budget range. Describe any business dates when changes must be avoided. With that information, we can assess the project and propose a scoped engagement.
Explore Seraph’s managed IT and project services, or discuss your migration with Seraph. Chicago-based; remote and onsite work is scoped to your needs.
Vendor references
Reviewed November 12, 2026: Microsoft consolidated Google Workspace migration guidance; Google Workspace batch migration overview and limitations; Exchange Online PowerShell migration guidance. Features and prerequisites can change; confirm them for the actual environment.
