How long does a Workspace to Microsoft 365 migration take?

Assessment and design typically take a few weeks, and the migration itself scales with Drive volume rather than with user count, which surprises people who have budgeted around mailbox numbers. A few hundred users with a modest Drive estate is commonly a matter of weeks. The same user count with years of accumulated Drive content, heavy Apps Script use and complex shared drives is a materially longer project. The single biggest variable is how much content you decide to move rather than archive, which is why we push that decision early.

Will our Google Docs and Sheets survive the conversion?

Most will, and complex ones need checking rather than assuming. Simple documents and straightforward spreadsheets convert cleanly. What does not reliably survive is complexity: spreadsheets with intricate formulas, pivot structures, linked sheets or Apps Script attached, and heavily formatted documents. The practical approach is to identify your genuinely business-critical documents during assessment, validate those individually after conversion, and accept that a small number will need manual rework. Budgeting for that rework in advance is far better than discovering it as a surprise.

What happens to our Google Chat history?

It does not move into Teams in any complete sense, and the most useful thing you can do is tell people that clearly and early. Organisations that communicate it in advance get acceptance; organisations that let people discover it get complaints framed as a migration failure. If any of that history has a genuine retention or legal obligation attached, export it separately before the Workspace tenancy closes, because that option disappears with the subscription. For most businesses the honest position is that chat history was never treated as a record and nobody will miss it after the first fortnight.

What about all the links between our documents?

This is the most underestimated part of the whole project. Documents reference each other by Google URL, and those references appear in document bodies, inside spreadsheets, in calendar invitations and in old chat messages. After migration they resolve to the old location or to nothing, and there is no complete automated fix. Our approach is threefold: keep Workspace read-only for a period so old links still work, identify and correct links in the highest-traffic documents deliberately, and tell users plainly that some links will break so a broken link reads as expected rather than as a fault.

Can we move everybody in one weekend?

Below a certain size, yes, and a single cutover is genuinely simpler because it avoids coexistence entirely. Above roughly a couple of hundred users it becomes difficult to support, since the first hours after cutover generate a concentrated burst of questions and one team cannot absorb all of it at once. Phased migration means planning coexistence properly: mail routing, calendar free/busy visibility across both platforms, and a clear answer to where a given document currently lives. That is achievable and it is not free, and skipping the planning produces a fortnight where nobody can reliably book a meeting.

What happens to applications that log in with Google?

They need an equivalent or a decommissioning decision, and this is the item most likely to be missed. Single sign-on integrations, internal scripts calling Google APIs, third-party tools connected to Workspace and anything using a Google service account all stop working when identity moves. We inventory these during assessment, because finding them afterwards means an application outage attributed to the migration. Some turn out to be straightforward to repoint at Entra ID, some need rebuilding, and a satisfying number turn out to serve a process that no longer exists.

Should we move all our Drive content?

Almost certainly not, and a migration is the best opportunity you will ever get to leave content behind. Every estate contains a large volume of material untouched for years, duplicated copies, and content from projects that ended long ago. Migrating it costs time twice: once in the move and again forever afterwards in search results and storage. Our recommendation is to set an age threshold, archive rather than migrate anything below it, and move deliberately. Almost nobody takes this opportunity, which is why tidy new tenants routinely inherit a decade of clutter on day one.

Will people lose their email folders and labels?

No, but the mapping needs a deliberate decision because Gmail labels and Outlook folders are different concepts. A Gmail message can carry several labels; an Outlook message lives in one folder. Migration tooling has defaults for resolving this and the defaults are not always what you would choose. We agree the mapping before the pilot, test it with real mailboxes that use labels heavily, and communicate the outcome. Users notice their mail organisation within minutes of cutover, and it is disproportionately what they judge the whole migration on.

Do we need to keep paying for Workspace afterwards?

For a period, yes, and we would push you not to cancel it on cutover day. A read-only overlap keeps old document links resolving, lets users find things they did not realise they needed, and means any document whose conversion went badly can be re-exported rather than reconstructed from memory. We recommend keeping it long enough to cover a full business cycle including a month-end, announcing the end date at cutover so nobody is surprised, and exporting anything with a retention obligation before the tenancy closes for good.

