Workspace migration: Microsoft checklist

A Workspace migration changes where people do their daily work. Google Workspace and Microsoft 365 are business software suites used for work such as email, calendars and documents. Moving between them requires decisions about accounts, records and the processes that depend on them. A successful import only answers the questions within its tested scope.

Check whether Google's setup import fits your team

Google's announcement dated 11 September 2026 describes a generally available setup path that can automatically import up to ten Microsoft users and their data. The listed categories are email, OneDrive files, calendar events, contacts and tasks. A larger organisation needs another path. This announcement does not establish that Teams, SharePoint or every shared resource is included.

The process is admin-only and runs in the background during setup. Google specifies Microsoft global administrator credentials, completed domain verification and MX activation as prerequisites. Domain verification establishes control of the domain; MX records direct incoming email. These are operational changes for the responsible administrator to plan, not boxes to tick casually during a trial.

The announcement describes a Flexible Plan path. Annual or Fixed-Term plans require licences to be added before importing users. Check the current setup instructions, eligibility and subscription commitments with the responsible supplier before authorising work. The availability of an import tool does not settle the cost, scope or support responsibilities of the whole move.

First establish why you want to move. If the problem is unclear ownership, duplicated documents or a broken approval process, a different software suite will still need agreed working practices. List what already works, the improvement you want and the accounts, shared resources and connected applications involved. Test critical integrations separately from the listed import categories.

Work through a migration decision

Use this worked example to decide whether a proposed move is ready for staff. It follows a fictional eight-person consultancy that uses Microsoft 365 and is evaluating Google Workspace. The people, records, test results and decisions below are hypothetical. They illustrate a method, not a reported client project. The pilot uses a separately authorised, controlled test environment with fictional records and test identities. It does not change the business's live domain or mail routing. These are business acceptance exercises, not instructions to run Google's setup import against a production domain before its prerequisites are met. The administrator must choose a suitable isolated test arrangement and satisfy the selected method's prerequisites there. Live domain and mail-routing changes need their own approved plan.

Start with the work the business must complete

The consultancy wants one agreed place to manage project correspondence and approved documents. Its operations manager defines the acceptance task: a consultant must find a project request, open the correct document, obtain approval and hand the work to a colleague. The authorised colleague must be able to continue the job, while someone outside the project must not gain access.

The office manager also needs to maintain bookings without creating duplicate appointments. These requirements matter more to the cutover decision than whether the migration dashboard reaches its final percentage.

The business assigns an operations manager to accept the workflows, a migration administrator to run and reconcile the technical work, and an IT supplier to investigate unresolved methods and configurations. The managing director owns the decision to change the working service. These are assigned responsibilities in this example, not assumptions that a software licence includes migration support.

Keep proved scope separate from planned work

The team creates this inventory before approving a date. It records what the fictional pilot has demonstrated and what remains outside that evidence. "Proved" applies only to the named objects and checks, not the whole product or every account.

For your own migration, retain an identifier for each source object and its expected destination or agreed disposition. Record exclusions and unresolved items explicitly. Where the chosen tooling cannot provide a reliable comparison, document the gap and agree another check before calling the population reconciled.

A sample can show that particular records are usable. It cannot prove that an unexamined mailbox or file collection is complete. Keep transfer reconciliation and business acceptance as separate results.

A failed acceptance test changes the decision

The administrator reports that the 12 selected files transferred and can be opened. The operations manager then runs the agreed project task using test records and ordinary staff permissions.

The first consultant finds the request and opens the proposal. The colleague taking over the project cannot open the approval record. The team also finds that an account outside the project can open a document it should not see. No real client data is used in this exercise.

The test fails even though all 12 files exist. It has exposed two different problems: an authorised person cannot complete the handover, and an unauthorised person has access. Counting files again will not resolve either one.

The administrator restricts access to the affected test material and investigates the permission mapping. The operations manager confirms who should approve and receive the document. The supplier helps determine which configuration or separate process needs changing. The planned retest must check both permitted and denied access after the correction, then repeat the complete handover task. At this point, no successful retest has been recorded.

A later passing retest would close those specific findings. It does not automatically accept the shared enquiry address, bookings, other users or older records. Their inventory entries remain open until their owners provide evidence.

