Dropbox vs ownCloud: which to choose

Dropbox or ownCloud Infinite Scale: which fits your file sync needs

If your Dropbox team plan is up for renewal and the main question is whether your files can sit on infrastructure you control, ownCloud Infinite Scale (oCIS) is worth a serious look. If your team is comfortable with a managed service, wants the least administration, and values Dropbox's mature sync and sharing experience, staying on Dropbox remains a reasonable choice. The decision turns on three questions: who must hold the data, who will run the service day to day, and how your storage and identity systems are already shaped.

Data location is often the deciding factor. With Dropbox, your files live in a provider-managed environment, and your options for choosing where they are stored are set by the vendor's plans. With oCIS, the platform runs in your cloud account, data center or air-gapped network, and it can use S3-compatible object storage, NFS or POSIX storage. Confirm with your compliance and legal teams which storage locations and access paths they require, and check whether your data residency rule covers backups and log files as well as the primary store. Operating responsibility works the other way: someone on your team, or a partner you contract, must patch, back up, monitor and upgrade the service.

Identity and storage shape the effort more than the feature list. oCIS can run with its embedded LibreGraph Connect identity provider for simple deployments, or connect to an existing OpenID Connect provider such as Keycloak, which fits teams that already sign staff in through a central directory. Verify that your clients, including the ownCloud desktop and mobile apps, work with your sign-in flow and network policy before committing. Ask ownCloud and your implementation partner to confirm the current release line, support terms and the Kiteworks ownership arrangement in writing, since these affect long-term planning.

Which option fits which team

This table matches common team situations to the option that usually fits better, with the condition that makes each advantage matter. Read each row against your own constraints, since the right answer depends on who will operate the platform and where the data must live.

Scenario	Better fit	Why
Small team that wants zero operations work	Dropbox team plan	Dropbox runs the service, storage and recovery. Self-hosting only makes sense if someone on staff will own upgrades, backups and sign-in changes.
Regulated team that must keep files in its own cloud account	ownCloud Infinite Scale	Deployed inside your own account or data center, oCIS keeps file content and metadata under your control, which matters when a regulator or contract names the location of the data.
Team already running Keycloak for single sign-on	ownCloud Infinite Scale	oCIS can connect to external OpenID Connect providers such as Keycloak, so existing users, groups and sign-in policies can be reused. Confirm the claim mapping for your realm before rollout.
Team with large folders on NFS or POSIX storage	ownCloud Infinite Scale	oCIS lists NFS and PosixFS backends, so existing file servers can stay in place. Dropbox would require moving data into its service and working around its browser download limits.
Team that needs one-off download of very large folders	Dropbox desktop app for export	Dropbox's browser zip downloads are limited to folders under 250 GB with fewer than 10,000 files. Migrating large trees is simpler through the desktop app in either case.
Team that depends on mature Dropbox-style sync and sharing defaults	Dropbox team plan	Dropbox has long-established desktop and mobile behavior and admin controls. Test oCIS clients against your sync, conflict and link expectations before committing.
Organization that wants to avoid a single vendor's ownership changes	ownCloud Infinite Scale, with a support plan to confirm	oCIS is Apache-2.0 and self-hosted, but ownership changed when ownCloud joined Kiteworks in 2023. Ask any vendor for written commitments on the open-source roadmap and support terms.
Team needing a vendor-backed support contract and SLA	Dropbox team plan or a commercial support agreement	Self-hosting shifts operations to your staff or a partner. Ask for a written scope and response terms before choosing a self-hosted route.

What Kiteworks ownership means for ownCloud's open-source path

Confirm the ownership change before you choose a branch. ownCloud GmbH announced on November 21, 2023 that it was becoming part of Kiteworks, and said its open-source position would stay the same, with a Kiteworks Open Source Program Office operating under the ownCloud brand. That is a public statement, not a contract. Read the ownCloud announcement alongside your own requirements, then ask Kiteworks or ownCloud to confirm in writing which code is released under which license, whether support terms or features differ between editions, and what the published roadmap covers for the next major release. Your procurement file should hold those answers, not a blog post.

The ownCloud product line contains two codebases with different licenses and operating models. Classic ownCloud Server (owncloud/core) is licensed under AGPL-3.0 and, in the 11.0 line, is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. oCIS is a separate platform under Apache-2.0, written in Go, that runs as a single binary with no external database for basic deployments. A Dropbox replacement plan should name one of them explicitly. Check which product each vendor quote covers, because license terms, upgrade paths and support scope attach to the codebase that is actually deployed.