Can you do this remotely? We are not in Hyderabad.

Yes, entirely. Assessment, design, migration execution and the support period afterwards are all delivered remotely, and platform migrations are among the most naturally remote work we do since everything involved is in two clouds. We are based in Gachibowli, Hyderabad and work with organisations across India, and where a client wants somebody present for a cutover weekend or for user floor-walking afterwards we will travel for it. Initial enquiries get a reply within 4 business hours.

Workspace to Microsoft 365, India

Mail is the easy half. Drive is where these migrations actually go wrong.

Mail, calendar and contacts move reasonably cleanly with mature tooling and predictable edge cases. Google Drive does not, because Docs, Sheets and Slides are not files in the sense Microsoft means, shared drive permissions do not map one to one onto SharePoint, and every document that links to another document links to a Google URL that will stop working. Plan around Drive and the rest follows. Plan around mail and you will discover Drive at the worst moment.

Book a migration assessment See what actually has to move

Microsoft

365

Cloud Solution Partner

Drive firstWhere the real work is
Native formatsDocs and Sheets need converting
Link rotThe most underestimated problem
CoexistenceFree/busy during a phased move

What has to move

Eight workstreams, and only the first is straightforward.

Migration proposals tend to describe this as moving mail and files. It is eight distinct pieces of work with different tooling, different risks and different failure modes, and the ones people plan for are not the ones that cause trouble.

Mail, which is the well-trodden part

Mailbox content moves with mature tooling and the edge cases are known: very large mailboxes, messages with unusual attachments, and labels, since Gmail labels are not folders and a message with several labels has to become something coherent in Outlook. Plan the label mapping deliberately rather than accepting a default, because users notice immediately and it is the first thing they judge the migration on.

Calendar, and the recurring meeting problem

Straightforward except for recurring meetings with exceptions, rooms and resources, and delegated access. Recurring series where individual occurrences were edited are where fidelity is lost, and they are common in exactly the calendars that matter most, meaning executives and shared team calendars. Test these specifically before cutover rather than discovering them in the first week.

Drive, and the format conversion nobody scoped

Google Docs, Sheets and Slides are not files with an equivalent on the Microsoft side, they are documents that live in Google. Migration converts them, and conversion is imperfect: complex spreadsheets with scripts, forms and pivot structures, and heavily formatted documents, all need checking rather than assuming. Identify the business-critical documents in advance and validate those individually.

Link rot between documents

The most consistently underestimated problem. Documents reference each other by Google URL, in document bodies, in sheets, in calendar invitations and in chat history. After migration those links still resolve to the old location, or to nothing. There is no complete automated fix, so the work is finding the highest-traffic documents and correcting their links deliberately during and after the move.

Shared drives and the permission model

Google shared drives and SharePoint document libraries are genuinely different models, and mapping one onto the other is a design decision rather than a technical conversion. Membership, manager and contributor roles, and the way access is inherited all differ. Doing this badly produces either a permissions mess or a set of libraries nobody can find, and it is where oversharing usually enters a new Microsoft tenant.

Chat, Meet and the collaboration habits around them

Google Chat history does not move into Teams in any complete sense, and organisations need to decide whether that matters and communicate the answer honestly. Meet to Teams is a change in habit rather than data, and the meeting links embedded in months of future calendar invitations all need reissuing, which is a task people reliably forget until the first meeting fails.

Identity, groups, aliases and delegation

Groups with their membership and posting permissions, aliases, delegated mailbox access, shared mailboxes and the applications authenticating against Google identity. That last one is the sleeper: single sign-on integrations, scripts using Google APIs, and third-party tools connected to Workspace all need an equivalent or a decommissioning decision before cutover, not after.

Coexistence, if you cannot move everybody at once

Any organisation too large for a single cutover needs a period where both platforms are live, and that period has to work. Mail routing, calendar free/busy visibility across the two systems, and a clear answer to where a given document lives today. Coexistence is achievable and it is not free, and organisations that skip planning it end up with a fortnight where nobody can book a meeting reliably.

The Drive problem

Eight things that go wrong with Google Drive, and how we handle each.

Drive is where the schedule slips and where users lose confidence. These are the specific failures, in the order they cause trouble, and none of them are avoidable by choosing better tooling.

