You’ve done the planning. You’ve secured the budget. You’ve mapped out your migration strategy. On paper, everything looks solid.
Then cutover day arrives… and something breaks.
A shared mailbox didn’t migrate. A department’s calendar events are missing. Some users can’t log in because their accounts weren’t properly provisioned. These aren’t rare edge cases, they’re common issues that surface when critical pre-migration details are overlooked.
The reality is, most Google Workspace migration failures don’t happen because of poor planning alone. They happen because of small but important gaps in preparation details that seem minor until they suddenly disrupt business operations.
From incomplete user provisioning to missed permission settings, and even choosing the right migration tools, these oversights can quickly turn a well-planned migration into a stressful experience. Using a reliable solution such as the EdbMails G Suite Migration Tool can be a key factor in ensuring a smooth cutover.
This checklist highlights the 15 things IT admins most commonly miss before cutover. Not the obvious basics, but the subtle details, including selecting the right migration tool that can make or break your migration success.
Before You Begin: Set the Right Mindset
A migration isn’t just a data transfer. It’s a transition of an organization’s communication infrastructure. Every item on this checklist exists because a real admin, at a real company, missed it and paid the price.
Work through this list at least two weeks before your scheduled cutover, not the night before.
The 15 Pre-Cutover Checks IT Admins Often Miss
1. Audit Inactive and Suspended Google Workspace Accounts
Most admins know how to migrate active users. Few remember to audit suspended or inactive accounts before starting.
Suspended accounts in Google Workspace may still hold critical emails, shared Drive files, or calendar data that colleagues reference. If these accounts are skipped during migration scoping, that data silently stays behind.
What to do: Export a full user list from the Google Admin Console, including suspended users. Decide in advance: migrate, archive, or decommission. Document your decision for each.
2. Check for Shared Mailboxes and Distribution Groups
Google Workspace doesn’t have “shared mailboxes” in the traditional sense, but many organizations simulate them using shared Google accounts or delegated mailbox access. These often get missed in the standard user list.
Similarly, Google Groups used as distribution lists need to be recreated or mapped on the target platform (e.g., Microsoft 365 distribution groups or shared mailboxes).
What to do: Identify all Google Groups, delegated mailbox accounts, and role-based email addresses (like support@, billing@, info@). Map each one to its equivalent on the target platform before cutover.
3. Verify Gmail Label Mapping to Target Folders
Gmail uses labels, not folders. This is one of the most misunderstood aspects of Google Workspace migration.
On Microsoft 365 or Exchange, labels become folders, but the mapping isn’t always clean. Nested labels, custom labels with special characters, and system labels like “Starred” or “Important” may not translate correctly, depending on your migration tool.
What to do: Before migration, export a sample user’s label list. Test how your migration tool handles nested labels and system labels. Verify the output structure on the target environment before running the full migration.
EdbMails tip: EdbMails preserves Gmail labels and folder hierarchy during migration to Microsoft 365, Exchange, and IMAP, ensuring users find their emails exactly where they expect them.
4. Check Connected Third-Party Apps and OAuth Permissions
Google Workspace accounts accumulate connected apps over time, such as CRMs, project management tools, e-signature platforms, HR software, and more. These connections authenticate through OAuth using Google credentials.
After migration, all these apps will break for users who relied on “Sign in with Google.” This causes immediate productivity disruption that many admins don’t anticipate.
What to do: Go to Google Admin Console > Security > API Controls > Manage Third-Party App Access. Document every connected app. Coordinate with app owners to set up re-authentication on the target platform well before cutover.
5. Validate SPF, DKIM, and DMARC Records Early
DNS changes are expected during migration, but many admins wait too long to prepare email authentication records.
If SPF, DKIM, and DMARC records aren’t updated correctly for the new mail platform, outbound emails from your domain can land in recipients’ spam folders immediately after cutover, a nightmare for business communication.
What to do: Work with your DNS administrator at least one week before cutover to prepare updated SPF and DKIM records for the target platform. Test them using tools like MXToolbox before going live.
6. Handle Forwarding Rules and Filters at the User Level
Many users have set up personal Gmail filters and forwarding rules over the years: “forward all emails from this sender to another address,” “auto-label everything from this domain,” etc.
These are stored at the user level in Gmail and are separate from admin-level routing rules. They will not migrate automatically.
What to do: Either communicate with users to recreate their filters on the target platform, or use Google Takeout to export filter settings and provide users with instructions for importing them on the new platform.
7. Don’t Forget About Google Contacts, Especially Shared Contacts
Google Contacts migrates less cleanly than email. Personal contacts often transfer well, but shared contacts (Directory contacts) in Google Workspace, the ones visible to all users in the organization, require a separate export and import process.
What to do: Export the organization’s shared contacts from the Google Admin Console’s Directory. Ensure your migration tool supports contact migration, and verify the output on the target before cutover. EdbMails migrates Google Contacts, including personal contacts and contact groups.
8. Audit Google Calendar Resources (Rooms and Equipment)
Organizations often configure Room calendars and Equipment calendars in Google Workspace (conference rooms, projectors, company vehicles). These are separate from user calendars and must be migrated or recreated manually on the target platform.
What to do: List all Calendar Resources from Google Admin Console > Buildings and Resources. Recreate them on your target platform before migrating user calendars that have existing bookings for those resources.
9. Check the Volume of User Data Before Throttling Bites You
Google Workspace APIs enforce throttling limits on data access. If you have users with extremely large mailboxes (50 GB+, or years of archived emails), the migration will slow significantly for those accounts.
Many admins plan migration timelines based on average mailbox size, then get surprised when a few heavy users cause the overall migration to run hours or days over schedule.
What to do: Before migration, identify your top 10-20 largest mailboxes using Google Admin Console reports. Plan extra time for these accounts or migrate them first as a separate batch. Tools like EdbMails include automatic throttling management to handle API limits without manual intervention.
10. Plan for Users Who Are on Leave During Migration
It sounds simple, but it’s often missed: users who are on medical leave, parental leave, or extended travel during migration may have accounts that haven’t been actively used for weeks. These accounts still need to be migrated, but there’s no user available to verify the results.
What to do: Create a list of absent users. Assign an IT team member to validate each account post-migration and hold the communication about migration status until the user returns.
11. Test the Migration With a Pilot Group First
Running a migration directly on the entire organization without a pilot is one of the biggest risks admins take. Issues that only appear at scale, such as performance degradation, unexpected label conversion, and calendar sync errors, won’t show up in a quick demo.
What to do: Select a pilot group of 5-10 users representing different departments, mailbox sizes, and data types. Run the full migration for this group, verify the results thoroughly, then scale to the rest of the organization. EdbMails supports selective mailbox migration, making it easy to run focused pilot migrations before full cutover.
12. Set Up Incremental Migration Runs Before Cutover Day
Many admins think of migration as a one-time event: move everything, then cut over. In reality, data continues to arrive in source mailboxes during the migration window. Without incremental migration, any emails received after the initial migration run are left behind.
What to do: Plan at least one incremental (delta) migration run close to the cutover date. This syncs any new emails, contacts, or calendar items added since the initial migration, ensuring nothing is missed at cutover. EdbMails supports incremental migration, allowing you to run delta passes as many times as needed before final cutover.
13. Document the Rollback Plan
Nobody wants to think about rollback. But having no rollback plan is a significant risk, especially for large or complex migrations.
If cutover fails or users experience critical data loss, how long will it take to restore access to Google Workspace? Who makes the rollback decision, and how is it communicated?
What to do: Before cutover, document a clear rollback procedure: how to revert MX records, how long source data will remain accessible, and who has the authority to trigger a rollback. Share this plan with management and the IT team.
14. Communicate With Users Before, During, and After Migration
User communication is consistently underestimated. Users who are surprised by a sudden platform change, even a smooth one, will flood the helpdesk with tickets and create unnecessary disruption.
What to do: Send at least three communications: one announcement 2 weeks out, one reminder 3 days before cutover, and one “what changed” guide on migration day. Include basics like how to access their new account, where their old emails are, and who to contact for issues.
15. Validate Migration Results With Reports Before Closing the Project
Once migration is complete, many IT teams quickly move on to the next task. But declaring the migration “done” without formal verification is a mistake.
Users may not immediately notice missing emails or calendar events. Without a structured post-migration audit, issues can surface weeks later when they’re much harder to trace and resolve.
What to do: Use your migration tool’s detailed reports to verify item counts per mailbox, confirm calendar events and contacts were transferred, and cross-reference any errors or warnings. EdbMails auto-generates detailed migration reports covering mailbox status, item counts, folder-level details, and error logs, giving admins full visibility to close the migration with confidence.
Migrate Google Workspace with Confidence Using EdbMails
EdbMails G Suite Migration Software is built to handle the complexities that catch admins off guard. From automatic throttling management and incremental migration support to detailed migration reports and label-preserving transfers, EdbMails helps organizations complete Google Workspace migrations smoothly with zero data loss and zero downtime.
Whether you’re migrating from G Suite to Microsoft 365, Exchange Server, or an IMAP server, EdbMails gives you the control and visibility to migrate with confidence.
👉 Download the free trial and migrate up to 30 items per folder at no cost, no credit card required.
Not sure where to start? Book a free personalized demo and let our migration specialists walk you through the entire process, tailored to your organization’s size and setup. Book a Demo