Before committing, request a written statement covering four items: the license for every component you will deploy, including any Kiteworks-supplied extensions or clients; the support terms and who responds to security advisories; the release and stability policy for oCIS, since the current v9.0.0-rc.1 tag is a release candidate that needs its status confirmed; and whether the embedded identity provider or an external Keycloak instance remains a supported option for OpenID Connect sign-in. Also decide whether your own team can track upstream releases and apply updates. If you start on classic ownCloud Server and later need oCIS features, the move is a migration, so write that path into your scope from the beginning.

Choosing between classic ownCloud Server and oCIS

Classic ownCloud Server, published as owncloud/core under AGPL-3.0, is the PHP-based platform that most existing ownCloud deployments know. Version 11 is deployed only with Docker, and the web server, PHP runtime and database are managed inside ownCloud's images. That gives a team a predefined stack to run, but it also means your container platform, image update process and database backups have to fit around ownCloud's packaging. The 11.0.0 release was published on July 30, 2026, and 10.16.6 on October 6, 2026, according to the GitHub releases page.

Deployment model: Docker is the only supported path for Classic 11, so teams without a container workflow need to build one first.
Stack ownership: The web server, PHP and database come inside the images, which limits how much of the runtime you can tune by hand.
Upgrade path: Image-based upgrades follow ownCloud's release notes, so plan maintenance windows and test restores before each move.
Team fit: Suits organizations that already run Docker, want a conventional PHP-style server and need the classic feature set.
Requirements: Confirm the supported Docker, host and database versions on the system requirements page before you commit.

Before choosing this path, check the current system requirements for version 11 and confirm with ownCloud which release line receives security fixes for your timeline.

Where your files, identity and logs would live

Moving from Dropbox to ownCloud Infinite Scale changes who controls where files sit, who signs users in, and what evidence you can show an assessor. The four cards below cover those decisions in the order they usually come up during planning.

Data location and hosting model

With oCIS, files live wherever you run the binary: your cloud account, your data center or an air-gapped network. Dropbox stores team data in its own infrastructure, so this is a change of custodian, not just of software. Confirm which regions and accounts your policy allows, who holds the root and backup credentials, and whether logs and metadata leave that boundary. Ask the vendor or your own architects to confirm where the search index and thumbnails are written.

Single-binary deployment footprint

The oCIS README describes one binary of microservices with no external database needed for basic deployments, and Helm charts exist for Kubernetes. A small footprint is simpler to patch, but it also means your team owns every component that Dropbox runs for you, including TLS, reverse proxying, backups and upgrades. Check whether your platform team can run Kubernetes, and agree on a release cadence before the pilot, because oCIS release candidates and major versions move quickly.

Identity through embedded or external OIDC

oCIS can run its embedded LibreGraph Connect identity provider or trust an external OpenID Connect provider such as Keycloak. The embedded option suits small or isolated deployments, but most enterprises already have an identity source of record that should drive joiner, mover and leaver processes. Decide which option applies, confirm how group claims map to share permissions, and test deprovisioning, since a disabled account in Dropbox does not automatically revoke sync clients running elsewhere.

Storage backend choice

oCIS supports S3, NFS and POSIX filesystem backends. Your choice determines backup method, replication, performance and who can read raw files outside the application. S3 suits object-based storage with its own durability controls, NFS fits existing NAS estates, and a POSIX filesystem fits single-host or small clusters. Confirm the encryption-at-rest approach for each backend, the restore path for versions and trash, and whether file-level audit events are captured in the application or only at the storage layer.

Compliance evidence and ownership

Controls such as access logging, encryption, change management and backup testing must be demonstrated, not just configured. DeployOpen prepares the systems, control designs and evidence for a compliance assessment, but independent auditors issue any report or attestation. Ask who owns the vendor relationship now that ownCloud is part of Kiteworks, which agreement covers support and security notices, and how you will collect evidence from Dropbox's own reports before cutover.

How recovery windows and download limits compare

Dropbox allows a browser download of a folder as a .zip only when the folder is under 250 GB uncompressed and holds fewer than 10,000 files, and it recommends the desktop app for large downloads. Teams planning an exit should treat that limit as a migration constraint, because whole project trees often exceed it. On oCIS the question is different: you need to know which download paths your users will have and whether the web interface imposes its own archive or folder size limits. Confirm that in the oCIS documentation for the exact version you deploy, then test a download of your largest production folder through the browser, the desktop client and the mobile client before you set expectations with users.

