We have run SharePoint migrations from file shares, on-premises SharePoint, Box, Dropbox, Google Workspace and platforms that no longer exist. The part most suppliers leave out is that moving content is the easy half. Move fifteen years of duplicates into a clean tenant and you have paid to relocate the mess, locked in the structure on the way through, and given Copilot fifteen years of duplicates to answer from.
A senior digital workplace consultant responds within one working day.
A lift & shift
Everything came over, including the things nobody had opened since 2014. Search got worse, not better.
Structure decided by the tool
The migration tool's default mapping became the information architecture, and nobody signed it off.
Content nobody meant to publish
Material that was effectively hidden on a file share became searchable the moment it landed in SharePoint.
Some of these are routine. Some need scripting because the source never stored content in a way that maps cleanly onto SharePoint.
Network drives, file servers, the shared drive nobody has audited since it was set up. The most common migration we are asked for, and the one where deciding what not to bring matters most.
SharePoint Server 2013, 2016 and 2019, including farms that have been upgraded in place more than once. Usually the point at which multiple legacy licences and forgotten customisations surface.
Acquisitions, divestments and group restructures. Technically the most constrained, because both sides are live and permissions have to survive the move.
Drive, Docs and Sheets into SharePoint and OneDrive. Format conversion is straightforward; the sharing model is not, because Google's link permissions rarely have a clean SharePoint equivalent.
Usually adopted departmentally, so the migration is also the moment the organisation discovers how much sits outside its own governance.
Jive, Lotus Notes, and intranet products whose vendors have been acquired or wound down. Jive is still a live source; Notes estates are rarer now but the ones that remain are usually the hardest. Read the migration case studies →
If you are still on SharePoint Server, this is now urgent. Microsoft ended support for SharePoint Server 2019 on 14 July 2026, and earlier versions went out of support before it. An unsupported platform holding your business content is a security and compliance problem before it is an IT one, and it is the single most common reason a migration lands on someone’s desk this year.
Almost every migration we deliver is part of something larger, and the ones that are not tend to be the ones that disappoint.
Content does not become findable because it changed address. It becomes findable because somebody decided how it should be organised, who owns it, and what should not have come over at all.
So a migration is usually a phase of something else – a new intranet, a knowledge management programme, a restructure after an acquisition, or a forced move off an unsupported platform. When it genuinely is a standalone project, it is normally because a deadline has removed the option of doing anything more thoughtful, and in that case we will say plainly what you are deferring rather than pretending the deadline solved it.
The reason this matters commercially is timing. Restructuring a tenant after the content has landed is a project in its own right. Doing it during the migration costs almost nothing extra, because everything is being touched anyway. A migration is the one economically sensible moment to fix structure, and it does not come round again.
We will also tell you when a migration is not what you need. If the problem is that nobody can find anything, moving it somewhere new does not address that, and we would rather start with a discovery than sell you a data transfer that leaves you where you started.
An intranet build
Migration runs as a workstream alongside it, and at enterprise volumes it usually sets the critical path rather than following it.
A knowledge management programme
Where restructuring the content is the actual point.
An acquisition or divestment
Tenant-to-tenant, usually under a legal deadline.
A forced move
An unsupported platform or a licence expiring.
None of these are tooling failures. The tools are good. These are decisions nobody was asked to make.
Material that was effectively lost on a file share - buried in a folder nobody navigated to, protected by obscurity rather than permissions - becomes fully indexed the moment it lands in SharePoint. Salary letters, disciplinary files, old commercial terms. All of it findable.
The single most serious migration risk, and not one competitor page in this SERP mentions it.
Migration tools map source structure onto destination structure. That is what they are for. But if nobody has designed the destination, the folder hierarchy from a 2012 file server quietly becomes your information architecture, and unpicking it later means moving everything twice.
This is why we bring information architecture work forward, into the migration rather than after it.
Copilot has no way of knowing which of the four near-identical policy documents is current. Migrate all four and it will answer confidently from whichever it finds first. AI has not created a new problem here - it has made an old content problem visible and expensive.
What you migrate decides what Copilot can answer from. See Microsoft AI and Copilot.
Documents arrive in SharePoint without the metadata they need to be useful, because the source system never captured it. Mapping what exists onto what is needed - and deciding what has to be added by hand - is usually the least glamorous and most valuable part of the work.
Where content types and taxonomy get decided, whether or not anyone plans it.
Migrations are delivered by technical teams and experienced by everyone else. People arrive on Monday and cannot find the thing they used on Friday. If nobody has planned for that, the migration succeeds technically and fails in every way the business notices.
Adoption is part of the migration, not a phase after it.
Archives accumulated through acquisitions, kept for compliance, that nobody will ever open. They may genuinely need retaining - but retaining is not the same as migrating into your live environment where they dilute search for everybody.
A migration is a chance to bring over only what earns its place. Most suppliers will not tell you that, because scope is revenue.
Five stages. The first one is where the real decisions get made, and it is also the one most likely to be bigger than anyone expected.
1
What exists, where, how much of it, who owns it, when it was last opened, and what it depends on. Volumes, formats, permissions, customisations and integrations all get catalogued.
Be prepared for this to be larger than it sounds. Where a landscape has been built up over years - several legacy SharePoint licences, a few forgotten customisations, a file server that predates the current IT team - the audit is genuinely a project in its own right rather than a preliminary. We would rather tell you that now than discover it in week three.
2
Content is reviewed against value rather than volume: what is current, what is duplicated, what is genuinely referenced, and what needs retaining without cluttering the live environment. Archive, delete and leave-behind are all valid outcomes.
Site and content owners do most of this triage themselves, with a framework and deadlines from us. They know which of the four policy documents is current, and no external team can work that out faster than they can.
3
Structure, navigation, permissions model, content types and metadata mapping - decided before anything moves, not inferred from the source afterwards. This is the stage that determines whether search works when you arrive.
4
A pilot first, with a real department and real users, so the mapping gets tested before it is applied to everything. Then waves, with validation, delta syncs to catch anything changed mid-flight, and integrity checks against the inventory from stage one.
5
Communications, training for the people who now have to find things somewhere new, decommissioning of the source, and a review once people have actually used it. Migrations are experienced by end users, not by project teams.
Nobody can price a migration honestly without the audit. What they can do is tell you which variables move the number, so you can see where you sit.
For an enterprise migration, three months is the floor and three to nine months is the normal range. Anyone quoting a few weeks for an estate of this size is quoting for the moving and not for the deciding – and the deciding is where the value and most of the elapsed time sit. The audit is scoped and fixed before you commit to anything beyond it, and it is what prices the rest honestly.
Worth distinguishing this from intranet re-platforming, which is a different piece of work. Moving from a third-party intranet product onto Lightspeed365 typically runs four to eight weeks, because the content volumes are smaller and the destination is already built.
The worked examples in this market tend to be small. Ours are not.
Where it sits
Not our criteria. These are the ones buyers are advised to apply, so here are our answers.
If the honest answer is that nobody knows what is on the file shares or who owns it, the audit is the project and the migration is what follows.
Replacing a third-party intranet platform is re-platforming rather than content migration, and it has its own route.
If the reason for moving is that nobody can find anything, the real work is structure - how content is organised, named, owned and navigated when it lands.
All of it sits under our SharePoint consultancy practice.
Tell us what you are moving and why. Sometimes the answer is a straightforward migration and we will get on with it. More often the interesting question turns out to be what should not come over – and occasionally the honest answer is that moving it will not fix what is wrong.
No, and the way that is assured is validation rather than assurances. Everything is inventoried before it moves, migrated in waves with a pilot first, then checked back against that inventory, with delta syncs to catch anything that changed while the migration was running. Permissions are mapped deliberately rather than carried over automatically, because source permission models – particularly Google’s link sharing and file share group nesting – often have no clean SharePoint equivalent, and copying them blindly is how content ends up more widely visible than intended.
For an enterprise estate, three months is the realistic floor and three to nine months is the normal range. The variable is not the moving – that part is largely automated and fast – it is the auditing, the content triage and the decisions about what should not come over. A single file server for a few hundred people with clear ownership sits at the short end. A multi-region estate with several legacy SharePoint farms, forgotten customisations and no current content owners is a nine-month programme, and compressing it does not make it shorter, it just moves the work to after go-live. The audit tells you which you are, and it is scoped and priced before you commit to anything beyond it.
Almost never, and this is the decision that determines whether the migration was worth doing. Moving everything is cheaper on the day and more expensive every day afterwards: search degrades because duplicates and dead content dilute it, Copilot answers from whichever version it finds first, and restructuring later means touching everything twice. Content decisions during a migration cost very little because everything is being handled anyway. The same decisions afterwards are a separate project.
Third-party tooling, chosen to suit the source, and we are deliberately not precious about it. The migration tools in this market are mature and good – ShareGate, Microsoft’s own Migration Manager and others do the mechanical work reliably. What they cannot do is decide what deserves to move, design where it should land, or work out which of four similar documents is the current one. That judgement is the part we are paid for, and it is why a tool licence is not a substitute for a migration plan.
Urgent, if you want a supported platform. Microsoft ended support for SharePoint Server 2019 on 14 July 2026, and earlier versions were already out of support before that. Unsupported means no security updates for a system holding your business content, which is a compliance question as much as a technical one. There is also a practical consideration: on-premises estates tend to carry the most accumulated customisation, so the audit takes longer, and the timeline is not as short as the deadline makes it feel.
If you mean moving content into a new SharePoint environment, yes – that is this service. If you mean replacing a third-party intranet product such as LiveTiles, Wizdom or a similar platform, that is re-platforming rather than content migration, and it is handled by our own intranet product Lightspeed365. The distinction matters because those products often store content outside SharePoint, which means the migration needs scripting rather than copying, and because the destination decision comes before the migration one.
