Content, permissions, metadata and version history moved without loss, and the workflows, forms and customisations rebuilt on the other side. Most migration providers move your files and leave. We are engineers as well, so we can put back what the move broke.
Nobody plans a migration for its own sake. Something forces it. If one of these is your situation, the rest of this page is written for you.
Two organisations, two Microsoft 365 tenants, and a deadline by which people need to work as one company. Tenant-to-tenant migration is the most constrained kind of move: identities, permissions, mailboxes and content all have to arrive together, and the business rarely gets to pause while it happens.
Separating one business unit's content out of a shared tenant, cleanly enough to satisfy the buyer and the lawyers. Harder than a merger in one respect: you have to prove what left and what stayed.
On-premises SharePoint that is approaching, or has passed, the end of Microsoft's support. The content migration is usually the straightforward part. The customisations built on top of it are not.
File servers and NAS being decommissioned, with years of accumulated content that has to go somewhere governed and searchable rather than into another drive nobody manages.
SharePoint and OneDrive storage that has grown past its included allowance, with most of the volume being content nobody has opened in years. This is frequently an archiving problem rather than a migration one, and the two are worth separating before you spend anything.
Organisations already paying for Microsoft 365 and also paying for a second storage platform. Consolidation removes a licence line, a security surface and a place where content hides, but permission models rarely map across cleanly, which is where these projects usually stall.
Content that must be held in a specific region, retained for a defined period, or moved out of a system that cannot evidence what happened to it. The move itself is often less demanding than proving it was done correctly.
Mapped drives with fifteen levels of folders, permissions granted a decade ago to people who have left, and no way to search, classify or secure any of it. The content usually matters; the structure almost never survives contact with a migration.
We have successfully migrated data from Windows file shares and NAS, and between Microsoft 365 tenants. Our migration platform also has the connectors and capabilities to support Google Drive, Dropbox, Box, AWS S3 and SharePoint Server 2013, 2016 and 2019, subject to source-system assessment and project requirements.
Mapped drives, file servers and network-attached storage into SharePoint document libraries. We map NTFS permissions to SharePoint groups rather than recreating them one-for-one, because a permission structure built up over a decade of ad-hoc grants should not be carried forward unchanged. Long paths, illegal characters, versioned duplicates and orphaned owners all get handled explicitly during assessment rather than discovered mid-migration.
Shared Drives and My Drive content into SharePoint and OneDrive, including native Google file conversion to Office formats. Sharing permissions in Google do not map cleanly onto Microsoft 365, link-based access in particular, so we report the differences before the move rather than leaving you to find out afterwards.
Dropbox Business and team folders into SharePoint, with folder structure, versions and sharing arrangements assessed and mapped. Commonly a licence-consolidation project as much as a content one: the saving is usually the reason it gets approved.
Box content, metadata and permissions into SharePoint. Box's metadata templates and custom fields often carry real business value, so we map them to SharePoint content types and managed metadata rather than flattening them into folders.
Content held in S3 buckets into SharePoint, or into Azure storage where it is better suited. Frequently relevant where an application has been writing documents to S3 for years and the business now needs them governed, searchable and accessible alongside everything else in Microsoft 365.
SharePoint 2013, 2016 and 2019 into SharePoint Online. Site collections, libraries, lists, metadata and version history migrate; classic customisations, workflows and InfoPath forms do not, and have to be rebuilt. We identify which is which during assessment, and we can do the rebuild as well as the move.
Consolidating two tenants after an acquisition, or separating one after a divestiture. SharePoint sites, OneDrive content, Teams files and the permission structures behind them. The sequencing matters more than the tooling here: identity has to be resolved before content moves, and the cutover has to be planned around how the business actually works.
We support migration from a range of document management and enterprise content management platforms, with each source system assessed case by case to determine the appropriate migration approach, tooling, metadata mapping, permissions and content transformation requirements.
Mapped drives, file servers and network-attached storage into SharePoint document libraries. We map NTFS permissions to SharePoint groups rather than recreating them one-for-one, because a permission structure built up over a decade of ad-hoc grants should not be carried forward unchanged. Long paths, illegal characters, versioned duplicates and orphaned owners all get handled explicitly during assessment rather than discovered mid-migration.
Shared Drives and My Drive content into SharePoint and OneDrive, including native Google file conversion to Office formats. Sharing permissions in Google do not map cleanly onto Microsoft 365, link-based access in particular, so we report the differences before the move rather than leaving you to find out afterwards.
Dropbox Business and team folders into SharePoint, with folder structure, versions and sharing arrangements assessed and mapped. Commonly a licence-consolidation project as much as a content one: the saving is usually the reason it gets approved.
Box content, metadata and permissions into SharePoint. Box's metadata templates and custom fields often carry real business value, so we map them to SharePoint content types and managed metadata rather than flattening them into folders.
Content held in S3 buckets into SharePoint, or into Azure storage where it is better suited. Frequently relevant where an application has been writing documents to S3 for years and the business now needs them governed, searchable and accessible alongside everything else in Microsoft 365.
SharePoint 2013, 2016 and 2019 into SharePoint Online. Site collections, libraries, lists, metadata and version history migrate; classic customisations, workflows and InfoPath forms do not, and have to be rebuilt. We identify which is which during assessment, and we can do the rebuild as well as the move.
Consolidating two tenants after an acquisition, or separating one after a divestiture. SharePoint sites, OneDrive content, Teams files and the permission structures behind them. The sequencing matters more than the tooling here: identity has to be resolved before content moves, and the cutover has to be planned around how the business actually works.
We support migration from a range of document management and enterprise content management platforms, with each source system assessed case by case to determine the appropriate migration approach, tooling, metadata mapping, permissions and content transformation requirements.
Migration software is good, and we use it. If your situation is simple (one source, clean permissions, content that is already organised) buying a tool and running it yourself may genuinely be the right answer, and we will tell you if we think so.
We are straightforward about this: we use our own internally developed migration platform, and ShareGate where a client already holds the licences. The value we add is the assessment, the design decisions, the exception handling and the engineering afterwards, not the software.
Every phase produces something you can hold us to.
A full inventory of what exists: volumes, file ages, permission complexity, duplicates, and what should not move at all. This is where most of the cost is decided.
Target architecture, permission and metadata mapping rules, wave sequencing, cutover approach and a documented rollback position.
A representative subset migrated and validated end to end, with the findings fed back into the plan before anything else moves.
Waves by business unit or content type, scheduled around how the business works. People keep working throughout.
Reporting that proves what moved, what did not and why: item counts, permission mapping, exceptions, and evidence you can hand to an auditor.
Users on the new platform, source systems retired on an agreed date, and a documented position on what happens if something surfaces later.
Every plan we write includes what happens if a wave goes wrong: what is reverted, how, and how long the source system stays available before it is decommissioned. It is the question every IT director asks, and it should be answered in writing before the project starts rather than improvised during it.
A lift-and-shift migration moves your content and everything wrong with it. Four things worth deciding before the move rather than after.
If access was granted ad hoc over a decade, migrating faithfully reproduces a structure nobody understands and nobody can audit. The assessment is the natural moment to rationalise it: permissions are never easier to fix than when you are already touching everything.
Folder hierarchies fifteen levels deep do not become findable by arriving somewhere new. Content that will actually be used benefits from metadata and content types; content that is being retained for compliance does not need either. Deciding which is which is most of the work.
In most estates a large share of content has not been opened in years. Migrating it costs money once and storing it costs money continuously. An assessment that identifies what can be archived or deleted frequently pays for itself before the migration begins.
Metadata that was never applied cannot be migrated into existence. Where it matters, it has to be derived (from folder structure, file properties or naming conventions), and that is a design decision made before the move, not a setting applied after it.
Content you must keep and almost never open does not belong in your most expensive storage. Regulated and asset-heavy organisations frequently hold years of project records, drawings, inspection reports and correspondence that must be retained but is accessed perhaps once a year.
We archive that content out of SharePoint into Azure Blob storage, at a fraction of the cost per terabyte, with retrieval when it is needed and the retention position preserved.
As an illustration: for 1 TB of inactive content, Microsoft 365 Archive is currently priced at approximately $51 per TB per month (1,024 GB at $0.05 per GB), subject to the tenant’s included storage quota and billing conditions. Azure Blob Archive can be considerably cheaper for long-term cold storage, although retrieval, transaction and early-deletion charges must also be considered.
This is also worth raising with organisations whose migration finished years ago. Storage growth is a problem that arrives quietly.
This is the part most migration projects underestimate, and the reason we treat migration as an engineering engagement rather than a data move.
When content leaves its original system, the things built around it stop working:
A migration specialist will identify these and hand them back to you. We identify them at assessment, price the rebuild alongside the move, and do both, which is usually the difference between a migration that completes and one that is declared finished while three business processes quietly stop working.
For regulated organisations the migration is only half the requirement. The other half is being able to demonstrate it was done properly.
We have delivered migration engagements from Windows file shares and NAS to SharePoint Online, and Microsoft 365 tenant-to-tenant migrations, covering content, metadata, folder structures, permissions and security groups.
Timelines and volumes vary by engagement, and can be shared for a specific client reference once disclosure is approved.
We have worked on the Trivandi SharePoint environment, involving more than 190 sites and over 18 TB of data, with subsequent modernisation, governance improvements, content restructuring, reporting and user-experience enhancements.
See the intranet pageA capital expenditure approval process running on email and spreadsheets, with no audit trail and no way to see where a request was sitting. We built a Power Automate and Power Apps solution with conditional routing by value threshold, automatic escalation, full approval history and a mobile interface for approvers who are rarely at a desk.
See Power Automate & Power AppsWhat IT teams ask us before they commit to a move.
Before anyone quotes a migration, you should know what you actually have: how much content, how old, how tangled the permissions are, what can be archived instead of moved, and what will break when the source system is switched off. That assessment is useful whether or not you go on to work with us. It is also the only honest basis for a fixed price.
Assessment scope, duration and fee are tailored to your environment. Ask us whether the fee can be credited against the migration.
