Content Migration Was Never the Technical Problem

Ask a SharePoint migration specialist where projects actually go wrong, and the answer is rarely the software. Zoe Bennett of Fresh Intranet and Shannon Ford of Microsoft – both who spend their working lives moving organizations’ content into SharePoint Online, made that case directly to David Bowman on Fresh Intranet’s Fresh Perspectives podcast. The technical migration, in their account, is often the easy part. Everything that determines whether it succeeds happens around it.

IT thinks it’s a checkbox. It rarely is.

The pattern repeats across nearly every engagement: the first conversation comes from IT, or from a single part of the business, and it arrives with a simplified picture already attached – just lift everything over, move it to the cloud, done. Zoe and Shannon’s first move is almost always to push back on that framing. Real scoping means talking to the people who actually own the content across departments, not the project team overseeing the migration from above.

That gap between the tidy version of the project and the messy reality underneath is not a failure of planning. It is the normal starting condition. Organizations that treat the initial IT conversation as sufficient tend to discover, mid-project, that they are migrating content nobody can explain the value of – or missing content that quietly runs a department’s work.

Content ownership is binary, not middling

One of the more striking patterns Zoe and Shannon described is how little middle ground exists in how well people understand their own content. Some employees maintain immaculate, well-labeled structures and know exactly where everything lives. Others cannot describe what they have or where they saved it – even when asked directly. There is rarely an in-between. The organizations that fare best in migration are not the ones with the least content. They are the ones where more of that content sits with the first group.

Copilot has raised the cost of sloppy permissions

Permissions management has always been a migration headache, since legacy systems rarely map cleanly onto how SharePoint Online handles access. What has changed is the stakes. With Microsoft Copilot now pulling answers from whatever it can access, badly managed permissions do not just create administrative confusion – they actively surface content that should never have been findable in the first place. Migrations that skip proper security trimming and version reconciliation are not just carrying forward old mess; they are handing that mess a much larger microphone.

The same logic applies to duplicate documents and version sprawl – the familiar graveyard of files ending in v1, v2, v3_final. Reconciling those duplicates during migration, rather than carrying all of them across, is what determines whether Copilot’s output can be trusted as a current source of truth.

Metadata is undervalued because the payoff is invisible upfront

Metadata – structured information about a document, rather than the document itself – is what makes SharePoint search actually work, and what allows organizations to build views by relevance instead of forcing everyone through deep folder structures. Most organizations, in Zoe and Shannon’s experience, treat it as an afterthought. Getting people to see the value takes a live demonstration of what better search results look like. Getting people to consistently fill metadata in, once the demo ends, is the much harder and more permanent behavior change.

Manual, automated, or scripted – the content type decides

Not all content migrates the same way. Page-based intranet content – news posts, web parts, visually designed pages – is largely rebuilt by hand, since automated tools rarely reproduce layout and formatting acceptably. Document management content is the opposite case: better suited to native migration tooling or custom scripting, since the volume makes manual recreation impractical. Knowing which category a given migration falls into, before choosing a method, is what separates a realistic project timeline from an optimistic one.

The real failure point is adoption, not migration

Zoe described a project where the technical migration succeeded by every measure: a fully built Microsoft Teams front end, SharePoint quietly doing the file storage behind it. The rollout still failed, because the shift was too large a jump for users, who went back to saving files locally rather than working inside the new structure. The lesson she draws is one that will be familiar to any internal communicator: the migration is not finished when the technology goes live. It is finished when people’s behavior has actually changed – and that requires sustained communication and reinforcement well past go-live, not a training session on launch day.

What to do before calling a vendor

Zoe and Shannon’s advice for organizations at the start of this process has less to do with SharePoint than with internal communication. Get the message flowing internally before the vendor conversations start, so the change does not land on employees as something happening to them without warning. Begin cleaning up content in parallel, so the migration project inherits less of the existing mess. And treat the migration itself as one step inside a broader digital strategy – the move to the cloud is rarely the destination, only the first piece of a longer picture that needs buy-in on its own terms.

None of that is a technology recommendation. It is a communication and change management one, delivered by two people whose day job is the technology.

This article is adapted from a conversation with Zoe and Shannon of Advania on Fresh Intranet’s Fresh Perspectives podcast, hosted by David Bowman.