Cutting corners on a Google Workspace migration risks serious operational disruption, including calendar duplication, accounts live on both platforms at once, and third-party tools no longer recognising the account. Successful transitions, especially complex Google-to-Google moves, require an experienced Google Workspace Partner to handle scoping, permission re-mapping, and user adoption that standard automated migration tools simply are not sophisticated enough to do (yet…).
Here’s a real example from the Cobry archives:
We picked up a Google Workspace migration that had been stuck for five weeks. Files had moved across, but email and calendars hadn't, so people were live on both platforms at once, calendar invites were splitting into duplicate events, and people were turning up to meetings that had already moved because their copy of the invite never got the update.
We got on a call with the client's CTO and Head of IT, asked direct questions until we had an accurate picture of what state everything was actually in, and gave them a timeline. We ended up beating it by two weeks, partly because the calendar chaos was causing enough disruption that everyone wanted it resolved fast.
We often run Google Workspace migrations from scratch, but we also frequently get brought in to finish ones someone else started and couldn't complete. Rescuing a stalled migration requires a different set of skills to running one cleanly from start to finish.
As Alistair Robertson, Cobry’s Tech Lead, puts it: "Someone with a perfect track record of doing migrations with zero issues is not the person you bring in to fix a job like that.". Success here comes down to resilience gained from experience and the ability to adapt when the original plan no longer matches reality.
The consequences of a stalled Google Workspace migration
Accounts end up live on both platforms at once, which sounds manageable until you see what it does to a calendar.
A calendar migration doesn't move an event, it copies it. If someone's account exists on both sides, an invite sent to their old alias creates a second, separate copy of the event instead of syncing to the original, so you end up with two different event IDs for what's meant to be the same meeting. One side accepts, the other proposes a new time, and neither system knows the other exists. Multiply that across a few hundred people and you get a business that can't reliably book a meeting.
Untangling that means sitting down with whoever actually knows the account, asking direct questions, and giving them an honest timeline instead of vague reassurance.
Why Google-to-Google Workspace migrations are harder than they look
If you're already on Google Workspace and moving to a different Google tenant, people usually assume it'll be the easy switch. In practice it's often more complex.
Google identifies an account by more than the email address. Underneath it sits a unique identifier, and every service tied to Google, ads accounts, analytics, anything using "sign in with Google", is tied to that identifier. If you change the email without dealing with that, the new account won't be treated as the same person, even though it looks identical. For a business with a few hundred third-party tools connected that way, that means a lot of individual re-authentication work.
A Google-to-Google migration usually needs a Google Workspace Partner to meticulously rebuild accounts and re-share everything. That's why it tends to take longer than a Microsoft-to-Google migration, even though on paper it looks like the simpler switch.
The limitations of Google Workspace migration tools
Google's native import tool is genuinely useful for a straightforward Microsoft 365 to Google Workspace migration, and it keeps getting better. That being said, it doesn't support Google-to-Google at all right now, and even where it does apply, its reporting isn't yet as detailed as a dedicated migration tool, so large or regulated organisations need to take that into consideration.
A tool will move whatever you point it at, but it won't tell you that turning a shared mailbox into a Google Group is going to break the finance team's shared inbox on day one, or that a set of file permissions has built up five years of external access that probably shouldn't get recreated as-is. Making those calls is second nature to our team through lived experience of 13 years of Google Workspace migrations.
Fixing a Google Workspace migration vs reversing one
These two get talked about as if they're the same problem, and they get mixed up constantly.
Fixing a migration means picking up something someone else left half done and finishing it properly. Reversing one is rarer, and it means the original decision to move platform was wrong for that business, usually because something business-critical never had a workable path to the new system. Old, standalone systems that were never designed to integrate with anything are the clearest example. When that's the situation, careful planning after the fact can't save the migration, because someone needs to spot the incompatibility before go-live, and that's a judgement call no checklist makes for you.
Most projects that go wrong are the fixable kind. That's the more common failure by a wide margin, and it's avoidable with proper scoping done early.
Common Google Workspace migration mistakes
A few patterns come up often enough to name directly.
No record of what was agreed. If decisions live in someone's memory of a call rather than a shared document with a visible edit history, everyone's relying on remembering the same conversation the same way, and they won't. A tracker that shows who changed what, and when, turns a dispute into a two-minute conversation instead of a lost week.
Treating it as a technical job only. Moving the data is easy to measure. Getting people, especially teams like finance who are often the most attached to their existing spreadsheet-based way of working, comfortable in the new environment is what actually determines whether the migration was worth doing. Platform adoption is what decides whether the investment pays off, which is why Cobry continues to support organisations post-migration to ensure full training across all the tools and systems.
No plan for when something breaks. Every migration carries some chance of an unexpected problem, and whether that turns into a minor hiccup or a five-week limbo comes down to the expertise of the person handling it.
What to ask a Google Workspace Partner about your migration BEFORE you hire them
A few questions tend to separate someone who's done this enough times from someone who hasn't.
Can they show you how they document decisions during the project?
Will they talk you through a migration that didn't go to plan and how they remedied it?
Do they flag trade-offs like shared mailboxes and permissions before you decide?
Is their pricing on tooling and licensing clear enough to compare against another quote?
Cobry: One of the UK’s Leading Google Workspace Partners
Cobry is a Google Workspace Partner based in the UK. We run Microsoft 365 to Google Workspace migrations from migration planning all the way through to user enablement and adoption. We also run Google-to-Google migrations and offer continuous monthly support. If you're weighing up whether to run this yourselves, get in touch and we'll give you a straight answer on what your environment actually needs.
