When Box or ownCloud Infinite Scale is the better fit
Box is the better fit when you want a managed service and can accept its data location model. Choose Box if your priority is to avoid operating file storage yourself, if your teams depend on existing Box integrations and admin tooling, or if Box Zones satisfies your residency requirement for encrypted content at rest. The Box model suits organizations that value vendor-run patching, uptime and support over control of the storage layer. Before deciding, confirm with Box which region options and support access terms apply to your tenant, because those details, not the marketing summary, will determine whether a residency or audit requirement is met.
ownCloud Infinite Scale (oCIS) is the better fit when the files must sit in your own datacenter, or in infrastructure you contract directly, and when identity must stay with your existing provider. oCIS is an Apache-2.0 binary of microservices that runs on a single server or on Kubernetes with Helm charts, and it can use an external OpenID Connect provider such as Keycloak in place of its embedded identity provider. It also lets you choose your editor: Collabora Online, ONLYOFFICE Docs or Microsoft Office Online Server can all attach through WOPI. That choice matters if you already license one of these editors or have a policy on which office engine handles documents. Confirm the storage backend (S3, NFS or PosixFS) and the WOPI connector version with the oCIS documentation before you commit to a design.
The decision turns on three questions. First, where must the data physically and administratively sit, and who may access it for support? Second, does your team have the Linux, Kubernetes or storage skills to run oCIS, back it up and upgrade it on your schedule, or will you need a retainer or an implementation partner for that? Third, how much version history and external collaboration do your users need? Box plan tiers set limits on file size and version retention, and oCIS version retention and external sharing depend on how you configure it, so list those requirements in writing and test them on a pilot before you plan a migration.
Which option fits which scenario
This table matches common situations to the better fit between Box and ownCloud Infinite Scale. Read each row as a starting point, then confirm the constraints listed in your own environment before choosing. The main takeaway is that oCIS suits teams that need storage and identity under their control and can staff a Kubernetes or server platform, while Box remains simpler for teams that want a managed service and rely on its integrations.
| Scenario | Better fit | Reason |
|---|---|---|
| Regional data residency mandate | Depends on the mandate: oCIS in your own datacenter or in-country provider | Box Zones selects one of its storage regions, but you still need to confirm how metadata, support access and key handling are documented. With oCIS you choose the facility, so residency evidence comes from your own infrastructure records. |
| Existing Keycloak or Entra ID setup | oCIS with an external OpenID Connect provider | oCIS can connect to external OpenID Connect providers such as Keycloak, so your existing directory and sign-in policies can stay in place. Confirm the claims mapping and group handling for your provider before committing. |
| Small team with no platform staff | Box, unless you can fund a managed or supported deployment | Running oCIS means operating containers or a Kubernetes cluster, upgrades, backups and monitoring. A small team without that skill set should weigh a supported deployment or stay with a managed service. |
| On-premises storage on S3 or NFS | oCIS with S3, NFS or PosixFS backends | The oCIS documentation lists S3, NFS and PosixFS storage backends, so you can keep bytes on your own object store or file system. Box stores content in its own cloud, so this need usually points to oCIS. |
| Heavy reliance on Box integrations | Box, until each integration has a replacement plan | Box has a broad catalog of connected apps and workflows. Before moving, list every integration, confirm whether oCIS or a WOPI editor supports it, and budget time to rebuild any that do not. |
| Office editing for Word, Excel and PowerPoint files | oCIS with Collabora Online, ONLYOFFICE or Office Online Server | oCIS supports collaborative editing through WOPI with these editors. Confirm which formats and co-authoring features each editor provides in your chosen version. |
| Long-term control of the source code and licensing | oCIS (Apache-2.0) | oCIS is licensed under Apache-2.0 and can be self-hosted. Note that ownCloud is part of Kiteworks, so review the vendor relationship and support terms in writing before you rely on a specific release line. |
Where your files and identity live
Box and a self-hosted ownCloud Infinite Scale deployment answer the same question in different places: who holds the bytes, who runs the identity provider, and who can produce evidence when an auditor asks. The cards below walk through those decisions in the order they usually come up in a renewal review.
Data location and residency
Box Zones lets administrators choose one of several storage regions for encrypted content at rest, which is a region choice made inside Box's cloud. An oCIS deployment places content on storage in your own datacenter or an in-country provider, using S3, NFS or PosixFS backends. Check whether your regulator cares about where content sits, where metadata sits, or both, because the answer changes the design.
Hosting model options
oCIS ships as a single binary of microservices that can run on one server or on Kubernetes with Helm charts. Box is a hosted service with no servers for you to patch. A managed partner can operate oCIS for you, but then the operator's access and location become part of your data location review. Decide which model your operations team can run for the next several years, not only for launch.
Identity and single sign-on
oCIS includes an embedded identity provider and can also federate with external OpenID Connect providers such as Keycloak. Box's identity configuration is managed in its admin console and its own SSO setup. Confirm which identity source is authoritative for joiners, movers and leavers, and whether group membership flows from your directory into file permissions. A basic oCIS install without an external provider is suitable for evaluation, not for a regulated estate.
Audit evidence and access logs
Auditors usually ask who can read regulated content, who administers the platform, and how those actions are logged and retained. With Box, much of that evidence comes from the vendor's controls and reports. With oCIS, your team owns the logs, the backup records and the access reviews. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications; independent auditors do that work.
Vendor assurance documents
Box publishes its security and compliance documentation for customers to review during procurement. A self-hosted platform has no equivalent vendor package for your environment, so you must build the assurance file yourself: architecture diagrams, data flow maps, encryption settings, key management and backup procedures. Ask ownCloud or Kiteworks which documentation covers the open-source release and which parts only apply to commercial subscriptions.
Support access and key custody
Box staff access to customer content follows Box's policies, which you should read rather than assume. In a self-hosted deployment, administrators hold the keys and decide whether any vendor or partner can reach the data. Write down who holds encryption keys, who can open a support session, and how that access is approved and recorded before the migration begins.
How oCIS fits into your infrastructure
Infrastructure Infinite Scale (oCIS) is a single Go binary of microservices, so the same product can run on a small server for a pilot group or on a Kubernetes cluster for the whole organization. The ownCloud documentation and the oCIS README describe it running from a Raspberry Pi up to Kubernetes clusters, and basic deployments need no external database and no external identity provider. That makes a first proof of concept cheap to stand up. Before you commit, decide how many users, how many concurrent uploads and how much availability you need, then test those numbers on your own hardware. Keep the Helm chart and the Kubernetes deployment path in mind from the start if you expect growth, because moving a running pilot onto a different topology is work you should plan for.
The embedded LibreGraph Connect identity provider is enough for a small or isolated deployment. You should plan for an external OpenID Connect provider such as Keycloak when users already sign in through a corporate directory, when you need multi-factor authentication or conditional access enforced centrally, or when several applications must share one login. Confirm with your identity team which provider will be the source of truth for groups and roles, and test the claim mapping for each oCIS role before go-live. Storage is the second decision. The oCIS documentation lists S3, NFS and PosixFS backends. Object storage fits Ceph RADOS Gateway, SeaweedFS or Garage deployments in your own datacenter, while NFS or PosixFS suits existing file servers. Confirm backup and restore for whichever backend you pick, because oCIS metadata and file blobs must stay consistent.
Do not confuse oCIS with classic ownCloud Server. Classic ownCloud Server (owncloud/core) is a separate AGPL-3.0 product, and the ownCloud Server 11.0 system requirements describe deploying it with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. oCIS is an Apache-2.0 Go binary with its own architecture, configuration and upgrade path, so documentation, container images and support guidance for one do not transfer to the other. When you request a quote or read vendor material, confirm which product and version the material covers. Your evaluation, migration plan and security testing should name oCIS explicitly.
What each option costs to run over time
This table breaks down the recurring and one-time costs of staying on Box versus running ownCloud Infinite Scale on your own infrastructure. Read each row for who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Quote figures should come from your own vendor and partner conversations, not from this page.
| Cost component | Box | Self-hosted oCIS |
|---|---|---|
| Subscription | Recurring per-user fee that depends on plan tier; file size limits and version retention vary by tier. Confirm current terms with Box. | No license fee for the Apache-2.0 oCIS binary. Optional support contracts are a separate recurring cost if you want them. |
| Storage growth | Priced into the plan and typically scales with seats and tier. Growth beyond plan allowances is a commercial conversation. | Recurring infrastructure cost on your own storage (S3, NFS or PosixFS backends). Grows with retained versions and copies, so track it monthly. |
| Backups and retention | Largely handled by the vendor within the plan. Ask what recovery and retention terms apply to your tier. | Your team or partner owns backup design, restore testing and offsite copies. Recurs with data volume and recovery objectives. |
| Infrastructure and hosting | Minimal on your side beyond client endpoints and identity integration. | Recurring compute, Kubernetes or server capacity, database and network costs, plus identity provider hosting if you use Keycloak or another external provider. |
| Upgrades and staff time | Vendor-managed upgrades; internal effort mostly covers admin and user changes. | Recurring. oCIS publishes frequent releases, such as v8.2.1 and v9.0.0-rc.1, so budget staff or a retainer for testing, patching and rollouts. |
| Migration effort | One-time cost to export content, plus re-creating shares, permissions and integrations during exit. | One-time cost to deploy, integrate identity and WOPI editing, migrate data from Box and validate permissions. Scope it in writing before work starts. |
What a move from Box to oCIS involves
The sequence turns Box content into an oCIS deployment on storage you control, with permissions, links and editing rebuilt and checked before users move. Each step closes with a check the team can verify.
Inventory content, owners and sharing
Your team lists the folders, file sizes, owners, external collaborators and shared links in Box, and records which content is still in active use. Identify which files exceed the 32 GB per-file limit for FTPS transfers, since those need a different route. Confirm with Box which bulk transfer options your plan includes, because FTPS and SFTP access is offered to Business and Enterprise customers. The step is done when you hold a written inventory that the business owners have signed off, with a list of what must be kept and what can be archived.
Export content in bulk over FTPS or SFTP
An administrator with Box FTPS or SFTP access pulls the content in bulk, using the method Box describes for bulk migration and occasional bulk download. Export files in batches, verify file counts and total sizes against the inventory, and store the export on a staging volume you control. A plain download does not keep version history, comments, metadata or the full permission model, so record those separately from Box if you need them. The step is done when every batch reconciles with the inventory and the staging copy is checksummed.
Pilot oCIS with your identity provider and storage backend
Your platform engineers deploy oCIS in a pilot environment, either as a single binary on a server or on Kubernetes with the Helm charts. Choose between the embedded LibreGraph Connect identity provider and an external OpenID Connect provider such as Keycloak, and select the storage backend (S3, NFS or PosixFS) that matches your data location rules. Test sign-in, group mapping and quota behavior with a small set of test accounts. The step is done when the pilot passes the login and storage tests your security team wrote, and the backup procedure has been restored once in a test.
Load exported data into oCIS spaces
Your team imports the staged folders into oCIS spaces, grouped the way the business uses them, and checks file integrity against the staging checksums. Decide in advance which Box version history is carried over and which is archived as read-only copies, because oCIS will not reconstruct Box version history from a plain export. Record any files that fail to import and resolve them individually. The step is done when a sample of files from each space opens correctly and totals match the reconciled inventory.
Rebuild shares, permissions and links
Your administrators recreate space memberships, group roles and external shares based on the permission inventory from the first step, rather than copying Box settings one by one. Shared links that external partners rely on are reissued and communicated, and expiry settings are reviewed against your sharing policy. Confirm with the business owners that each space has an accountable owner. The step is done when a permission review shows every space has the intended members and no orphaned external access.
Configure WOPI editing with your chosen office server
Connect oCIS to Collabora Online, ONLYOFFICE Docs or Microsoft Office Online Server through WOPI, and test opening, co-editing and saving of .docx, .xlsx and .pptx files. Check that the WOPI endpoints are reachable from user networks and that certificates and timeouts are set for your environment. Confirm the licensing and support terms of the office server you pick, since Collabora's free CODE edition differs from the enterprise edition with support and SLAs. The step is done when test users can edit and save documents in each supported format without data loss.
Cut over users and roll out clients
Schedule the cutover with the business owners, freeze changes in Box for the migrated content, and run a final incremental export for anything changed since the bulk copy. Roll out the ownCloud desktop, Android and iOS clients through your normal software distribution, and publish short guidance on sign-in and where content now lives. Keep Box read-only for a period agreed with the business owners, then retire access after the agreed exit checks pass. The step is done when the users in scope sign in on oCIS, the final delta reconciles, and the Box access removal is recorded in your change system.
Questions buyers ask before switching from Box
How much does it cost to move from Box to oCIS?
The cost is driven by components, not by a single license line. oCIS is Apache-2.0 licensed, so the software itself carries no license fee. Recurring costs include the servers or Kubernetes capacity, object or file storage that grows with your content, backups, monitoring, and any support subscription you choose. One-time costs include planning, the content migration, identity integration, and the editing setup for Collabora Online, ONLYOFFICE or Office Online Server. Ask any implementation partner for a quote built from a written scope that lists each of these components separately. Ask the vendor of your chosen office editor what its own license or support terms are, since those are separate from oCIS.
How long does a Box to oCIS migration take?
The pace is set by how much content you move, how much version history you keep, how many users and groups must be mapped, and how many integrations must be rebuilt. Bulk export from Box uses FTPS or SFTP for Business and Enterprise customers, and Box limits files transferred over FTPS to 32 GB each, so large or oversized files need a separate path. Identity integration with an OpenID Connect provider and the WOPI editing setup add their own steps. Pilot a single department first to measure real throughput in your environment, then plan the remaining waves from that measurement.
What does the internal team need to run oCIS?
Your team needs Kubernetes or Linux server skills to run oCIS, which ships as a single binary of microservices and offers Helm charts for Kubernetes. Someone must own storage backend choice among S3, NFS and PosixFS, backups, upgrades and monitoring. Identity administration is needed for the OpenID Connect provider, whether that is the embedded LibreGraph Connect or an external service such as Keycloak. Security staff should own the access model and the review of shared links. Document who owns each of these roles before the project starts, because they continue after the migration ends.
Can our team migrate to oCIS without outside help?
A team with Linux, container and identity skills can do it internally, but the work is larger than installing a binary. Basic deployments need no external database or identity provider, yet production setups with high availability, object storage, WOPI editing, and integration with existing identity and logging usually require design decisions and testing. Many organizations combine internal ownership with a fixed-scope engagement for planning, implementation, hardening and documentation. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under written scopes. Confirm each deliverable and timeline in writing before work starts.
Can oCIS replace Box Zones for data residency?
oCIS can keep content in a location you choose, because it runs in your own datacenter, a private cloud, or an in-country provider. Box Zones lets administrators pick one of 10 storage regions for encrypted content at rest, so the two models differ in who operates the infrastructure and who can access it. With oCIS, your organization controls the storage backend, the encryption keys and the support access. Confirm with your auditors and regulator which evidence they need, such as data flow diagrams, administrator access logs and backup locations, because oCIS does not provide certifications or attestations on its own.
Is oCIS licensed differently from classic ownCloud Server?
Yes. oCIS is a separate Apache-2.0 platform written in Go, while the classic ownCloud Server (owncloud/core) is licensed under AGPL-3.0. The two codebases are distinct projects with different architectures, so licensing terms and upgrade paths differ. Classic ownCloud Server 11 is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. ownCloud GmbH announced that it became part of Kiteworks, and said the open-source position would stay the same. Ask the vendor to confirm current license terms and support options for each product before you choose.
Which Box features does oCIS not cover out of the box?
Several Box features need explicit planning rather than assumed parity. Box Notes and third-party Box integrations must be replaced or rebuilt. Shared links, collaborator permissions and version history do not move through a plain download, so the migration must map them deliberately. Governance, retention and external collaboration rules need to be defined in your own policy and tooling. Ask for a written gap list from any partner, and check each item against the current oCIS documentation and your own test environment before committing.
Where migrations to oCIS usually stall
The hardest part of leaving Box is rarely the bulk copy. It is deciding what the new system should mean for permissions, shared links and history. Box folder collaborators, group memberships and link settings such as passwords and expiry do not translate one to one into oCIS spaces, shares and roles. Before any transfer, export a sample of folders, list every collaborator and external link, and write down which ones must survive as live access and which can be recreated by the owner. Confirm with your own oCIS build how it maps shares, roles and link options, and agree the mapping with the data owners who will sign off on it.
Version history is the second decision. A bulk download over FTPS or SFTP gives you current files, but it does not carry Box's version chain with it, so carrying history forward usually means a separate, deliberate step. Set a retention position for each class of content, such as contracts or regulated records versus working drafts, and check the governing retention rules with your compliance owner. Box Notes and third-party integrations, such as Box Relay, Box Sign or connectors to line-of-business systems, need a named replacement or a documented retirement. Confirm which of your integrations use Box APIs and which can be moved to oCIS WebDAV, CS3 or WOPI endpoints, since many will need code changes rather than configuration.
Client rollout is where users first feel the change. Plan which ownCloud web, desktop, Android and iOS clients each group will install, how sync folders from Box Drive or the Box desktop app will be migrated, and how the cutover date is communicated. Test WOPI editing with Collabora Online, ONLYOFFICE or Office Online Server on the documents your users open most often, because editing failures are the most common support ticket after go-live. A pilot group with real workflows, run for a fixed period before the Box contract ends, usually exposes the permission and sync issues that a test folder does not. Ask any implementation partner to write these checks into the fixed scope so they are signed off, not assumed.
How DeployOpen helps evaluate and move to oCIS
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Box vs ownCloud, we start with a written scope that tests whether oCIS fits your identity, storage and editing requirements before any migration work begins.
How we scope
- Written scope that names which Box plans, user groups and shared folders are in and out of the migration
- Review of identity requirements, including whether oCIS's embedded identity provider or an external OpenID Connect provider fits your directory
- Confirmation of where content must live, whether a single server, Kubernetes cluster or your own datacenter
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Deployment of oCIS on the storage backend you choose, such as S3, NFS or PosixFS, sized to your confirmed data volumes
- Integration of Collabora Online, ONLYOFFICE or Office Online Server through WOPI, tested against the file types your teams actually edit
- Configuration of OpenID Connect sign-in, client rollout and access rules, with the hardening steps documented alongside
- Test runs of bulk export from Box over FTPS or SFTP into the new environment, checking file counts, paths and permissions
How we hand over
- Documentation of the architecture, configuration, backup and upgrade procedures written for your own operations team
- Evidence packs and control descriptions prepared for your compliance assessors, who issue any audit report or certification
- Runbooks for user onboarding, shared link policy and recovery, so administrators can operate the platform without us
- Knowledge transfer sessions scheduled against the written scope, with open items recorded for follow-up
How we support
- Ongoing support, upgrades and continuous security testing available as a retainer after handover
- Periodic review of oCIS release notes and security advisories, with upgrade plans agreed in writing
- Security testing of the file sharing service, including its API and WebDAV endpoints, on request
- Retainer scope and response expectations confirmed in writing, with a quote following from the agreed scope