Native format conversion

Docs, Sheets and Slides convert to Microsoft formats, and conversion fidelity varies with complexity. Simple documents are fine. Complex spreadsheets are not reliably fine.

Identify business-critical documents before the move and validate individually
Spreadsheets with scripts, forms or complex formulas need the most attention
Accept that some documents will need manual rework, and budget for it

Apps Script, which does not migrate

Automation written in Apps Script has no equivalent that comes across, and organisations frequently do not know how much they depend on it until it stops.

Inventory Apps Script usage during assessment, not after cutover
Rebuild in Power Automate where the process is still worth automating
Some scripts turn out to automate a process nobody needs any more

Links between documents

Every reference from one document to another is a Google URL. After migration those point at the old world, and there is no complete automated remedy.

Fix the high-traffic documents deliberately rather than attempting everything
Keep Workspace read-only for a period so old links still resolve
Tell users what to expect, since silent link failure erodes trust fastest

Shared drive permissions

The Google model and the SharePoint model differ in structure, not only in naming, so this is a design exercise rather than a mapping table.

Design the target library structure before migrating anything into it
Do not carry across access that was already too broad, since this is your chance
Manager, contributor and viewer roles need deliberate equivalents

Files owned by people who have left

Content sitting in the personal Drive of a departed employee, still referenced by current work. Common, and invisible until the account is deprovisioned.

Find orphaned ownership during assessment while the accounts still exist
Reassign ownership before migration rather than after
This is also the moment to delete what genuinely has no purpose

Version history that does not travel

Google keeps extensive revision history and not all of it comes across. For most content nobody minds; for regulated or contractual documents somebody will.

Establish early whether any content has a retention obligation on history
Export history separately for the small set where it genuinely matters
Decide and document the position rather than discovering it later

Volume, and the time it actually takes

Drive estates are usually larger than anybody expects and throttling is real. A migration sized on optimistic throughput slips, publicly, in front of users.

Measure real throughput on a pilot batch before committing to dates
Migrate in waves aligned to teams, not alphabetically
Run the bulk copy well ahead of cutover, with a delta pass at the end

Deciding what not to move

A migration is the best opportunity you will get to leave content behind, and almost nobody takes it, which is how a tidy new tenant inherits a decade of clutter.

Content untouched for years is an archive candidate, not a migration candidate
Archive to a cheaper location rather than migrating by default
Every gigabyte not moved is time saved twice, in migration and in future search

Why bring us in

We run both platforms, so the assessment is honest.

We support Google Workspace too

We are a Microsoft Partner and we also administer Workspace estates, so we have no interest in telling you the migration is simpler than it is. That also means we understand what you are leaving, which matters when deciding what has to be reproduced and what was never really used.

We scope Drive properly, because that is where projects slip

Most proposals price mail carefully and treat Drive as a volume number. We assess format complexity, Apps Script usage, shared drive structure and link density first, because those determine the effort and they are the reason migrations run over.

We design the target rather than mirroring the source

A new tenant is the one chance to not carry across a decade of accumulated sharing. We design the SharePoint structure and permission model deliberately, which costs a little planning and saves the oversharing remediation that otherwise arrives about a year later.

We plan the communication as carefully as the data

Users judge a migration on the first hour: whether their mail arrived, whether their calendar looks right, and whether the document they need opens. Telling people in advance what will not come across, particularly chat history, converts a complaint into an expectation.

What drives the move

Why Indian organisations switch.

A parent company standard

An acquisition or a group policy requiring alignment onto Microsoft. Usually comes with a date and limited negotiation, which makes coexistence planning more important rather than less.

Security and compliance requirements

A need for sensitivity labels, data loss prevention, information barriers or the wider Purview surface, frequently triggered by a customer security questionnaire or a DPDP programme.

BFSI and regulated sectors

Sector expectations and audit requirements that are easier to evidence on the Microsoft stack, particularly around retention, legal hold and administrative audit trails.

Consolidating onto one vendor

Organisations already running Windows, Teams or Azure who conclude that two identity providers and two collaboration platforms is one too many of each.

Education moving to a mixed model

Institutions that adopted Workspace for students and need Microsoft for staff and administration, where the answer is frequently coexistence rather than full migration.

