Open-source alternative to OneDrive for Business

How OneDrive capabilities map to Nextcloud, Seafile and oCIS

This table maps the OneDrive for Business capabilities that matter most in a file migration to Nextcloud, Seafile and ownCloud Infinite Scale. Read each row as a starting point: the notes flag where a platform covers the need natively, where it depends on an edition or add-on, and where it leaves a gap you must close. Confirm each admin control against the vendor's current documentation for the release you plan to deploy before you commit to a design.

When Nextcloud, Seafile or ownCloud Infinite Scale fits

Each of these platforms can replace OneDrive for Business file sync and sharing on infrastructure you control, but they differ in feature breadth, licensing, storage design and operating model. The cards below set out where each one fits and what to verify before you commit to a pilot.

Which platform fits your user count and storage backend

Running sync alongside Exchange, Teams and Office in Microsoft 365

How to move OneDrive files without losing version history

This sequence moves OneDrive and SharePoint files into a self-hosted platform with their version history, sharing links and permissions checked at each stage. Each step ends with a verifiable output, so the cutover can happen group by group with a fallback in place.

1. Inventory libraries, owners and sharing

   The IT or platform team lists every OneDrive account, SharePoint document library and team site in scope, along with its owner, approximate size, file types and external sharing links. Compare the inventory with the Microsoft 365 admin center and the sharing reports available to your administrators. The step is done when each library has a named owner and a status of migrate, archive or delete, approved by the business owner.

2. Confirm licensing for the export path

   Check that the administrator who runs the export holds a Microsoft 365 E3 or E5 license, because Purview eDiscovery export requires one. Confirm this with your Microsoft account team or licensing documentation, since a standard business plan may not cover it. The step is done when a licensed eDiscovery administrator is named and can log in and run a test search, so the export does not stall at the start.

3. Export content through Purview eDiscovery

   Create a Purview eDiscovery case, run a search scoped to the OneDrive and SharePoint sites from the inventory, and export the results as native documents with the version history option selected. Search export packages expire 14 days after creation, so download each package and store it in a staging location with checksums promptly. The step is done when every package is downloaded, verified against the item counts in the search results, and recorded in the migration log.

4. Run a pilot with a small user group

   Import the exported files into a test instance of Nextcloud, seafile or oCIS, depending on the sizing decision, and select a small group of users whose files are representative of the wider estate. Ask the pilot users to open, edit and share several documents with known version histories. The step is done when the pilot group signs off on file names, folder structure and version access, and every defect found is logged with an owner.

5. Confirm version fidelity in a test

   Compare a sample of documents with multiple versions between the export and the target platform. Check that each version's content, modified date and author match what the source shows, and document any version that the target cannot represent. Vendor documentation on version handling should be confirmed in your own environment, not assumed. The step is done when the team has a written fidelity report that states which versions carry over, which do not, and how the business accepts the difference.

6. Map permissions and sharing links

   Translate SharePoint and OneDrive permissions into groups and roles in the target platform, using the directory integration you have configured, such as LDAP, Active Directory or an OpenID Connect provider. Rebuild internal shares and external links, and list any link that cannot be recreated so that owners can resend it. The step is done when a permission report for each library shows the source and target access side by side and an approver has signed it off.

7. Cut over by user group and keep a read-only fallback

   Migrate the remaining users in groups, scheduling each cutover with the business owner and announcing a freeze on edits in the source for that group. Keep the source libraries in read-only mode during a defined fallback window agreed in advance, so users can recover content if a defect appears. The step is done when each group confirms access in the new platform and the fallback window closes with no open migration defects.

8. Retire the source after validation

   Once the fallback window closes and the business confirms no outstanding issues, archive the export packages and migration logs according to your retention policy, then remove or lock the source content. Before any deletion, check the retention and legal hold settings in the source tenant with your compliance team. The step is done when the retention record is complete, the source is locked or deleted under an approved change, and the migration report is filed with compliance.

Questions buyers ask before replacing OneDrive for Business

What the self-hosted file platform actually costs to run

Hardening the platform before users move in

This sequence turns a freshly installed file platform into one that is encrypted in transit, gated by your identity provider, scanned for malware, recoverable from tested backups, and observable through audit logs and access reviews. Each step ends with a check you can record as evidence before any user data arrives.

1. Terminate TLS with a verified certificate

   Your platform or infrastructure team places the file service behind a reverse proxy or ingress that serves a certificate from your internal or public CA, and disables plain HTTP for user traffic. Confirm the exact TLS settings, supported protocol versions and certificate handling in the current administration documentation for your chosen platform, since these change between releases. Done means an external scan of the hostname shows only encrypted endpoints, the certificate chain validates on every supported client, and WebDAV and sync clients connect without certificate warnings.

2. Enforce MFA through the chosen identity provider

   Your identity team connects the platform to the directory or identity provider that already holds your staff accounts, using the LDAP, OpenID Connect or SAML integration the platform documents, and requires a second factor at that provider rather than inside the file application. Confirm which authentication backends your platform version supports and how it handles existing local accounts and app passwords for sync clients. Done means a test user cannot sign in with a password alone, and local administrator accounts are either removed or protected by their own second factor.

3. Integrate antivirus scanning on uploads

   Your platform team enables a malware scanner on upload and on sync so infected files are quarantined before other users can open them. Nextcloud All-in-One bundles ClamAV, and the Seafile admin manual documents ClamAV virus scanning as a Professional Edition feature, so confirm the current setup steps, scan-on-upload behavior and quarantine handling for your release. Done means a harmless EICAR-style test file is flagged and blocked in a test library, and the scanner's update schedule is written into your operations runbook.

4. Restore a test backup to a separate environment

   Your operations team configures backups of the database, file storage and configuration, then restores them to an isolated environment and starts the platform there. Confirm which backup tool your platform bundles or supports and whether the file store and database must be captured at the same point in time. Done means a restored instance serves a sample of files with correct permissions and version history, and the restore steps, duration measured in your environment and owner are recorded.

5. Configure admin audit logging and forward it

   Your security team turns on the platform's audit or activity logging for logins, sharing changes, permission changes, deletions and admin actions, then forwards those logs to your central log store outside the file server. Confirm which events each platform records, the retention it supports and whether logs can be exported in a format your SIEM ingests. Done means a test share, a permission change and a failed login each appear in the central log store with the user and timestamp.

6. Run the first access review before onboarding

   Your IT and data owners review the initial group memberships, library or folder shares, public links and external guest accounts, removing anything that does not match the approved access model. Keep the review as a signed record so the same method can repeat after each joiner, mover and leaver cycle. Done means the approved access list is saved, every public link has an owner and expiry decision, and the reviewer and date are on file.

7. Sign off the baseline with a documented check

   Your security lead compares the completed settings against the vendor's current hardening guidance and your internal control list, and records any gaps with an owner and a target date. Ask your implementation partner or internal team to keep the configuration, scan results, restore test and access review in one evidence folder. Done means each control has a recorded result, open gaps are accepted or fixed, and the sign-off is approved before the pilot group receives its first accounts. Audit firms, not the platform vendor or DeployOpen, decide whether that evidence satisfies any specific framework.