Record the actual go or no-go decision

At the scheduled review, the fictional team's decision is no-go for the business cutover. The permission test has failed, the enquiry process has no accepted destination and booking ownership remains untested. Staff continue using the agreed source service. The administrator may continue the controlled test exercise, but that permission does not authorise production routing changes or source retirement.

The decision record names the managing director as approver and the operations manager as coordinator. It gives the administrator responsibility for the access repair, the office manager responsibility for the enquiry and booking tests, and the records owner responsibility for the older-record decision. Each owner must return evidence before the next review. A new calendar date alone is not a reason to approve the move.

The team will reconsider when the affected access tests pass, the shared enquiry and booking workflows have accepted arrangements, the remaining account and record populations have reconciled dispositions, and the support and recovery plan is ready. Any accepted exception needs a defined impact, an owner and an authorised business decision. An unknown critical workflow remains an unresolved condition.

If those conditions cannot be met within the available resources, the business can defer the migration or reassess whether moving is the right project. Keeping a working service while resolving the evidence is a valid outcome.

Make the cutover handover explicit

Before a later approved cutover, the administrator must explain the chosen migration path's sequence and any prerequisites. The team should not invent a universal order for domain, account, import or mail-routing changes. Those steps depend on the verified method.

The operations manager records which service staff should use for each activity at each stage. Staff receive a clear instruction about where to create new work, where to find retained records and how to report a missing item. The support lead receives the unresolved-issue register, approved exceptions, contact arrangements and the authority to escalate. The administrator retains ownership of transfer errors until the support lead explicitly accepts the handover.

The change record states who may pause the move and which failed checks require escalation. In this example, loss of the enquiry workflow or a failed permission check stops further rollout. The managing director decides whether to continue, defer or invoke the approved recovery plan, with technical advice from the administrator and business impact from the operations manager.

Plan recovery without losing work created during the move

For Google's setup import, the administrator guidance distinguishes copying from recovery. It says the import does not modify or delete source data. Stopping an import can take a few minutes and does not roll back imported data. The stopped import cannot be restarted, and importing the same content more than once can create duplicates. Google points to separate default import methods when more data needs to be brought across.

That means "stop and try again" is not a complete recovery procedure. Record what reached the destination, determine the appropriate next method and check for duplicates before authorising further work. Do not treat a preserved source as proof that destination changes can be reversed automatically.

Returning staff to an earlier system is not the same as reversing every change. Messages, file edits and bookings may have been created after the agreed checkpoint. The recovery plan must say where that work is, who will preserve it and how conflicting copies will be resolved.

Before execution, the administrator records the checkpoint and the information needed to identify subsequent changes. The operations manager assigns a business owner to decide which version of a disputed record is authoritative. The support lead tells staff which service to use and records reports of missing or duplicated work. The administrator performs approved reconciliation steps and retains the evidence; the relevant business owner accepts the result.

Consider a second hypothetical exercise in the same isolated test environment. Staff create three new test project notes and change one test booking before the team decides to return to the source workflow. The administrator identifies all four changes and prevents further test edits during reconciliation. The project owner approves the three notes for controlled transfer, and the office manager checks the booking against its previous state before approving the single intended change. The team checks that it has neither lost the notes nor duplicated the booking.

Those four items form the exercise's complete change set. A real recovery needs evidence for its actual population, a tested method and a decision about conflicts. Do not assume that changing routing or signing into the old account moves later work back automatically.

Keep the source environment under an explicit access, retention and closure decision. Migration completion does not, by itself, authorise deleting records or ending a service that staff still need for recovery.

Bring the unresolved decision to the right owner

Take one critical workflow and write its acceptance result before committing to a cutover. If the result is unknown or failed, name the missing evidence and the person who can obtain it. That produces a decision the business can review.

If ownership, supplier responsibilities or the investment decision remain unclear, my IT management consulting can help scope a management review, assess supplier arrangements and agree a practical roadmap with your existing team. Discuss your migration plan with the inventory, failed test and proposed cutover conditions. We can agree the decisions and handover needed before defining the engagement. Technical execution responsibilities and any specialist work must be agreed as part of that scope.