Files off GCP, into SharePoint the team could run

The overview

A national public institution was consolidating work into Microsoft 365 while day-to-day files still lived on Google Cloud storage. The material was reachable, but it sat outside the platform where email, collaboration, and policy were moving. Staff opened folders by memory of old trees. Ownership and retention were hard to prove when someone asked a simple question: who owns this, and should it still be here?

The cutover could not be a dump into a default SharePoint library. That would have created a second place to search, not a system teams could run. This engagement migrated content from GCP into SharePoint with structure and permissions grounded in how the institution already worked.

The pain point

Operational files lived on Google Cloud while the rest of the estate was moving to Microsoft 365. Every week of delay deepened the split: some work in the new world, some trapped in the old store, and nobody sure which copy was authoritative.

Staff still hunted folders by memory; ownership and retention were unclear. New joiners inherited folklore about “where things live.” Records obligations existed on paper while practice stayed informal.

A cutover without a usable structure would strand the teams that open the files every day. Leadership needed speed; operators needed recognisable libraries. Those two needs are easy to say and hard to satisfy in the same migration.

Our approach

We ran this engagement through Betahood’s methodology: Kick-off, Discover, Build, and Deliver.

Kick-off

Kick-off aligned ICT and the business on the problem: files still lived on GCP while the estate moved to Microsoft 365. Constraints included continuity of access and recognisable structure for operators. Done meant SharePoint libraries teams could run without a parallel drive. Discover was the next step—not a blank template migration.

Discover

We inventoried collections, interviewed work-stream owners, and observed how staff find and name files today. Workshops mapped permissions to existing roles. A written migration and information-architecture specification defined waves, verification checks, and what stays frozen during cutover. Build and move work waited on that agreement.

Build

Build produced library structure, permission models, and migration tooling checks against source. Checkpoints verified sample collections with the people who open those files daily. Structure that felt foreign went back to Discover-level correction before the next wave.

Deliver

ICT and business users validated completeness and access before GCP was retired for those collections. Training and written handover covered library ownership and day-two operations. Support absorbed early findability questions. Teams opened Microsoft 365 libraries on Monday and continued work without a scavenger hunt.

What we delivered

We delivered a SharePoint library structure, migrated content from GCP, and access mapped to the roles that already owned the work. Libraries were named for the work streams that use them. Permissions followed existing accountability. ICT received a handover they could run.

The package covered inventory, information architecture, migration execution with checks, role-based access, and operational documentation for the teams who support Microsoft 365 day to day.

The outputs

Records and working files sit in Microsoft 365. Teams find libraries by the same names they already use. Access follows the roles already in place. The institution no longer maintains a second cloud store for the same material.

The migration succeeded as an operations outcome, not only as a bytes-moved metric: people opened the new libraries on Monday and continued their work without a scavenger hunt.

Client review

The people who run the process day to day were clear about what changed—and why the approach mattered as much as the software.