Recovery on oCIS depends on the storage, backup and retention design your team builds around it. The platform exposes file versions and deleted-item handling, but you should confirm in the oCIS documentation which version and trash retention settings exist for your release, how they are configured, and whether they apply globally or per space. Dropbox's version history and deleted file recovery periods depend on the plan you buy, so compare against the current Dropbox Help Center terms for your tier rather than assumptions. The storage backend adds a second layer: with an S3 backend, bucket versioning and lifecycle rules can keep prior object versions, while with NFS or POSIX storage, file system snapshots and backup tooling perform that role.

Before cutover, write down the recovery commitments your organization needs and test them. Restore a deleted file, an earlier version and a complete folder from backup, and record how long each restore takes and who is authorized to run it. Back up oCIS data and its metadata together so that restored files and the platform's index stay consistent. Retention periods for trash, versions and backups should come from legal, compliance and records owners, not from the default settings, and should be reviewed whenever the storage backend or backup product changes.

What drives the cost of each option

This table sets the recurring Dropbox team subscription against the one-time and ongoing costs of running ownCloud Infinite Scale yourself. Read the one-time and recurring columns first, then the drivers, because the break-even point depends on seat count, data volume and how much internal staff time you can commit. No prices are quoted here, so use the request list to get comparable figures.

Cost component	One-time or recurring	What drives it up or down
Dropbox team plan seats and included storage	Recurring, billed per user under the plan you choose	Seat count, plan tier, storage needed beyond what is included, and whether admin, security or retention features require a higher tier. Ask Dropbox for the current per-seat price and storage terms in writing.
Dropbox add-ons and overage	Recurring, only if your plan needs them	Extra storage, advanced admin or compliance features, and contract term. Ask whether any renewal uplift applies.
oCIS servers or Kubernetes capacity	Recurring infrastructure, plus one-time setup	Number of concurrent users, sync frequency, and whether you run one node or a Helm-based cluster. A single binary keeps the footprint small, but high availability adds nodes.
Object or disk storage (S3, NFS or POSIX)	Recurring, scales with data	Total stored volume, version retention, and replication. Object storage is often priced per GB-month and adds egress fees on download, so ask your provider for both.
Backups and recovery testing	Recurring storage plus periodic restore testing	Backup frequency, retention period and offsite copies. Restore testing time is easy to skip and is what proves recovery works.
Monitoring and logging	Recurring tooling, plus setup	Whether you reuse existing monitoring stacks or add new ones, and how long logs are kept for audits.
Upgrades and patching	Recurring staff effort per release	Release cadence, the number of environments (test and production), and how much of the upgrade path is automated. Confirm the current release line before planning.
Vendor support or partner retainer	Optional, recurring when chosen	Support tier, response expectations, and whether upgrades and testing are covered. Ask ownCloud for the subscription terms and ask any partner for a fixed-scope quote.
Staff time to operate and migrate	One-time for migration, recurring for operations	Team skills in Linux, containers and identity integration, plus client rollout and user support. This is often the largest and least visible cost, so estimate it from your own environment.

What moving from Dropbox to ownCloud involves

The sequence turns Dropbox folders into oCIS spaces with the right storage, sign-in and sharing, and ends with Dropbox retired only after the team has checked its files. Effort sits mostly in scoping, access design and verification, not in the platform install.

