Nextcloud or OpenCloud: when each one fits
Choose Nextcloud when the platform must do more than store and share files. Nextcloud is a PHP application on a database stack (MySQL, MariaDB or PostgreSQL in the Nextcloud 35 requirements), and its app ecosystem covers calendar, talk, office integration and workflows in one install. Choose OpenCloud when the requirement is a pure file service: a Go server that keeps data in the filesystem with no database, which means fewer moving parts to back up, patch and monitor. The decision turns on five questions: which apps your users need on day one, how identity will be wired, which office editor you will connect, whether you need paid support, and how you will upgrade over the next few years. Confirm each one against your own requirements before you pick a platform.
Identity is often the deciding factor. Nextcloud documents LDAP and Active Directory login through its LDAP app, and also supports OpenID Connect and SAML backends, so an existing directory can be reused without a parallel user store. OpenCloud authenticates users through OpenID Connect, either against an external provider such as Keycloak or the embedded LibreGraph Connect provider. If your directory is Active Directory and your team already runs Keycloak, test both paths with a pilot group, including how groups and quotas map to your structure. Support needs also differ: Nextcloud GmbH sells Enterprise tiers with stated maintenance and response terms, while OpenCloud GmbH offers paid builds with support and professional services. Ask each vendor for the written support terms that apply to your version and region.
Plan the upgrade path before you commit. Nextcloud requires one major version at a time, a backup before each upgrade, and third-party apps disabled until they are confirmed compatible, so budget time for app testing on every cycle. OpenCloud's filesystem storage removes database migrations from the picture, but you still need to confirm how each release handles storage layout and client compatibility. Office integration is the other check: if you need collaborative document editing, confirm which editor and connector pairing you will run with each platform before you size the server. A simple test is to load a sample of your real file tree, run a sync client on two laptops and a mobile device, and rehearse one restore.
Which platform fits which scenario
This table matches common team situations to the platform that fits better and the reason. Read each row as a condition: if it describes your team, the named platform is the stronger starting point, and the reason shows what would change that.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Pure file service for a small or mid-size team | OpenCloud | OpenCloud stores data in the filesystem with no database to run, which reduces moving parts if the need is files and sharing only. Confirm the storage backend and backup approach for your volume. |
| Calendar, Talk and office apps on one platform | Nextcloud | Nextcloud's app ecosystem covers calendar, Talk and office integration in one PHP platform, and Nextcloud All-in-One can bundle Talk with recording and optional Nextcloud Office. Confirm each app's support status for your chosen version. |
| Team standardized on Active Directory through LDAP | Nextcloud | Nextcloud's LDAP app lets directory users appear in Nextcloud and sign in with directory credentials. Confirm how OpenCloud's OpenID Connect path would reach your directory before choosing it for this case. |
| Team on Keycloak or another OpenID Connect provider | OpenCloud | OpenCloud authenticates users through OpenID Connect with an external provider such as Keycloak, and also offers an embedded LibreGraph Connect option. Nextcloud also documents OpenID Connect, so compare claim mapping and group handling in your environment. |
| Team needing paid vendor support | Nextcloud (confirm for your scope) | Nextcloud GmbH sells Enterprise with a 100-user minimum, and OpenCloud GmbH offers paid builds with support and professional services. Teams under 100 users should ask OpenCloud GmbH for its support terms in writing before deciding. |
| Upgrades planned on a fixed major-version path | Nextcloud | Nextcloud supports each major line for one year and requires upgrading one major version at a time, with backups before each step. Teams that value a documented, predictable upgrade sequence should plan for that cadence. |
| Team that wants the lightest server stack to operate | OpenCloud | OpenCloud is a Go codebase with no database dependency, while Nextcloud 35 requires a PHP runtime and one of several supported databases. Confirm the operating effort against your own platform team's skills and monitoring. |
How each platform is built and what that means for operations
Nextcloud and OpenCloud take very different routes to the same file service. The choices below decide what you back up, what you monitor and which skills your team needs before go-live. Check each one against your own infrastructure and your staff, not against the feature list.
Nextcloud is a PHP and JavaScript application
Nextcloud Server is written mainly in PHP and JavaScript/TypeScript, so your team needs PHP-FPM tuning, web server configuration and database administration skills. Supported databases are MySQL, MariaDB and PostgreSQL, and Oracle and SQLite carry limitations. Confirm which PHP and database versions your chosen Nextcloud line supports before you pick a stack, since the supported matrix is version specific.
Nextcloud caching and bundled services
A manual Nextcloud install means you choose and configure Apache or nginx with php-fpm, plus any Redis or APCu caching. Nextcloud All-in-One bundles Redis and APCu caching, PostgreSQL, optional Nextcloud Office, Talk, BorgBackup, ClamAV and full-text search inside a managed set of containers. Ask which of these services you will own after installation, because each one adds patching and monitoring work.
OpenCloud stores everything in the filesystem
OpenCloud is a Go codebase under Apache 2.0 that keeps all data in the filesystem and uses no database. Backups therefore center on the storage volume and its consistency, not on a database dump plus file snapshot pair. Ask how your backup tool captures a live filesystem tree and metadata, and test a restore before you rely on it.
OpenCloud sign-in through OpenID Connect
OpenCloud users authenticate through OpenID Connect, either against an external identity provider such as Keycloak or against the embedded LibreGraph Connect provider. An external provider means you run and patch a second identity system and manage its realm, clients and token lifetimes. The embedded provider reduces components but still needs review for your production identity requirements.
Storage backends and monitoring at scale
The oCIS documentation lists S3, NFS and PosixFS storage backends, so the choice of storage is an early design decision with backup, latency and monitoring consequences. Confirm which backend your OpenCloud build supports in production and what metrics it exposes to your monitoring stack. OpenCloud v8.1.0 was published on October 5, 2026, so check the release notes against your deployment plan.
How sign-in and office integration differ
Nextcloud treats identity as a set of pluggable backends. Local accounts are the starting point, and directory and federated sign-in are added through apps and configuration. For teams that already run Active Directory or another LDAP directory, the LDAP app lets directory users appear in Nextcloud and sign in with their directory credentials. Nextcloud also documents OpenID Connect and SAML as user authentication backends, which gives a second path when the directory is not the source of truth.
- LDAP and Active Directory: the LDAP app maps directory users and groups into Nextcloud, so access can follow existing directory membership.
- OpenID Connect: documented as a user authentication backend for federated sign-in through an existing identity provider. Confirm the app version and provider settings you need.
- SAML: documented as a backend for providers that speak SAML only. Confirm the supported configuration for your provider before you commit to it.
- Mixed sources: many teams combine a directory for staff with OIDC for partners. Test how accounts, groups and quotas map across both sources before go-live.
Check which backend your identity provider supports, whether group mapping covers your access model, and how a removed account ends its active sessions and sync clients.
OpenCloud signs users in through OpenID Connect. You can connect an external identity provider such as Keycloak, or use the embedded LibreGraph Connect provider. Because OpenCloud stores its data in the filesystem and uses no database, the identity provider is where users, groups and account lifecycle are managed. Your design therefore depends on the provider's capabilities as much as on OpenCloud itself.
- External provider: Keycloak is named as an example of an external OIDC provider. Your existing identity provider must speak OIDC for this path to work.
- Embedded provider: LibreGraph Connect is the built-in option. It can reduce the number of separate identity services in a small deployment. Confirm that it meets your user lifecycle and audit needs.
- Directory access: the supplied material describes OIDC as the sign-in model. Confirm with OpenCloud whether direct LDAP or Active Directory binding is available before you assume it.
- Single protocol: one sign-in model keeps the design simple, but a directory-only environment will need a bridging identity provider in front of OpenCloud.
Ask OpenCloud how groups and roles reach the file service, how the embedded provider is backed up, and how a removed user's sessions end across sync clients.
Online document editing in Nextcloud runs through office components that sit beside the Nextcloud server. You deploy and connect them, and the editor you choose carries its own license, edition model and support path. Nextcloud All-in-One can include an optional Nextcloud Office component, which is one way to install it alongside the server. Confirm the editor, its license and its update path before you plan the rollout.
- Collabora Online: source code is under MPL-2.0 and integrates through the WOPI protocol. It is built on LibreOffice technology. Collabora describes the free CODE edition as not recommended for production, and the paid Collabora Online adds tested updates, security fixes and support.
- ONLYOFFICE Docs Community: licensed under AGPL-3.0. ONLYOFFICE lists its admin panel, white labeling and paid support tiers as Enterprise Edition features.
- Nextcloud Office: an optional component in All-in-One. Confirm its license, supported file formats and update cadence with Nextcloud.
- Operating load: the office server is another service to patch, size and monitor, with its own TLS and network reachability requirements.
Confirm which editor your users need for file formats, co-authoring and external sharing, and which edition includes the support your team requires.
The supplied material for OpenCloud covers storage, sign-in and licensing, but it does not describe an office integration path in detail. Confirm in OpenCloud's documentation which editors it supports, which integration protocol they use and how each is deployed. Until that is confirmed, treat office as an open item in the design and do not assume it matches the Nextcloud setup.
- Documented path: check the OpenCloud documentation for supported editors and connector protocol before you scope the work.
- Editor licensing: if you select Collabora Online or ONLYOFFICE Docs, the license and edition points in the Nextcloud office tab still apply to that editor.
- Separate service: an editor runs as its own service with hosting, TLS and upgrades, and those tasks belong in the written scope of any implementation.
- Test with your own files: verify the file types, co-authoring behavior and editor versions your users depend on, using your own documents.
Ask OpenCloud for a written list of supported office integrations, the versions it has tested, and the support path for each component.
Capabilities, storage and maintenance compared
This table sets Nextcloud and OpenCloud side by side on license, storage, identity, office integration, release cadence, paid support and upgrade rules. Rows marked for confirmation reflect current OpenCloud capabilities that the sources we reviewed do not fully establish, so verify them with OpenCloud GmbH before you decide. The main takeaway is that the two platforms differ most in storage design and in how much an upgrade path depends on the release model.
| Capability | Nextcloud | OpenCloud |
|---|---|---|
| License | AGPL-3.0 for the server, with Nextcloud GmbH selling an Enterprise subscription | Apache 2.0 and AGPL-3.0, with OpenCloud GmbH offering paid builds for support and professional services |
| Storage design | Primary storage on local disk, NFS or object storage, with metadata held in a database | Files stored in the filesystem with no database, per the project README |
| Database requirement | Required: MySQL 8.4 or 9.7, MariaDB 10.11 to 12.3, PostgreSQL 14 to 18, or Oracle under an enterprise subscription | No database required, per the project README |
| Identity options | LDAP and Active Directory, plus OpenID Connect and SAML authentication backends | OpenID Connect with an external provider such as Keycloak or the embedded LibreGraph Connect provider |
| Office integration | Nextcloud Office and Talk are available as apps; confirm the current integration options for your version | Confirm current office integration options and supported editors with OpenCloud GmbH |
| App ecosystem | Large app catalog covering office, chat, calendar, antivirus and search | Narrower file-service scope; confirm which extensions and integrations are maintained |
| Release cadence | New major version every four months, with each supported for one year; Nextcloud 35 is supported until September 2027 | OpenCloud v8.1.0 published October 5, 2026; confirm the current release and support windows |
| Paid support | Enterprise tiers (Standard, Premium, Ultimate) with a 100-user minimum for list pricing | Paid builds for support and professional services; confirm what support terms and lifecycle apply |
| Upgrade rules | Major releases cannot be skipped; upgrade one major version at a time, back up first and disable third-party apps until confirmed compatible | Confirm the upgrade path and whether any major-version rule applies |
What drives the running cost of each platform
Running cost splits into one-time work and recurring work, and the two platforms shift that split differently. One-time costs cover planning, the initial install, identity integration, office server setup, migration of existing shares and any custom app work. Recurring costs cover hosting, database and storage, backups and restore testing, upgrades, staff time and any paid support or subscription. Nextcloud's community server is AGPL-3.0-only, so the code itself costs nothing to obtain, but a Nextcloud Enterprise subscription adds a per-user recurring fee with a 100-user minimum, and OpenCloud offers paid builds for teams that need support and professional services. Ask every bidder to separate license or subscription lines from hosting and labor lines, so the comparison is not distorted by bundling.
The biggest recurring cost driver for a pure file service is usually the database and identity layer. Nextcloud keeps metadata in MySQL, MariaDB or PostgreSQL, so you pay to administer and back up that database, and its LDAP app or OpenID Connect and SAML backends add integration work to maintain. OpenCloud stores all data in the filesystem with no database and authenticates through OpenID Connect against an external provider such as Keycloak or its embedded LibreGraph Connect, so the recurring work shifts toward the identity provider and the storage volume. Office integration is a separate cost either way, because a document server has its own hosting, patching and licensing terms. Backups are priced by data volume and restore-test frequency, not by the platform name. When requesting quotes, ask for an itemized estimate covering the components above, the named versions and their support windows, the number of users and expected growth, the storage backend and its backup method, the identity integration in scope, the upgrade path for the next major release, and the support tier with response times in writing. Confirm which costs recur annually, which scale with users and which scale with storage. Ask whether an OpenCloud paid build or Nextcloud Enterprise tier is quoted as an option or as a requirement. Plan for a scheduled upgrade cycle in both cases: Nextcloud requires one major version at a time with a backup before each step, which is staff time you should budget for every release.
Moving files and users from one platform to the other
This sequence moves users, groups, shares and file data from one platform to the other without losing access or metadata along the way. It ends with a verified target instance, a documented cutover and a retired source system that no one can still write to.
Inventory users, groups, shares and sync clients
The migration lead and the current administrator list every user, group, folder share, public link, guest account and desktop or mobile sync client on the source instance. Record which apps hold data or workflows, such as calendars, contacts, office editing or external storage mounts, because each one will need its own decision. The step is done when the inventory is signed off by the business owner of each shared folder and the list of apps has a keep, rebuild or drop decision attached to it.
Map identity to the target directory
The identity owner decides how sign-in will work on OpenCloud, which uses OpenID Connect with an external provider such as Keycloak or the embedded LibreGraph Connect provider, and confirms how the source instance authenticates today, whether local accounts, LDAP or Active Directory, SAML or OpenID Connect. Map each source account to a stable identifier in the target so that ownership and group membership survive the move. The step is done when a test account can sign in to a staging target through the chosen provider and every group resolves to the same members as before.
Export and verify file data and metadata
The storage engineer copies file content and the metadata that describes it, including owners, timestamps and versions where the tooling supports them, from the source to the target storage backend. Confirm the chosen transfer method for each version of both products, because migration tooling and supported paths change between releases. Compare file counts, total sizes and checksums for a sample of directories, and review any files the tool skipped. The step is done when a reconciliation report shows matching counts and no unexplained differences in the sampled sets.
Rebuild shares, office integration and apps
The platform engineer recreates what does not transfer cleanly: public share links, expiry and password settings, office editing connections, calendar and contact sync, and any external storage mounts. Test each rebuilt item with a named user from each group, and document any feature that has no equivalent on the target so that the business owner accepts the gap in writing. The step is done when every item on the inventory has a passing test or a signed exception.
Run parallel access with a defined rollback
A small pilot group works on the target while the source stays available read and write for everyone else, and the team tracks every defect and support request against the inventory. Agree in advance who can trigger a rollback, what data is considered authoritative during the overlap, and how changes made on the target are reconciled back. The step is done when the pilot group has completed normal work for an agreed period and the defect log has no open items that block general use.
Cut over users and freeze the source
The team schedules a cutover window, runs a final incremental copy, switches DNS or client configuration to the target and places the source into read-only mode. Desktop and mobile sync clients are pointed at the new address and tested with one device per platform before the wider user group is moved. The step is done when the final reconciliation matches the source, all active users sign in to the target and the source logs show no new write activity.
Retire the old instance and keep the evidence
After a retention period set by the data owner and the compliance lead, the team takes a final backup of the source, removes its access paths and decommissions the hosts. The compliance lead archives the migration inventory, reconciliation reports, sign-off records and the backup reference, so that auditors can trace what moved and when. The step is done when the source is offline, the archive is stored under the organization's retention policy and the decommissioning ticket is closed.
Where implementation projects usually run long
Identity and storage decisions cause most of the schedule slips, because both are costly to change once users sign in and files land on disk. On Nextcloud, the team has to choose between the LDAP app, OpenID Connect or SAML user backends, and each choice changes how groups, quotas and admin roles map from the directory. On OpenCloud, sign-in runs through OpenID Connect with either an external provider such as Keycloak or the embedded LibreGraph Connect provider, so the team must settle that claims model before the first pilot. The client team should supply directory owners, a group mapping sheet, test accounts for each role and a decision on who owns the identity provider after go-live. For storage, confirm which backends the chosen OpenCloud version supports (the oCIS documentation lists S3, NFS and PosixFS, and the team should verify that list for OpenCloud itself) and fix the choice before any user uploads data.
Office integration and client rollout are the next places where plans drift. Confirm with the office editor vendor how many concurrent editors each server must handle, then size the office tier from that answer and from the hardware you already run, not from assumptions. Nextcloud's app ecosystem is the larger variable: Nextcloud's upgrade guidance says to disable third-party apps until each is confirmed compatible, so the team needs a written inventory of every app in use and an owner who signs off on each one before a major upgrade. OpenCloud's smaller app surface shortens that inventory, but the team should still list the workflows that depend on any external integration. Sync client rollout also needs a pilot group, a managed install method for desktops and mobile devices, and a plan for users who already sync from another service.
Backup and restore testing is the step most often skipped, and it decides whether the rollout can be trusted. A backup that has never been restored is an unverified assumption. Nextcloud requires a backup before every upgrade and one major version at a time, so the restore test should cover both the data directory and the database, with a timed run and a user-level file check. OpenCloud stores data in the filesystem without a database, which changes what the restore test must capture, and the team should document that path explicitly. DeployOpen plans, implements, documents and supports these items under a written fixed scope, with deliverables and timelines agreed before work starts. The client team still has to name the data owner, approve sign-off criteria, provide maintenance windows and keep staff available for pilot feedback. Ongoing upgrades and support are available as a separate retainer.
Questions buyers ask before choosing
How much effort does migrating between Nextcloud and OpenCloud take?
Migration effort depends mainly on how much of your work lives in Nextcloud apps and how your users and files are mapped. Nextcloud stores file metadata in a database and runs a large app ecosystem, while OpenCloud keeps data in the filesystem with no database and authenticates through OpenID Connect. Expect work in four areas: exporting and validating file trees and permissions, re-creating sharing rules, reconnecting clients and identity, and retiring any Nextcloud-only apps your team depends on. Before you commit, test a representative sample of users, shares and folders in a non-production instance. Ask both vendors and any implementation partner to scope the move in writing, since no fixed effort figure for this path is published in the sources we rely on.
Can a small team run Nextcloud or OpenCloud without outside help?
A small team with Linux administration experience can run either platform, but the workload differs. Nextcloud 35 needs a supported PHP version, a supported database such as MariaDB, PostgreSQL or MySQL, and a web server such as Apache or nginx with php-fpm, and it requires one-major-version-at-a-time upgrades with backups before each step. OpenCloud is a Go server with no database, which removes one component to patch but still needs identity integration through OpenID Connect and regular backups of the filesystem data. Decide who owns patching, upgrades, backups and restore tests, and whether that person has time for them each month.
Does a small team need Nextcloud Enterprise?
Not for the software itself. The Nextcloud Server code is AGPL-3.0-only, so a community deployment is free to use. Nextcloud GmbH sells Enterprise as a paid subscription with support and maintenance terms. According to Nextcloud's pricing page, Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum, and list prices start at 71.29 euros per user per year for Standard at 100 or more users, with lower rates from 200 users. A smaller team should instead weigh whether it needs a vendor response commitment, and should ask Nextcloud GmbH for current terms before deciding.
Does OpenCloud need a database to run?
No. According to the OpenCloud GitHub README, the server is a Go codebase that stores all data in the filesystem and uses no database. That simplifies the stack, but it shifts attention to filesystem layout, backup consistency and storage performance. Identity still matters: users sign in through OpenID Connect, either with an external provider such as Keycloak or with the embedded LibreGraph Connect provider. Confirm with OpenCloud how it handles metadata, backup and restore for your storage choice, and test a full restore before go-live.
What does the work need from our team?
Plan for four inputs: an owner for the platform, people who understand your identity provider and directory, a storage and backup owner, and business users who can validate sharing, retention and client behavior during testing. For Nextcloud, the LDAP app or SAML and OpenID Connect backends need directory and certificate details from your side. For OpenCloud, the OpenID Connect provider and its claims must be configured and tested. Ask any partner to list these inputs in the written scope so the dependency on your staff is clear before work starts.
How long does a project take, and what sets the timeline?
No standard duration is published for either platform in the sources we rely on, so treat any figure you hear with caution. The timeline is set by the number of users and groups, the number and complexity of integrations (identity, office editing, backup, monitoring), the volume and structure of existing data, the amount of migration from another platform, and how many validation rounds your compliance and security teams require. Nextcloud's release schedule also affects planning, since Nextcloud 35 is supported until September 2027 and Nextcloud 36 is scheduled for 17 February 2027, according to Nextcloud's maintenance schedule. Ask for a written phase plan with acceptance criteria.
Can DeployOpen run either platform for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. That scope can cover Nextcloud or OpenCloud, including identity integration, backup design, upgrades and evidence for compliance assessments. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so request a quote based on a written scope. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
Five decisions that settle the choice
Nextcloud and OpenCloud overlap on file sync and sharing, so the choice usually turns on a few concrete questions. Work through these in order: the apps you need, how users sign in, where data lives, who supports the platform, and how often you can afford to upgrade.
Required apps beyond files
Nextcloud's core value is its app catalog: calendar, contacts, chat, video calls, office integration and workflow apps all run inside one server. OpenCloud is built around file storage, sharing and sync, so the scope is narrower. If your rollout needs a chat or calendar layer, list those apps now and confirm how each one is delivered on OpenCloud before committing. If the requirement is files and sharing only, the narrower scope is a benefit because there are fewer components to run.
Identity provider standard
OpenCloud signs users in through OpenID Connect, either against an external provider such as Keycloak or the embedded LibreGraph Connect provider. Nextcloud supports LDAP and Active Directory login through its LDAP app and also documents OpenID Connect and SAML backends. If your directory is Active Directory and must stay the source of truth, Nextcloud's LDAP path is the more established route. If your identity team already runs an OIDC provider, check that OpenCloud's claim mapping and group handling match your policy.
Storage backend and backup approach
OpenCloud stores all data in the filesystem and uses no database, which simplifies the storage layer but places the consistency and backup burden on your filesystem snapshots and copies. Nextcloud keeps metadata in a relational database (MySQL, MariaDB or PostgreSQL) and file content on local or object storage, so backups must cover both. Map your recovery point and recovery time objectives against each design, then ask each vendor how file and metadata state are kept consistent during a backup.
Support and paid build needs
Both platforms are open source, and both sell paid options. Nextcloud GmbH sells Enterprise subscriptions with support, and OpenCloud GmbH offers paid builds for environments that need support and professional services. Decide whether your organization must have a contracted vendor with defined response times, and whether it needs a maintenance lifecycle longer than the community release window. Ask each vendor for written support hours, response targets and the terms of any long-term maintenance before you assume either option meets your policy.
Upgrade tolerance and release cadence
Nextcloud publishes a new major version every four months and supports each for one year, and it does not allow skipping major releases, so you must step through each one with a backup before every upgrade. Teams that can plan a steady upgrade rhythm usually find this manageable. OpenCloud's release cadence and upgrade path are newer and less documented in the supplied sources, so check its release notes and upgrade guidance for the versions you plan to run. Choose the platform whose upgrade cadence your operations team can actually sustain.
Existing skills with PHP or Go
Nextcloud is written mainly in PHP and JavaScript/TypeScript, so teams with PHP operations experience will recognize its web server, PHP-FPM and database layers. OpenCloud is a Go codebase distributed as a single server, which suits teams already comfortable with Go binaries and filesystem-based operations. Your in-house skills determine how much you will need to outsource for troubleshooting and customization. If your team has neither, weigh the cost of training against the cost of an implementation partner.
How DeployOpen approaches both platforms
DeployOpen does not start from a preferred platform. Nextcloud and OpenCloud are both self-hosted, both open source and both deployable inside your own cloud accounts, data centers or air-gapped networks. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents whichever platform the written requirements point to. DeployOpen is not an official partner, reseller or certified provider of either vendor, so no commercial arrangement with either project shapes the recommendation on this page.
The work is delivered as fixed-scope engagements. Before any build starts, scope, deliverables and timelines are agreed in writing. For this decision, that means the written requirements should cover the points where the two platforms actually differ: whether you need a database and which one, how users sign in (LDAP or Active Directory, OpenID Connect or SAML on the Nextcloud side, OpenID Connect through an external provider such as Keycloak or the embedded LibreGraph Connect on the OpenCloud side), whether office editing must be built in, which backup and restore process you will accept, and which upgrade path your team can run. Each of these becomes a deliverable with an owner and an acceptance test, not an open preference.
Ongoing work after go-live is handled the same way. Support, upgrades and continuous testing are available as retainers, and quotes follow from the written scope rather than a published price list. Ask any integrator, DeployOpen included, to show how upgrades, backups and restore tests will be documented for the platform you select, and to name who is responsible for each. If the requirements are still unsettled, the honest next step is a scoping workshop that produces the written requirements, not a platform decision made on instinct.
How DeployOpen helps choose, 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 Nextcloud vs OpenCloud, that means starting from your user count, identity setup and file workload, then building the platform you pick in your own infrastructure.
How we scope
- We confirm user count, sign-in sources and whether you need office editing, sharing links or external users.
- We map your storage design, database policy and backup targets before any build begins.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We install the chosen platform in your environment and connect it to your identity provider.
- We configure storage, backups and any office or video integrations you have agreed in scope.
- We test sign-in, sync, sharing and restore paths against the written acceptance criteria.
How we hand over
- You receive documentation covering the configuration, runbooks, upgrade steps and backup procedures.
- We walk your administrators through daily operation, user onboarding and recovery tasks.
- Compliance-relevant settings and evidence are prepared for your own auditors, who issue any opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning follows the vendor's release path, with backups taken before each change.
- Quotes follow from the written scope, so you can ask what recurring support and upgrades would cost.
