If your organization runs ownCloud, you have probably spent the last year watching the situation deteriorate and wondering what comes next. Kiteworks acquired ownCloud in late 2023 and closed the deal in March 2025. The core Infinite Scale engineering team left in January 2025 to build OpenCloud. The PHP 7.4 runtime your ownCloud Server 10.x instance depends on has been end-of-life since November 2022. And the “five-year open-source commitment” from Kiteworks expires in 2028 — assuming it lasts that long.
The question is no longer whether to migrate. It is where to migrate to, and how to do it without disrupting your users.
This guide covers the technical and strategic considerations for migrating from ownCloud to OpenCloud — what transfers cleanly, what requires manual work, what breaks entirely, and why the operational model you choose for your next platform matters as much as the platform itself.
Why the Clock Is Ticking on ownCloud
The urgency is not hypothetical. Four things converged in 2024-2025 that make staying on ownCloud an active risk:
1. The Kiteworks Acquisition
Kiteworks is a US-based proprietary vendor focused on “private content networks.” They acquired ownCloud along with DRACOON and Maytech, and have been steering ownCloud customers toward the Kiteworks platform on a like-for-like contract basis. The open-source project is on a five-year pledge that expires around 2028. Community contributors have expressed deep skepticism about what happens after that date — and reasonable skepticism about what happens before it, given that the engineers who actually built ownCloud Infinite Scale have already left.
2. The PHP End-of-Life Problem
ownCloud Server 10.x was built on PHP 7.4, which reached community end-of-life in November 2022. PHP 8.0 followed in November 2023, and PHP 8.1 reached end-of-life on December 31, 2025. Late 10.x releases (10.14+) added partial PHP 8.x support, but the upgrade path is fragile, poorly documented, and unsupported by the original engineering team.
Running a file sharing platform for regulated data on an unsupported runtime is a compliance finding waiting to happen.
3. Critical Security Vulnerabilities
In November 2023, three critical CVEs were disclosed simultaneously: a CVSS 10.0 information disclosure that leaked admin passwords and credentials (CVE-2023-49103), a CVSS 9.8 authentication bypass allowing unauthenticated file access (CVE-2023-49105), and a CVSS 8.7 OAuth redirect bypass (CVE-2023-49104). CISA added the first to its Known Exploited Vulnerabilities catalog within days.
While patches were released, the severity and clustering of these vulnerabilities raised fundamental questions about the codebase’s security posture — questions that become harder to answer as the original development team disperses.
4. The Developer Exodus
In January 2025, approximately 15 developers from the ownCloud Infinite Scale (OCIS) team departed and joined OpenCloud GmbH, founded by the Heinlein Group in Berlin. These were the engineers who designed and built the Go-based rewrite of ownCloud. Their departure means the people with the deepest understanding of the OCIS codebase are now working on OpenCloud, not ownCloud.
What Is OpenCloud
OpenCloud is a direct fork of ownCloud Infinite Scale (OCIS), built by the same engineers who created OCIS. It is maintained by the Heinlein Group — a Berlin-based company with 30 years of open-source infrastructure experience that also operates mailbox.org and OpenTalk.
The key differences from ownCloud Server 10.x:
| ownCloud Server 10.x | OpenCloud 5.x | |
|---|---|---|
| Language | PHP 7.4 (EOL Nov 2022) | Compiled Go binary |
| Database | MySQL / PostgreSQL / Oracle required | No database — metadata on filesystem |
| Architecture | Monolithic PHP application | Microservices with TLS between services |
| Storage | Local filesystem or S3 | DecomposedS3 — native S3 with any compatible provider |
| RAM | 1-2 GB minimum (PHP + database + Redis) | ~100 MB for the OpenCloud process |
| Backup | Database dump + filesystem sync (must be coordinated) | Filesystem snapshot only — no database to coordinate |
| License | AGPLv3 open-core + proprietary EULA on OCIS | AGPLv3 + Apache 2.0, no proprietary restrictions |
| Ownership | Kiteworks (US, proprietary) | Heinlein Group (Germany, open source) |
OpenCloud is currently on version 5.1.0 (rolling release) with production release 4.0.3 available for organizations that prefer slower release cycles.
What About Nextcloud?
Nextcloud is the other major fork in the ownCloud family tree, created by ownCloud founder Frank Karlitschek in 2016. It has a larger community (34,000+ GitHub stars vs. 4,800 for OpenCloud), a broader feature set (calendar, contacts, chat, project boards), and a well-established enterprise track record with customers like Siemens and Deutsche Telekom.
The trade-offs are real:
- Nextcloud is PHP + MySQL/PostgreSQL. You are migrating from one PHP stack to another PHP stack. The operational burden does not change — you still manage a database, PHP-FPM pools, OPcache, Redis, and the coordination between them.
- OpenCloud is a compiled Go binary with no database. Backups are a filesystem snapshot. Upgrades are a container image swap. The operational surface area is dramatically smaller.
- Nextcloud has more features. If your organization needs calendaring (CalDAV), contacts (CardDAV), video conferencing, or an app ecosystem with hundreds of extensions, Nextcloud is the better fit.
- OpenCloud is faster and lighter. Delta sync, file bundling, and a ~100 MB memory footprint. Multiple independent reviews report more reliable sync behavior, especially with large file counts and interrupted connections.
The right choice depends on what your organization actually needs. If the primary use case is file sync and share with real-time document collaboration, OpenCloud delivers that with significantly less operational overhead. If you need a full collaboration suite, Nextcloud is the more complete platform.
The Migration: What Moves and What Does Not
This is where most migration guides get vague. Here is the honest technical breakdown.
What Migrates Cleanly
- Files and folder structure — File data transfers reliably via rclone over WebDAV. Folder hierarchy is preserved.
- File timestamps — Preserved by rclone during transfer.
- File checksums — Verified automatically during transfer to ensure data integrity.
What Requires Manual Reconstruction
| Item | Migration Status | What Has to Happen |
|---|---|---|
| Internal shares | Not automated | Must be manually recreated on OpenCloud. Share acceptance states reset. |
| Federated shares | Not migrated | Remote shares from both directions require manual acceptance. Federation must be pre-configured. |
| Link shares | Partial | Password-protected links do not import correctly — passwords must be reset. If the target enforces passwords but the source did not, the import process will fail. |
| Users | Not automated | Must be pre-provisioned on OpenCloud manually or via LDAP/OIDC integration. |
| Groups | Not automated | Must be pre-provisioned. Group-based shares are silently ignored if the target group does not exist. |
| User passwords | Not portable | Cannot be migrated from ownCloud database auth. Users must reset passwords, or use external auth (LDAP/OIDC). |
| External storage mounts | Not portable | Must be reconfigured from scratch on OpenCloud. |
| ownCloud apps/plugins | Not compatible | ownCloud apps do not work in OpenCloud. Evaluate functionality case by case. |
Known Gotchas
- Users must stop working during the sync window. The rclone-based migration is not real-time. Files modified during transfer may not sync correctly.
- The migration is user-by-user. There is no bulk migration of an entire ownCloud instance in a single operation. Each user’s data is synced individually via WebDAV.
- Username aliasing does not work. If you attempt to import data using a different username than the source, share metadata will break.
- Large files may hit upload limits. The rclone WebDAV driver does not use chunked uploads. If your reverse proxy has upload size limits, large files will fail silently.
- Version timestamps are not preserved on S3 backends. If your target uses S3 storage, file version history timestamps will be lost.
Migration Options
There are three paths available today, each with different trade-offs in complexity, cost, and risk.
1. Self-Service via rclone
OpenCloud provides official documentation for migrating data using rclone over WebDAV. You configure rclone with WebDAV remotes for both the source ownCloud instance and the target OpenCloud instance, then sync data user by user. Users, groups, and shares must be reconstructed manually.
Best for: Small deployments (under 20 users) with minimal share complexity and a dedicated sysadmin willing to spend a weekend on it.
2. Managed Migration via audriga
OpenCloud partnered with audriga (Karlsruhe, Germany) in July 2025 to provide managed migration services. audriga handles data transfer, structure analysis, and workflow adaptation. They support migrations from ownCloud, Nextcloud, SharePoint, Dropbox, and Google Drive.
Best for: Large deployments or complex share structures where the rclone approach becomes impractical.
3. Fully Managed by Open Edge
With Open Edge Managed OpenCloud, we handle the entire migration: deploying the target OpenCloud instance on US sovereign infrastructure, configuring the S3 storage backend, migrating your data, setting up SSO integration with your identity provider, reconstructing shares and group structures, and managing the platform going forward.
Your users get a new URL and a faster sync client. Your IT team gets one less platform to manage.
Best for: Organizations that want to migrate off ownCloud and stop managing file sharing infrastructure entirely. Especially relevant for regulated industries where US data residency, audit logging, and encryption at rest are requirements — not preferences.
Self-Hosted vs. Managed: The Hidden Operational Cost
OpenCloud is genuinely simpler to operate than ownCloud 10.x. No database, no PHP runtime, no Redis layer, filesystem-only backups. But “simpler” is not “zero effort.” Self-hosting OpenCloud still means your team is responsible for:
- Deploying and configuring the Docker Compose stack (or Kubernetes Helm charts for HA)
- Managing TLS certificates and reverse proxy configuration
- Configuring and maintaining the S3 or local storage backend
- Planning and executing upgrades (rolling releases every 3 weeks, production releases every ~6 months)
- Monitoring health and responding to issues
- Integrating SSO/LDAP and maintaining the identity configuration
- Testing and applying security patches
- Managing backup retention and verifying restore procedures
For organizations with a dedicated platform engineering team, this is manageable. For organizations where file sharing is one of dozens of internal tools managed by a small IT team, the operational burden adds up — even when the underlying platform is lightweight.
With a managed service, you eliminate the operational overhead entirely. You consume the platform. Someone else runs it.
What Open Edge Managed OpenCloud Includes
Every managed OpenCloud deployment includes:
- OpenCloud 5.x on US sovereign infrastructure (Iron Mountain VA-1, Manassas, Virginia)
- Collabora Online for real-time document collaboration in the browser
- S3 storage — use ours (no egress fees, US-only) or bring your own
- SSO integration — OpenID Connect, SAML 2.0, LDAP, or Active Directory
- Automated backups with managed retention
- 24/7 monitoring with Prometheus-based alerting
- Zero-downtime upgrades — we manage the release cycle
- Security patches applied proactively
- Audit logging for all security-relevant actions
- Encryption at rest with FIPS 140-3 validated cryptographic modules (CMVP Certificate #5115)
- Contract-based pricing — no per-user SaaS fees, no per-GB storage surprises
Planning Your Migration
If you are ready to start planning, here is a practical checklist:
- Inventory your current ownCloud deployment. How many users? How much data? What apps or plugins are in use? What external storage mounts exist? What SSO or LDAP integrations are configured?
- Map your share structures. Internal shares, group shares, federated shares, and public links all require different handling. Document what exists so nothing is missed during reconstruction.
- Decide on your identity strategy. If you are using ownCloud’s built-in user database, migration is an opportunity to consolidate on an external identity provider (LDAP, Active Directory, or OIDC via Keycloak or Okta). External auth eliminates the password migration problem entirely.
- Choose your storage backend. OpenCloud’s DecomposedS3 driver supports any S3-compatible storage. Evaluate whether you want to use your existing S3 provider, bring a new one, or use managed storage from your hosting provider.
- Plan your cutover window. The migration requires a quiet period where users are not modifying files. For small teams, this can be a weekend. For large organizations, consider a phased rollout by department.
- Communicate with your users. The sync client changes. The web interface changes. The URL probably changes. Give your users advance notice and desktop/mobile client download links before the cutover.
Talk to Us About Your Migration
If your organization is running ownCloud and evaluating what comes next, we can help you plan the migration — whether that means a fully managed OpenCloud deployment on our infrastructure, or just a technical consultation to help you understand your options.
Tell us about your current deployment, user count, storage needs, and compliance requirements. We will walk through the migration path that makes sense for your situation.