Scope teams, folders and sharing
Start by listing every Dropbox team, shared folder and external share link, with its owner, approximate size and file count. Mark which folders hold regulated data and which need version history carried forward. Your team supplies the account inventory and the business owner who signs off each group. DeployOpen can help structure the inventory and the migration waves in writing before any data moves. Done means each folder has an owner, a destination and a wave assignment that the business has approved.
Stand up oCIS in a test environment
Deploy oCIS in a non-production environment with the storage backend you have chosen, whether S3, NFS or POSIX, and the identity model: either the embedded LibreGraph Connect provider or an external OpenID Connect provider such as Keycloak. Your infrastructure team supplies the hosts or cluster, storage capacity and the directory or identity source. Confirm the deployment method, such as the Helm charts for Kubernetes or the single binary, against the current oCIS documentation. Done means test users can sign in, upload and sync through the web, desktop and mobile clients.
Export large folders through the desktop app
Do not rely on browser downloads for large data. Dropbox's own help center limits folder downloads from dropbox.com to folders under 250 GB uncompressed with fewer than 10,000 files, and recommends the desktop app for larger transfers. Sync the relevant Dropbox folders to a staging workstation or server, then copy them into a staging area on the ownCloud side. Record the source path, file count and checksum or size totals for each folder. Done means each folder's staged copy matches the source counts and sizes in your inventory.
Import into spaces and recreate access rules
Load the staged files into oCIS spaces, one per team or project, and map each Dropbox shared folder to a space with the same group membership. Recreate permissions by role instead of copying links one by one, and rebuild any external share links only for recipients who still need them. Dropbox sharing links and version history do not carry over automatically, so note which ones you need to re-create or accept as lost. Your security team should review the rebuilt permissions. Done means every space has named owners and its members match the approved access list.
Roll out clients by team
Move one team at a time. Give each team the ownCloud desktop, Android or iOS client, a short guide to the new locations, and a support contact for the first week. Ask team leads to stop writing to the Dropbox folder on their cut-over date, then sync the final changes from Dropbox. Confirm that collaborative editing works through your chosen office integration, such as Collabora Online, ONLYOFFICE or Microsoft Office Online Server via WOPI. Done means each team has signed off that it can open, edit and share files from the new spaces.
Verify data and integrity before cut-over
Before any Dropbox folder is marked read-only, compare file counts, sizes and sampled checksums between the source and the oCIS spaces. Check permissions, file names with special characters and large files, and confirm that backup of the new storage is running. Ask the business owner to sample critical files. Record exceptions in a register with decisions. Done means every exception is closed and the owner has signed a verification record for each team.
Retire Dropbox after verification
Once each team's verification record is complete, switch the Dropbox folders to read-only or archive them according to your retention policy, and remove team members from Dropbox. Keep the export and verification evidence for the period your records policy requires. Confirm with your legal and compliance leads what must be retained before deleting anything in Dropbox. Done means the Dropbox team is closed or reduced to archive access, and the evidence file is stored where your auditors can find it.

Questions buyers ask before switching from Dropbox

What does it cost to run oCIS, and who pays for each part?

oCIS itself is free to download under Apache-2.0, so the recurring costs sit in the infrastructure and people around it. Expect to pay for compute to run the oCIS services, object or file storage sized to your data volume, backups kept outside the primary storage, TLS and identity components, and staff time for patching and monitoring. Dropbox per-seat fees are replaced by these line items, and the balance depends on team size, how much data you hold and how many users you have. Ask any implementation partner for a quote that separates one-time work (design, migration, hardening) from recurring work (hosting, backups, upgrades, support), and check whether your own team or an outside provider will carry each line.

How long does a migration from Dropbox to oCIS take?

The timeline is set by how much data you move, how the transfer runs and how many teams cut over. Dropbox only allows browser downloads of folders under 250 GB uncompressed with fewer than 10,000 files, so larger folders need the desktop app, which makes bulk transfer the slow step. Other drivers include how many shared folders and links need to be recreated, how many users need client rollout, whether you run a pilot team first, and how much permission mapping your current sharing model requires. A fixed-scope engagement lets you agree the phases, deliverables and dates in writing before work starts, so ask for the schedule to be tied to your data inventory.

Can our team operate oCIS without outside help?

It depends on your existing skills in Linux, Kubernetes or Docker, identity federation and storage administration. oCIS ships as a single binary of microservices with no external database needed for basic deployments, which lowers the number of components to run, but production use still requires monitoring, backups, certificate handling, upgrade planning and an identity provider decision. Check whether your team has on-call coverage for file services and can read release notes on the oCIS GitHub releases page before each upgrade. Many teams keep daily operations in-house and buy retainers for upgrades, testing and incident support.

What does the work need from our internal staff?

Internal staff provide decisions and access, which is often the bottleneck. You will need an owner for the file platform, someone who can approve storage location and retention rules, an identity lead who connects the oCIS sign-in to your directory or to Keycloak, and team leads who confirm which folders, members and external sharing rules must carry over. Security and compliance staff should review encryption, access logging and backup policy. Plan for users to switch from Dropbox desktop and mobile clients, and for a short period where both systems run side by side. Ask the implementation partner for a written list of the roles and hours they expect from your side before the scope is signed.

Does oCIS replace Dropbox sharing links and version history?

oCIS supports file sharing and syncing through ownCloud's web, Android, iOS and desktop clients over WebDAV and CS3 APIs, so you can recreate shared spaces and user or group permissions. Public links and version history do not move automatically with Dropbox data, so existing links will need to be reissued and history will not be carried over unless a migration step preserves it. Before committing, confirm with the vendor or your partner how versioning, link expiry, password protection and retention behave in the oCIS release you plan to deploy, and test those behaviors with a pilot group.

