Inside a Google-to-Microsoft 365 M&A migration: Expert Q&A with MVP Jasjit Chopra

In this Q&A, Microsoft MVP Jasjit Chopra unpacks real-world Google-to-Microsoft 365 migrations in a merger and acquisition (M&A).

When a merger or acquisition happens, IT teams don’t just inherit new colleagues, they inherit entire digital ecosystems. And if those ecosystems include Google Workspace, the pressure is on to move to Microsoft 365 quickly, securely, and without disrupting business operations.

We asked Microsoft MVP Jasjit Chopra to explore a real-world Google-to-Microsoft 365 M&A migration. From the triggers that set the project in motion, to the biggest risks on the table, to the tactical steps that kept the transition on track, Jasjit shares what it takes to navigate the complexity of this high-stakes scenario.

We also look at how ShareGate streamlined the process by migrating Gmail, Google Calendar, and Drive in one smooth, secure workflow. No scripts. No mid-migration surprises.

This Q&A builds on insights from our recent webinar with Jasjit, From Google Workspace to Microsoft 365: MVP strategies for mastering M&A migrations. If you want even more tips, strategies, and lessons learned straight from the source, it’s a must-watch!

‍

Q: Before we dive in, can you share a bit about your background and your company’s work?

A: Hi everyone, my name is Jasjit Chopra, and I’m the CEO of Penthara Technologies.

I was first introduced to SharePoint back in 2005, starting with the on-prem version—specifically the 2003 edition. I got my hands on it as a site admin, and that’s how my journey in the SharePoint world began.

Today, I lead a small team of about twenty people, and we’ve handled tons of migrations. We’ve moved terabytes upon terabytes of data for all kinds of customers—from Google Workspace, tenant-to-tenant migrations, file share migrations, and more. Whether the target destination is SharePoint Online, Microsoft Teams, or Exchange Online, we’ve built up deep expertise over the years, and at this point, I often joke that we can migrate any customer in our sleep.

‍

Q: Tell us why organizations switch from Google Workspace to Microsoft 365. What prompted these moves in your experience?

A: The story behind migrations—for so many different customers—is always unique at the end of the day, right? Some of them want to grow because they've been merged into a bigger entity. Some of them want to make a decision to leave Google Workspace and move to Microsoft 365 because of the features and security it provides.

Or it could be any other technical or business decision.

With mergers and acquisitions, there are strict timelines. Sometimes there’s urgency in certain scenarios. In some cases, there's a security breach or a risk happening in the environment, and the customer wants to move their data from a file share or from Google Workspace. In other cases, there are compliance requirements—they have to meet a specific date to stay compliant—and they want to move away from Google Workspace to Microsoft 365, because Microsoft 365 has tools like Purview and Defender security features that they want to take advantage of.

The reasons for migrating from Google Workspace vary from customer to customer. We’ve migrated some customers in under a month. Other times, it’s taken two to three months, depending on how much data is involved. And for a few customers, it’s taken even longer because of complex integrations or single sign-on applications—so we have to move identities along with the data.

Those migrations tend to take longer, depending on whether we’re using a phased approach with a few batches of end users at a time, or a big bang approach, doing everything over a weekend. It really depends on the use case—we look at the scenario, choose the right strategy, and implement accordingly.

There are two important things that are absolutely non-negotiable: first, the end-user experience. After migration, users should be able to manage and work on the new platform as easily as possible. Second, no data loss.

‍

“Two things are absolutely non-negotiable: first, the end-user experience. Second, no data loss.”

‍

No end user should come back saying, “Hey, I’m missing data from my inbox, my file share, or my Google Drive,” or anything they previously had access to.

‍

Q: Heading into these projects, what were some of your biggest concerns? Were there any known risks or unknowns that had you worried before things got underway?

A: Some of the biggest risks we've seen during migrations obviously come from misalignment between the business and technical teams. The business often wants things done really fast, but rushing through the process brings a lot of challenges.

You should always plan your migrations very carefully and make sure no stone is left unturned when it comes to impact analysis—whether that's business continuity or the user experience after the move. Especially when migrating from Google, it's important to consider how different the two environments are. The way you collaborate is very different in each platform, and of course, the UI is also dramatically different compared to what users are used to in Google versus Microsoft 365.

So yeah, change management continues to be the biggest risk in these projects. The second biggest we see is making sure you have a solid delta migration strategy so no data is left behind and there’s no data loss at the end of the day.

‍

Q: What was your approach to discovery and planning? Were there any tools or techniques that helped you assess the landscape?

