SharePoint Migration to SharePoint Online
Support for SharePoint Server 2019 ended on 14 July 2026. We move content and permissions into the cloud – and give every old customisation a verdict before we do: replace, keep or drop entirely.
The content moves, the customisations do not
Copying files is the easy part; there are tools for that. What makes a migration hard is everything that has grown up around the document store over twelve years: the view that colours overdue rows. The form that works out the flat rate. The workflow that sends the shift rota round every Monday. These are small applications – it is just that nobody ever treated them as such.
They sit on techniques that no longer exist in SharePoint Online: JSLink, sandbox and farm solutions, InfoPath, Designer workflows. The real difficulty, though, is not the replacement but the question that comes before it. Is anybody still using any of this? Whoever built them has usually left the company, documentation is rare, and ask around and every department gives the same answer: indispensable.
That uncertainty produces the two expensive mistakes – trying to take everything across, which founders on the technology, or rebuilding everything, which costs a multiple and mostly covers things nobody opens any more. So the project starts with a count, not with a copy. Only once every item has a verdict can anyone say whether the move is a quarter or a year.
Where the real work in a migration sits
The files are rarely the problem. These six areas decide how big the project becomes – and we work through them in this order.
Document stores and team sites
The most common starting point and the least dramatic part: libraries, metadata and versions move across, and the permissions get reordered on the way.
InfoPath forms
Simple data capture becomes a Power App, complicated forms become a project of their own – and a share of them is dropped without replacement.
Designer workflows
Approvals, reminders, status changes. What is genuinely needed is rebuilt in Power Automate – not every step from the old diagram.
JSLink and display logic
Coloured views, traffic lights, hidden columns. Much of that can be done with column formatting today, with no code at all.
Sandbox and farm solutions
Everything that was ever installed on the server itself. What stays is rebuilt as an SPFx web part; the rest disappears with the server.
Site structure and navigation
Subsites that grew over the years become sites in their own right, joined by a hub. That decision is taken before the migration, not during it.
An extract from the legacy inventory
Every item gets a verdict: keep, replace or drop entirely. Only counting the three groups shows how big the move actually is.
- 11 keep Moves across unchanged, standard features only.
- 7 replace Gets rebuilt – the only group that costs development.
- 23 drop No hits in the past year, no process behind it.
| Item | Built with | Usage | Verdict |
|---|---|---|---|
| View “Asset register”Engineering site | JSLink | opened daily | replaceColumn formatting, no code |
| Form “Leave request”HR | InfoPath | used weekly | replacePower Apps and Power Automate |
| Workflow “Invoice approval”Finance | Designer 2013 | runs daily | replacePower Automate, two stages |
| Web part “Sales figures”Sales | Sandbox solution | last opened 11/2022 | dropReport comes from Power BI |
| Workflow “Visitor sign-in”Reception | Designer 2010 | last run 2019 | dropProcess no longer exists |
| Library “Contracts”Legal | Standard | in daily use | keepmoves with its versions |
What matters is not the total but the middle group: only what gets replaced costs development.
Sample analysis, six of 41 items – deliberately the contested ones. How big the “replace” group turns out to be in your case only your own inventory will show.
From the inventory to the first stage in production
-
Take the inventory
We read the estate out by machine: JSLink references, installed solutions, InfoPath forms, Designer workflows, master pages – plus the access figures from the usage logs.
-
Triage with the departments
Every item gets a verdict. IT does not decide that on its own; the department that works with the thing does, on the evidence of how often it is actually opened.
-
Agree the target structure
Site collections instead of nested subsites, hubs for the navigation, permissions through groups from Entra ID. Settled before the first byte is copied.
-
Migrate in stages
Department by department, with a pre-load and a delta run on switchover day. The old system then stays readable for an agreed period.
-
Build the replacements and sign them off
The “replace” group is rebuilt as an SPFx web part, a flow or a Power App. It goes live only once the department has signed it off.
What changes after the move
Today
- The server still runs, but without security updates
- Nobody knows which customisations are still in use
- Forms and workflows depend on individual people
- Permissions have grown at the level of single items
- Every change needs a maintenance window
After the migration
- The content sits in SharePoint Online, updated continuously
- Every item has a verdict and a reason behind it
- Forms run in Power Apps, approvals in Power Automate
- Permissions hang on groups instead of single items
- The department changes views and columns itself
When you should not book this migration
Moving to the cloud is not the right route for every organisation. We settle these four points before we quote:
- If you have to stay on your own server, this is the wrong product. Anyone who keeps systems on-premises for regulatory or contractual reasons does not need SharePoint Online but an upgrade to the SharePoint Server Subscription Edition – a different project with different tools.
- There is no replica of the old world. Master pages, custom branding and JSLink views do not come back; modern SharePoint looks different. Treat training and internal communication as a side issue and you end up with a technically clean migration that the business reads as a step backwards.
- Some replacements cost money for good. An InfoPath form that talked to a database or to your ERP usually needs premium connectors once it is a Power App, and that means a licence per person per month. We work the figures out in advance; change them we cannot.
- The pace is set by data volume and sign-offs, not by the tool. Large libraries with a long version history take time, and Microsoft throttles transfers whichever tool you use. If a department has no capacity to test, we postpone the next stage rather than release it unchecked.
Source and target environment
Scope and price
The entry price covers the analysis with triage and the first migration stage. We cost the rest once we know what has to be replaced.
- Machine-read inventory of every customisation, form and workflow
- Usage evidence per item, taken from the access logs
- Triage with a verdict per item, agreed with the departments
- Target structure with site collections, hubs and group permissions
- Migration of the first department including versions and permissions
- Replacement of the most important customisation as an SPFx web part or flow
- Migration roadmap, documentation and a fixed price for the later stages
What increases the price
- Number of items that land in the “replace” group
- InfoPath forms with custom code or links into third-party systems
- Data volume, version history and number of site collections
- Item-level permissions that have to be reordered
- Running the old and the new side by side over several months
What the later stages cost depends on how many items land in the “replace” group. We name the binding fixed price for them after the analysis – any earlier and it would be guesswork.
All prices excl. VAT · licences for Power Apps and Power Automate are not included
What you get
-
Legacy inventory with a verdict
Every item with its technology, its usage evidence and the decision – the basis for all planning
-
Staged migration roadmap
Order, dates, owners and effort estimates so you can budget the later stages
-
First stage in production
One department fully in SharePoint Online, with the most important replacement built
-
Documentation, source code and 60 days of support
Target structure and permission logic in writing, source code for every new component
Frequently asked questions about SharePoint migration
These solutions fit alongside
SharePoint Web Parts with SPFx
The tool of the replacement: a single customisation rebuilt as a cloud-ready web part.
SharePoint Document Workflows
What becomes of Designer workflows: approvals and versioning in Power Automate.
SharePoint Intranet Suite
For when the homepage and the navigation are rebuilt after the move as well.
SharePoint Copilot Apps
The step after: answers drawn from content that has just been put in order.
How big is your legacy pile really?
In the free intro call we look at what is running on your server and give a first estimate of how much of it actually has to be replaced. Afterwards you know whether the move is a quarter or a year.
Book a free intro call