How does the Kiteworks ownership affect the open-source path?

ownCloud GmbH announced on November 21, 2023 that it was becoming part of Kiteworks, and it said ownCloud's open-source position would remain the same, with a Kiteworks Open Source Program Office operating under the ownCloud brand. oCIS is licensed under Apache-2.0, so the code you deploy remains open and can be forked, pinned or audited. The practical questions are roadmap and commercial support: confirm which features are in the community release, which sit behind a commercial offer, and how security advisories are delivered. Keeping your deployment in your own infrastructure means you can continue on a pinned version if your support arrangements change.

How to scope an ownCloud evaluation before committing

A written, fixed scope is the document that turns an ownCloud Infinite Scale evaluation into a decision you can defend. Before any installation, fix five things in writing: the deployment target (a single host, a Kubernetes cluster using the Helm charts, or an air-gapped network), the identity integration (the embedded LibreGraph Connect provider or an external OpenID Connect provider such as Keycloak), the storage backend (S3, NFS or PosixFS), the migration waves, and the acceptance tests that will decide each wave. Because oCIS runs as a single binary with no external database for basic deployments, it is tempting to skip this step. The choice of identity provider and storage backend is harder to reverse than the binary, so those two decisions belong in the scope from day one.

Acceptance tests should be written against your own teams, not against a feature list. Examples include: a sync client on each operating system in use reconnects after a sleep cycle, a folder of your largest real project syncs completely, a sharing link honors the expiry and password rules your policy requires, a user removed in the identity provider loses access, and a document opened through the WOPI-connected editor saves back without conflicts. Record who signs each test off. Ask DeployOpen or any other implementation partner to state in the written scope which tests are theirs to run, which you run, and what evidence each produces. Confirm with the ownCloud project and your own administrators which client versions and editor integrations are supported for your target release, since these change between releases.

Run a pilot group before cutover. Choose one team with mixed devices and realistic sharing patterns, keep Dropbox in place for them during the pilot, and set a fixed exit date for the pilot in the scope. Measure restore behavior, backup and restore of the storage and identity configuration, and how support requests are handled. The pilot also tests your version-recovery expectations: confirm in writing how far back the chosen storage and backup design can restore files and deleted items, because this is a commitment you will be making to users, not a default. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your infrastructure, so the pilot results and the runbooks should be deliverables in the statement of work before any wave begins.

How DeployOpen helps you evaluate, implement or migrate

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Dropbox vs ownCloud, that means starting from your actual sharing, storage and sign-in requirements before anyone installs a server.

How we scope

Review your current Dropbox team folders, sharing patterns and largest folders to size the migration work
Confirm storage backend choice among S3, NFS or POSIX storage based on where your data must reside
Agree the identity approach, either the embedded provider or an existing OpenID Connect provider such as Keycloak
Put scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope

How we build

Deploy the oCIS single binary or Kubernetes Helm chart into your environment with your chosen storage backend
Configure desktop and mobile clients, and connect collaborative editing through Collabora Online if you need it
Test sharing permissions, versioning, quota behavior and large-file transfers against your documented requirements
Run security testing of the deployed applications and APIs where your scope includes it

How we hand over

Document the architecture, configuration, backup and restore procedures in a form your own team can operate
Prepare a per-team cutover plan covering shared links, permissions and client rollout sequencing
Provide evidence and control documentation for your internal reviews, noting that auditors and certification bodies issue any attestation
Walk your administrators through daily operations, upgrades and incident steps before handover

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover platform version upgrades, including tracking oCIS release changes you need to act on
Ask for a quote that follows from your written scope, since DeployOpen does not publish a price list
Confirm with ownCloud and Kiteworks any support terms for the open-source platform in your own environment

Dropbox vs ownCloud

Dropbox or ownCloud Infinite Scale: which fits your file sync needs

Which option fits which team

What Kiteworks ownership means for ownCloud's open-source path

Choosing between classic ownCloud Server and oCIS

Where your files, identity and logs would live

Data location and hosting model

Single-binary deployment footprint

Identity through embedded or external OIDC

Storage backend choice

Compliance evidence and ownership

How recovery windows and download limits compare

What drives the cost of each option

What moving from Dropbox to ownCloud involves

Scope teams, folders and sharing

Stand up oCIS in a test environment

Export large folders through the desktop app

Import into spaces and recreate access rules

Roll out clients by team

Verify data and integrity before cut-over

Retire Dropbox after verification