A migration announcement is the start of your test plan

Separate the released tool from the roadmap

Google’s 13 October announcement says its data import tool for Exchange Online, SharePoint Online, OneDrive and Teams is generally available. It places enhanced sensitivity-label and encrypted-content migration capabilities on a different timetable: scheduled for general availability by the end of 2026.

If you are evaluating a move to Workspace, use that distinction in your project plan. Ask the migration supplier to identify which capabilities your proposed scope needs and demonstrate their availability in your environment. A promised delivery date should not become an assumed capability in the cutover checklist.

Let the business define a successful move

Our recommendation is to start with one work process and its owner. Ask what the team must be able to do after the move, who must have access and which existing material they need to keep using. Turn those answers into observed tasks, rather than accepting a count of transferred objects as the whole acceptance test.

In a fictional UK consultancy, the pilot team chooses a completed project with invented customer data. Its acceptance exercise asks a project manager to find an old decision, open the associated document and involve an authorised colleague. The team also checks that someone outside the agreed audience cannot use the same access route. This is an illustrative test design, not a report of a migration we performed.

Test the awkward work before choosing a cutover

Ask colleagues to nominate a representative exception: a document with restricted handling, an unusual approval route or a conversation they regularly return to. Have the supplier explain how that specific case will work at the destination. Record the evidence and any unresolved dependency in the pilot notes.

Keep test material appropriately controlled. Do not copy sensitive production information into an unapproved trial just to make the demonstration realistic. Where synthetic material cannot represent the required behaviour, agree a properly authorised test with the information owner before proceeding.

For each failure, record the attempted task, expected result and actual result. Give the issue to a named owner and agree whether it blocks the move. An accepted exception needs the affected business owner’s decision; it should not disappear into a technical log nobody else reads.

Finish with a decision the sponsor can assess

Prepare a short pilot record showing which business tasks passed, what remains unresolved and who accepted any limitations. Include the proposed support route for colleagues after the move and the conditions under which the migration will pause. Ask the sponsor to approve that record before committing to the wider rollout.

We have not tested the announced migration capabilities. The useful next step is a bounded evaluation against your own working requirements, with roadmap dependencies visible. A successful demonstration gives you evidence for a decision; the announcement gives you something worth evaluating.