When a SharePoint migration comes up
Three situations account for most of our SharePoint projects. First, a merger, acquisition or consolidation: two Microsoft 365 tenants become one, and along with the mailboxes the SharePoint sites, document libraries and the files of the Teams channels have to move into the target tenant. Second, a switch from Google Workspace to Microsoft 365: My Drive becomes OneDrive, shared drives become SharePoint libraries. Third, retiring a file store that no longer fits: Dropbox, a self-hosted Nextcloud or ownCloud, an S3 or WebDAV storage whose contents are to live in SharePoint Online and Teams from now on.
What all three have in common: the files themselves are not the problem, but everything attached to them. Folder-level permissions, metadata in library columns, version histories, sharing links to external people, file names SharePoint rejects. A manual copy or a sync client loses exactly these things, and with more than a handful of sites nobody knows afterwards whether everything really arrived. We are based in Memmingen, Germany, and handle SharePoint migrations for companies across Germany, Austria and Switzerland, many of them in the Munich area and across Bavaria; the work itself runs via our servers, not on site. How a project runs step by step is described on the process page.
Tenant to tenant: sites, libraries, lists and Teams files
In a SharePoint Online migration from one Microsoft 365 tenant to another, our software transfers entire sites: document libraries with the full folder structure, lists with their items, the metadata in the columns and the version history of the documents. File- and folder-level permissions are mapped to the corresponding users and groups in the target tenant, sharing links as far as the target knows the respective concept. Teams files are technically SharePoint libraries of the respective team site; they land in the library of the target team, channel folders included. On request the software discovers every site in the source tenant automatically and migrates them in one run, instead of each site having to be created and started individually.
We have to be honest about what does not move automatically tenant to tenant and has to be recreated in the target:
- Site- and library-level permissions: they are set again in the target; the final report lists every site and library concerned so nothing is forgotten.
- Teams chats and channel conversations: they are not SharePoint data and are not transferred.
- Power Automate flows, workflows and site designs: automations, branding and page layouts are set up again in the target tenant.
These points are in the discovery report before you commit. Mailboxes, calendars, contacts and OneDrive drives of the same organisation are migrated in the same project; the coordination with the domain transfer and identities is described on the page tenant-to-tenant migration, the order of the steps in the guide Microsoft 365 tenant-to-tenant migration.
Google Drive, Dropbox, Nextcloud and S3 to SharePoint
From Google Drive we transfer personal drives to OneDrive and shared drives into SharePoint document libraries, with folder structure, shares and sharing links as far as SharePoint can represent them. Google-native files, i.e. Docs, Sheets and Slides, are stored automatically as Office files (.docx, .xlsx, .pptx); the version history is carried over. Which shared drive becomes which site or library is defined together in the mapping. The details of this route are in the guide Google Drive to SharePoint and OneDrive (German).
From Dropbox, Nextcloud, ownCloud and S3 or WebDAV storage, files are transferred with the complete folder structure into the designated SharePoint libraries; file- and folder-level shares are mapped to the permissions of the target as far as the target system knows the concept. Invalid characters in file names and paths that are too long for SharePoint Online are renamed automatically by the software; every rename is traceable in the report. Guides for the most common sources: Dropbox to OneDrive and Nextcloud to Microsoft 365 (both German). If the target is not SharePoint but Google Drive or OneDrive only, the page cloud storage migration is the right one.
Preparation and automation: discovery, mapping, target sites
In the free initial analysis our software records the inventory automatically: every site, every document library and list with file count, volume, folder depth, versions and permissions; for Google Drive, Dropbox or Nextcloud every drive accordingly. From that come the discovery report and the mapping: which source site to which target site, which shared drive into which library, which source user to which target account. A short clean-up beforehand pays off: orphaned sites, shares of former employees, recycle bins. What is not meant to move is neither migrated nor charged.
In the target tenant we need licensed users, created teams or sites, and an app registration through which our software reads from the source and writes to the target. We create the sites and teams on request. Nothing is installed on end-user devices. The migration itself is SharePoint automation in the best sense: several libraries run in parallel, the software respects Microsoft throttling automatically so that neither the source nor the target tenant is slowed down, and a test migration on two or three real sites shows you the result before you commission the project.
Switching over: pre-migration, cut-over date, delta sync
The bulk of the data is transferred in the background while your team keeps working in the old environment; the source is only read. On the agreed cut-over date, usually a weekend, you set the source sites or the old storage to read-only, or tell the team that work now happens in the target. The delta sync transfers every file that was added or changed since the pre-migration, including new versions. Unlike email there is no MX record that enforces the switch technically; a clearly communicated date and repointing the OneDrive sync clients to the new libraries are therefore all the more important. In a tenant migration we bundle the cut-over with the domain transfer and the mailbox cut-over so your users only have to adjust once.
Data protection, proof and price
SharePoint libraries hold contracts, HR files, engineering data. Our own software transfers them directly from the source via our servers in Germany and the EU into your target tenant, without intermediate storage at a third party and without any third-party migration service. Credentials and app registrations are kept encrypted in our key vault and revoked after the project. On request we sign a data processing agreement under Art. 28 GDPR; what you have to consider as controller is summarised in general terms in the guide GDPR-compliant cloud migration (German); this is not legal advice.
After the migration the software checks every object against the source: files by count, size and path, list items, versions, permissions. Deviations are re-migrated or documented with the reason; renames and site permissions to be set again are listed in the final report. Pricing: a €200 project fee and €19 per user for personal files in OneDrive up to 50 GB; 25 users therefore cost €675 net. SharePoint sites, lists and Teams files are quoted as an effort-based item after the discovery analysis, because the number of sites, the volume and the permission structure vary too much for a flat rate. You receive a fixed-price quote beforehand that covers both. In the price calculator Microsoft 365 is preselected as the source; add SharePoint sites and Teams files there as an additional item in your enquiry.