Growth past what was set up informally

A Workspace tenant set up quickly in the early days by somebody who has since left, with no governance, and a business that has outgrown it.

Set expectations early

What comes across cleanly, what needs work, and what does not come at all.

Telling people this before cutover converts a complaint into an expectation. Almost every negative reaction to a Workspace migration traces back to somebody discovering one of these on the Monday rather than being told in advance.

	What	How it fares
Mail, contacts and calendar	Comes across well	Agree the label to folder mapping deliberately, and test recurring meetings with edited occurrences before cutover, since those are where fidelity is lost.
Files that were already Office formats	Comes across cleanly	Nothing special needed. These are the straightforward part of any Drive estate and usually a smaller share of it than people assume.
Google Docs, Sheets and Slides	Converted, with variable fidelity	Identify business-critical documents in advance and validate those individually. Complex spreadsheets need the most attention, and a few will need manual rework.
Links between documents	Breaks, and there is no complete fix	Fix the high-traffic documents deliberately, keep Workspace read-only so old links resolve for a period, and tell users so a broken link reads as expected.
Apps Script automation	Does not come across at all	Inventory during assessment, then rebuild in Power Automate where the process is still worth automating. A useful number turn out to automate something obsolete.
Google Chat history	Does not come across in any complete sense	Tell people clearly and early. Export separately where a genuine retention obligation attaches, before the Workspace tenancy closes.
Meet links in future invitations	Keep pointing at Google	Reissue future meeting invitations with Teams links as part of cutover, or the first meeting afterwards fails in front of everybody.

Two approaches

Tool-led migration against an assessed one.

Both move the data. One produces a fortnight of support tickets and a set of documents nobody trusts; the other costs more in planning and considerably less in everything afterwards.

Feature	Dimension	Tool-led
Scope	Everything, because the tool can	What should move, with archiving decided deliberately
Drive formats	Converted and assumed fine	Critical documents validated individually
Apps Script	Discovered when it stops working	Inventoried, with a decision on each
Document links	Break silently after cutover	High-traffic links fixed, users warned about the rest
SharePoint structure	Mirrors the Google structure, including its mistakes	Designed, with broad access not carried across
Coexistence	Not planned, so free/busy stops working	Mail routing and calendar visibility tested first
Users	Told it is happening	Told what will and will not come across
The week after	Support overwhelmed by predictable problems	A known list of exceptions, already being worked

Keep Workspace read-only for a while after you finish.

The instinct is to cancel the Google subscription the day the last mailbox lands, and it is the wrong instinct. Old links keep resolving, users find things they did not realise were missing, and the small number of documents whose conversion went badly can be re-exported rather than reconstructed. A read-only overlap period costs a fraction of what an emergency reconstruction costs, and it removes almost all of the pressure from the cutover itself. Decide the end date deliberately, tell people what it is, and then hold it.

Read-only rather than fully active, so nobody keeps working in the old platform
Long enough to cover a full business cycle, including month-end
Announce the end date at cutover, and remind people before it arrives
Export anything you are obliged to retain before the tenancy closes

The engagement

Five stages, and the pilot is the one that matters.

1
Assess both estates
Mailbox sizes and label structures, Drive volume and format complexity, shared drive membership, Apps Script usage, groups, aliases, delegation, and every application authenticating against Google. The output is a scope with the difficult items named rather than a volume figure.
2
Design the target
SharePoint structure and permission model designed rather than mirrored, Teams structure agreed, retention and label position decided, and the coexistence approach chosen. This is where you decide not to inherit the problems you currently have.
3
Run a real pilot for a full week
A cross-section of roles rather than volunteers from IT, running for a full week and ideally across a month-end. A pilot surfaces the things testing does not: the recurring meeting that lost its exceptions, the spreadsheet that converted badly, the integration nobody remembered.
4
Migrate in waves, with a delta pass
Bulk content copied well ahead of each cutover, a delta pass at the end to catch changes, and waves grouped by team so people who work together move together. Support arranged for the days after each wave, when the volume spikes and then falls quickly.
5
Fix links, decommission, and close out
High-traffic document links corrected, Workspace held read-only for an agreed period, anything with a retention obligation exported before the tenancy closes, and the remaining exceptions worked through rather than left. Then handover, or ongoing management.