A: So one of the very important parts of doing your migration is the first discovery process, right? In your discovery process, you have to be very clear on how you're going to get the data, understand the environment, and document everything properly.

So far, our tool of choice has been ShareGate to do the initial discovery for SharePoint and Teams environments in general. In a few cases, we use PowerShell—custom scripts we've created—to get a bit more detailed inventory of existing users, mailboxes, file shares, and where the data is stored.

When it comes to Google, we use Google Apps Script to get detailed information about specific scenarios we’re looking into, including exceptions that need to be flagged or taken into consideration.

ShareGate has been an amazing tool for giving us the lay of the land—a very holistic picture with just a few clicks. That really helps when we need to run discovery again and again, to make sure that from a timeline perspective, between when you start the project and when you finish the migration, the delta is regularly captured. It’s not just one discovery and then done—the discovery has to happen on a somewhat continuous basis to make sure there are no new users, no new data, no new sites or mailboxes that might affect the migration.

So you have to take that into account in your strategy as well.

‍

Q: Were there some early red flags or surprises during the discovery phase that forced you to adapt your migration plan?

A: Yes, we see them all the time.

In some cases, customers will tell us, “Oh, in our source environment, we’re not using this particular feature,” or “Our users aren’t supposed to access this data.” Sometimes, a company will say they’ve been operating for five years, but when we do the discovery, we only find around 20 GB of data which doesn’t really add up to five years of operations.

That’s when we need to dig a little deeper and ask the right questions as consultants, like: If you’ve been running your company for five years and only have 20 GB of data in Google Workspace, where’s the rest of it? Who’s working where, specifically?

Then, once you start talking to the end users, you often find out where the data actually is. Some of it’s sitting in personal Google Drives, some in Dropbox, or maybe even other environments. And if that hasn’t been accounted for in the migration plan, that’s when panic sets in.

You also start to uncover these little pockets of shadow IT—where people are using personal accounts to manage enterprise data. That’s a huge risk, and definitely not a good situation to find yourself in.

‍

Q: What's the toughest part (technical or people-related) during a Google-to-Microsoft 365 M&A migration project?

A: There are a lot of challenges, one way or another—both technical and human.

A big technical challenge you have to watch out for is throttling. It gets trickier on weekends because a lot of other customers are hitting the same data center. To help mitigate that, we run multiple instances and split the workload using different service accounts for the migration. That helps manage throttling at the user level across different scenarios. We also spin up multiple virtual machines in Azure to divide the workload further, so we’re not overloading a single VM at the end of the day.

That setup definitely helps. On the human side—where do I even begin? Most of the risk and challenges come down to change management. Users often aren’t properly prepared for what post-migration looks like. They don’t know how to access or work with their data the way they’re used to, and they struggle with how to collaborate in tools like Microsoft Word, Excel, PowerPoint—whatever they relied on in Google Workspace. So yes, that’s a consistent challenge. You really need to put a strong focus on training, and I always emphasize the importance of change management, communication, and upfront planning.

‍

“Most of the risk and challenges come down to change management. Users often aren’t properly prepared for what post-migration looks like.”

‍

If you’re doing all of that right, it goes a long way in reducing the risks and easing the transition.

Now, in rare cases, we also see service endpoints getting degraded. That’s another risk to factor in. If you’ve planned your migration timeline and things slow down—whether it’s a weekend or a weekday—you need to account for that in your strategy. What we usually do is an initial sync, followed by multiple delta syncs leading up to the final migration date.

But with that approach, you need to be careful about deleted items. Delta syncs don’t handle deletions—so if something is removed from the source, it’ll still appear in the target.

The way we handle that is by clearly communicating it from day one to both end users and stakeholders. We explain: once we kick off the initial sync, if you delete a file in the source environment, it’s still going to show up in the target.

So keep that in mind when you log into the new environment—some of the files you thought you deleted might still be there.

‍

Q: What do organizations tend to overlook during migrations like this?

A: Some of the most commonly overlooked data elements are permissions—especially shared ones, like guest sharing. That tends to get overlooked completely.

Even if you end up automating that through scripting, or if you need to tell your end users to manually re-share their items with external guests, it’s still one of the most common things we see that gets missed.

Calendar links during mailbox migrations are also really important. Sometimes they migrate fine, but in certain scenarios—depending on how they were created in the source environment—there can be issues.

They don’t always carry over, especially when it comes to Teams links. This isn't specific to Google Workspace—it’s more of a Teams issue. So you need to plan for it. You need a strategy in place to let your end users know that their recurring meetings will need to be recreated using a Teams link instead of the original Google invite.