Before cutover

Twelve checks before you move the first production user.

Worked through with every client before a production wave. Most post-migration complaints trace back to one of these having been assumed rather than verified.

Identity and routing

Domain verification complete and mail routing tested both ways
Test with real external senders, not internal mail
Every group, alias and shared mailbox has a target equivalent
Aliases are the commonest omission
Delegated mailbox and calendar access mapped
Executives notice this within an hour
Applications authenticating against Google identified
Single sign-on, scripts and third-party tools

Content

Business-critical documents identified and conversion validated
Complex spreadsheets specifically
Apps Script automation inventoried, with a decision on each
Rebuild, retire, or accept the loss
Orphaned files from departed staff reassigned
While the source accounts still exist
Target SharePoint structure designed, not improvised
This is where oversharing enters a new tenant

People

Users told what will and will not come across
Especially chat history and version history
Future meeting invitations reissued with Teams links
Otherwise the first meeting after cutover fails
A pilot group has run for a full week, including month-end if possible
One week beats any amount of testing
Support arrangements in place for the days after each wave
Volume spikes and then falls quickly

Questions we get asked

Workspace to Microsoft 365, answered plainly.

Around this decision.

Microsoft 365 vs Google Workspace

The platform decision itself, if you have not made it yet, compared on the things that actually differ rather than on feature lists.

Learn more

SharePoint permissions cleanup

How to avoid carrying accumulated oversharing into your new tenant, and what to do if it has already happened.

Learn more

Tenant to tenant migration

If the move is driven by an acquisition, the identity and domain constraints that make a cross-tenant migration a different project.

Learn more

Next step

Get Drive scoped before you agree a date.

Mail is predictable. Drive volume, format complexity, Apps Script usage and link density are what determine whether this project runs to plan, and they take a short assessment to establish. Remote-first from Hyderabad, serving all of India.

Book a migration assessment Compare the two platforms first

Related Services

Explore more solutions that work great with this service

Mail is the easy half. Drive is where these migrations actually go wrong.

Eight workstreams, and only the first is straightforward.

Mail, which is the well-trodden part

Calendar, and the recurring meeting problem

Drive, and the format conversion nobody scoped

Link rot between documents

Shared drives and the permission model

Chat, Meet and the collaboration habits around them

Identity, groups, aliases and delegation

Coexistence, if you cannot move everybody at once

Eight things that go wrong with Google Drive, and how we handle each.

Native format conversion

Apps Script, which does not migrate

Links between documents

Shared drive permissions

Files owned by people who have left

Version history that does not travel

Volume, and the time it actually takes

Deciding what not to move

We run both platforms, so the assessment is honest.

We support Google Workspace too

We scope Drive properly, because that is where projects slip

We design the target rather than mirroring the source

We plan the communication as carefully as the data

Why Indian organisations switch.

A parent company standard

Security and compliance requirements

BFSI and regulated sectors

Consolidating onto one vendor

Education moving to a mixed model

Growth past what was set up informally

What comes across cleanly, what needs work, and what does not come at all.

Tool-led migration against an assessed one.

Keep Workspace read-only for a while after you finish.

Five stages, and the pilot is the one that matters.

Assess both estates

Design the target

Run a real pilot for a full week

Migrate in waves, with a delta pass

Fix links, decommission, and close out

Twelve checks before you move the first production user.

Identity and routing

Content

People

Workspace to Microsoft 365, answered plainly.

How long does a Workspace to Microsoft 365 migration take?

Will our Google Docs and Sheets survive the conversion?

What happens to our Google Chat history?

What about all the links between our documents?

Can we move everybody in one weekend?

What happens to applications that log in with Google?

Should we move all our Drive content?

Will people lose their email folders and labels?

Do we need to keep paying for Workspace afterwards?

Can you do this remotely? We are not in Hyderabad.

Around this decision.

Microsoft 365 vs Google Workspace

SharePoint permissions cleanup

Tenant to tenant migration

Get Drive scoped before you agree a date.

Related Services

Microsoft 365

Google Workspace

SharePoint

File Server to SharePoint