Those scenarios have to be communicated. And as a post-migration step, you have to let your users know that it's their responsibility to go back and recreate those recurring meetings, or anywhere those special calendar links were used.

‍

Q: How did you get teams aligned on the new platform?

A:  We make sure we look at the executive sponsorship and the division alignment from a migration perspective—what kind of outcome they are expecting from that perspective.

Important stakeholders are aligned and engaged at the right point in time, and change management is implemented.

Then, you need to figure out whether you want to do a phased rollout. Do you want to do user segmentation in general? And figure out whether you want to handhold your C-suite box, or you want to do everything in a big bang approach, or you want to first do your IT department, or you want to take pieces from multiple departments. I’m a big fan of that. Instead of doing just a few users from an IT department, I would pick multiple users in the beginning—for doing the test migration or any scenario of that sort—where you have a diversity in your end user job function or job role specifications. So you cover multiple scenarios. And this helps from an integration standpoint. So if there are any other integrations that might break during the migration, in this scenario—when you’re picking up different users from different departments—they might come to the limelight, and you're able to document, manage, and plan accordingly.

I’ve talked so many times about communication strategy. You need to have a very well-written or well-planned, from a project plan perspective, specific section for communication.

Training and enabling your end users is also important from an adoption perspective. If things were done in your Google environment this way, this is how you do this in the Microsoft 365 environment. And there might be certain features that are much better—so you should highlight them. Or there could be features that are limiting—so you should call them out too. It goes both ways.

Data and workflow mapping is very important as well. So we take care of that from an alignment perspective.

You need to figure out what goes from where in the source to where in the target. Sometimes it’s not a lift-and-shift migration. In certain cases, we have to combine certain data sources to one SharePoint site, or we need to separate it out. In terms of “this belongs to this department,”  we’ll create those Microsoft Teams or standalone SharePoint sites as the requirement is—and then map that migration and migrate that data from that perspective. And of course, the end users get access to it, they test it, and then we redo it again, so things like permissions or deleted files don’t mess everything up.  That testing is really important because end users get hands-on experience and they can catch issues themselves.

Technical readiness and support is also very important—during and post-migration. You need to make sure you have the right people in your team and in your support team for any post-migration issues, and they are well aware of what happened and how you’ve taken the migration approach.

‍

Q: What advice would you give to IT teams preparing for their M&A migration from Google to Microsoft 365?

A: The very first thing would be to understand the context—why the migration is happening, right? That’s really important. You want to see which stakeholders are involved, what the expected outcome is at the end of the day, and what success looks like. Documenting that really helps. Be very, very thorough in your discovery; How you approach it and which workloads you want to migrate.

Identity and access management: make sure you do a good job understanding how all your single sign-on applications are integrated, how users are created, where they’re created, and what’s going to happen in the interim. Document that process. And make sure your HR team is involved from a particular date—like, from that point on, no new users are created in the source environment. Onboarding starts from a new process, in the new environment, especially in an M&A scenario.

It’s important to do this because communication is key. In certain scenarios, duplicate email addresses might come up. So, for example, if there’s a John in both environments, what happens then? You need to be ready for that. And make sure old emails are forwarded as needed.

I recommend setting that up if the domain is changing as part of the merger or acquisition. Even if the domain isn’t changing, maybe the login username will change but the email address will stay the same. Whatever the case is, make sure you document it clearly and manage it carefully.

Choosing the right migration tool is obviously very important. It really can make or break the success of the migration at the end of the day.

‍

“Choosing the right migration tool is obviously very important. It really can make or break the success of the migration at the end of the day.”

‍

From what I’ve seen, phased migrations tend to lead to better results than big-bang migrations—depending on the number of users, of course.

And aligning your change management and communication strategy helps a lot. Providing tailored training and support is important too. See if there’s budget and time available—and the energy, honestly—to invest in custom training and support for users.

Monitor your process and your plan. Measure what matters from a KPI standpoint, and then iterate. Fix what’s not working. This is where test migrations come in—figure out what’s working, what’s not, and adjust. Then move forward. Document those lessons learned and implement the right solutions based on the problems you ran into.

One big one is compliance. Legal and compliance considerations can vary. Maybe your source company has stricter or more relaxed security policies, and your target company is the opposite. That mismatch can cause real frustration—like if guest sharing isn’t allowed in SharePoint or OneDrive in the target environment. That’s a big issue sometimes.

So we try to document those things before the migration happens. For example, if there’s a business need to share with guest users or external users, and the current setup doesn’t support it, then we either confirm there’s an existing solution or help define one—something that allows the data to be shared securely and in compliance with the target company’s policies. That part is really important too.

‍

‍