How do Nextcloud upgrades and support keep a server on a supported major?
A Nextcloud server stays supported only if it moves to a new major version before the one it runs reaches end of life. Nextcloud publishes a new major every four months and supports each one for a year through monthly maintenance releases that fix known critical bugs and security problems. That means an internal instance can fall out of support within a single year if nobody plans the next upgrade. The practical question for an IT lead is who owns that cadence, who runs each major step, and how the team will know when the current version is nearing its end. The release schedule is the starting point: Nextcloud 33 is supported until February 2027, Nextcloud 34 until June 2027 and Nextcloud 35 until September 2027, and Nextcloud 36 is scheduled for 17 February 2027. Confirm the current dates on the maintenance and release schedule before you set a calendar.
The service is usually triggered by one of four situations. The first is an instance approaching end of life with no upgrade window booked. The second is a skipped upgrade, where the server is several majors behind. Nextcloud does not allow skipping major releases, so the team must step through each intermediate version in order, which can turn a single planned change into a chain of changes. The third is a server that cannot move forward without breaking apps, because a third-party app has no version compatible with the next major. The fourth is a decision to move to Enterprise support, which changes who answers when something fails. Each trigger calls for a different first step, so start by recording the installed version, the PHP and database versions, and the list of enabled apps.
In-house or partner is a question of skills and change windows. Teams with Linux, PHP and database operations experience, and spare change windows, often keep routine minor maintenance in house, including applying monthly maintenance releases after a backup. The parts most often outsourced are the multi-step major path, app compatibility review, and recovery planning. These require testing each step against a copy of production, checking the server against the system requirements for the target major (which set supported MariaDB, PostgreSQL, PHP and web server versions), and agreeing a rollback plan before the change. Ask any partner to show how they test app compatibility and how they restore from a backup taken just before the upgrade.
Nextcloud offers two support models. The community edition is free to use and is supported through the community and the documentation, so the internal team or a partner carries the operational responsibility. Nextcloud Enterprise is a paid subscription sold in Standard, Premium and Ultimate tiers, with a 100-user minimum. Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support. Ultimate adds support up to 24/7 with response times down to one hour. Pricing and tier details change, so confirm current terms on the pricing page before comparing options. Enterprise support does not remove the need for the team to back up, test and schedule upgrades.
Before a quote is agreed, the reader should confirm five things: the current installed major and the target major, the list of third-party apps and their vendor support status, the database and PHP versions in use and whether they match the target requirements, the maintenance window available each month, and whether the Enterprise support model is needed for the internal service level. A written scope should state which upgrades are included, how many test runs are planned, who takes the backup and restore test, and what happens if an app blocks the move. These answers determine the work, and they show whether an in-house team can run the cadence alone.
What do Nextcloud upgrade and support engagements include?
Upgrade and support work on Nextcloud follows one sequence: establish what is running, plan a path that never skips a major release, rehearse, change production, then keep the instance patched. Each package below ends with a named deliverable, and the scope is fixed in writing before work starts, with ongoing support available as a retainer.
Current-state assessment
Record the Nextcloud version, PHP version, database engine and version, web server, installed apps, and data volume in the data directory and any object storage. Compare these against the Nextcloud 35 system requirements and note anything unsupported. The deliverable is an inventory that the upgrade plan is built from, so gaps found here do not surface mid-upgrade.
Upgrade path plan
Nextcloud does not allow skipping major releases, so the plan lists every intermediate major version between the current release and the target, with the order and checkpoints for each step. It also sets the backup point before each step and the rollback criteria. The deliverable is a written plan the client approves before any change.
Staging rehearsal
Restore a copy of production data, config and database into a staging environment and run each planned upgrade step there first. Time each step and record every error or warning, so production work is not the first test. Confirm that third-party apps are disabled during the rehearsal and re-enabled only after a compatibility decision. The deliverable is a test record.
App compatibility review
Check each installed app against the target major version, including custom apps and apps that integrate with LDAP, SSO, or external storage. Decide for each app whether to keep, update, replace, or remove it, and record the owner who signs off. Apps that are not confirmed compatible stay disabled until that decision is made. The deliverable is a compatibility register.
Production upgrade with rollback
Enable maintenance mode, take a consistent backup of the database, configuration and data, then run each major step in the agreed order. Keep the rollback procedure tested and ready, with a defined point at which the team restores rather than continuing. The deliverable is a change log with timestamps, versions reached and any deviations from the plan.
Post-upgrade checks and runbook handover
Verify logins through the identity provider, sync clients, sharing, background jobs, previews, and app function against the test record. Then hand over a runbook covering the maintenance release routine, backup verification, and the next major upgrade date from the release schedule. Support then runs on a monthly calendar of maintenance releases, which can be placed under a retainer.
What makes a Nextcloud upgrade take longer or cost more?
This table lists the factors that most change how much work a Nextcloud upgrade involves, why each one matters, and what the owner can do to keep it under control. Read the drivers together, because several of them compound: a long version gap with many unverified apps is far more work than either factor alone.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of major versions between current and target | Nextcloud does not allow skipping majors, so each major is a separate upgrade step with its own testing, backup and rollback point. | Upgrade on a steady cadence rather than letting the installation fall behind. Confirm the supported path with the upgrade manual before planning. |
| Installed third-party apps without confirmed compatibility | Apps are disabled until they are confirmed compatible with the target version, and unmaintained apps may block a step entirely. | Remove apps nobody uses, replace abandoned ones, and record the compatibility status of every remaining app for each target major. |
| Database engine and version | Each major lists supported database versions. An unsupported or end-of-life database must be upgraded first, adding a separate change window. | Pin a database version that the target release lists as supported, and check the system requirements for each step ahead of time. |
| Custom code, theming and custom apps | Custom apps, template overrides and theme changes can break on internal API or template changes and need code review and retesting. | Keep customizations minimal and documented, prefer supported extension points, and keep custom code in version control. |
| User count and data volume | Larger instances take longer to run database migrations and background tasks, and the window for maintenance mode grows with them. | Measure the current run time in staging, clear unneeded data and old trash or versions where policy allows, and schedule the window with users informed. |
| Number of environments (production, staging, DR) | Each environment needs its own upgrade, test and verification pass. A staging system that differs from production hides problems until the live upgrade. | Keep staging close to production in version, database, apps and configuration, and upgrade staging first in every step. |
| Integrations such as LDAP, SSO, Office or external storage | Each integration has its own configuration and test cases. Identity and storage connections often need retesting after every major, and Office servers may need version alignment. | Document each integration with its settings, owner and test steps, and include login, sync and document editing checks in every upgrade test plan. |
| Compliance evidence requirements | Assessors may ask for change records, test results, backup proof and approval trails for each upgrade, which adds documentation work to every step. | Use a standard change template, store test results and backup verification with each change, and confirm the evidence format with your assessor in advance. |
| Support model and maintenance lifecycle | Community releases are supported for a limited period, and the plan you choose determines who answers questions when an upgrade fails. Confirm current terms on the Nextcloud pricing page. | Decide before the upgrade window who will handle escalations, and check how long the chosen support tier covers the version you run. |
How a Nextcloud upgrade project moves from assessment to handover
The sequence turns an aging or unsupported Nextcloud server into a planned, verified upgrade with rehearsed steps, tested backups and a maintenance calendar the client's team can run after the engagement ends. Each phase produces a written artifact that the next phase depends on.
Inventory the current installation and its apps
DeployOpen reviews the running Nextcloud version, PHP and database versions, web server, server configuration, user and group counts, storage backends, external integrations and every installed app, including third-party apps. The team confirms how the installation is deployed and which components are managed by the client's platform team. The output is a written inventory with a compatibility list for each app and component, reviewed with the client's administrators. The step is done when every installed app is marked as bundled, supported by its vendor, unmaintained or unknown, and the client has signed off on the list.
Design the upgrade path one major at a time
Nextcloud does not allow skipping major releases, so the plan lists every intermediate major version between the current release and the target. The target is set from the release and end-of-life dates confirmed in the Nextcloud maintenance schedule on the day the work is scoped, because the next target major depends on which releases are current at that time. The plan also records required PHP and database versions for each step, app compatibility decisions, and the points where the client must approve a go or no-go. The output is a sequenced upgrade plan that names each major, its prerequisites and its rollback point.
Verify backups and test a full restore
Before any change, the data directory or object storage, the database, the configuration files and the app list are backed up in a consistent state, with maintenance mode used during the backup window. DeployOpen then restores a copy into an isolated environment and checks that files open, shares resolve, users can log in and the database schema matches the backup. The output is a backup record and a restore test report listing what was restored, what was checked and any gaps. The step closes only when the client accepts the restore evidence as sufficient for rollback.
Rehearse each upgrade in staging
A staging copy is built from the production backup, with production data, app versions and configuration. Each major step in the upgrade plan runs in staging in order, with third-party apps disabled until their compatibility is confirmed. After each step, the team runs the upgrade command, reviews the output, and checks logins, sharing, sync client connections, background jobs and any integrations such as LDAP, Office or Talk. Problems are logged with a fix or a decision to defer the app. The output is a runbook with the exact commands, expected results, timings observed in staging and the app checks that passed or failed.
Execute the production change window
The production upgrade follows the rehearsed runbook without deviation unless a documented stop condition is met. Before the window opens, the client confirms the backup, the rollback procedure and the people on call. During the window, maintenance mode is enabled, each major step is applied in order, third-party apps are re-enabled only after their checks pass, and maintenance mode is turned off once the login and sync checks succeed. The output is a change record showing each step, the time it completed, the checks run and any deviation from the runbook. The step closes when the client accepts the change record.
Confirm post-upgrade health and monitoring
After the window, DeployOpen runs a verification pass covering admin overview warnings, the integrity check, background job execution, cron status, file locking, error logs, sync client connectivity and a sample of user workflows. Monitoring for web server errors, PHP errors, database health and storage capacity is confirmed or configured, and alert recipients are named by the client. The output is a post-upgrade verification report with any open items and owners assigned. The step is done when the report shows no unresolved critical findings and monitoring is confirmed to be reporting.
Hand over the runbook and maintenance calendar
The engagement closes with a handover package: the final configuration record, the updated inventory, the backup and restore procedure, the upgrade runbook, and a maintenance calendar. The calendar lists the next monthly maintenance releases to apply, the upcoming major versions, and their release and end-of-life dates as confirmed in the Nextcloud maintenance schedule at handover, with a review date for each. The client's team walks through the calendar and the rollback steps with DeployOpen. The output is a signed handover record. Ongoing maintenance, upgrades and support can then be covered by the client's team or a separate retainer.
Why Nextcloud upgrades must go one major version at a time
Nextcloud does not allow skipping major releases, so a server that is several majors behind cannot jump to the current version in a single step. The upgrade path has to run through each intervening major in order, with a check and a stable run at every stop before the next upgrade begins. For planning, this means the number of majors between the installed version and the target is a direct driver of effort, because each stop needs its own backup, compatibility review, upgrade, and verification. Ask any partner to show the full path as a numbered sequence of majors, not a single target version. The upgrade documentation sets three rules that every stop must follow. First, take a backup before every upgrade, covering the data directory or object storage, the database, and the config directory, so that each step can be reversed independently. Second, disable third-party apps until each one is confirmed compatible with the target major, since apps are the most common source of failed upgrades. Third, upgrade one major at a time. Teams should write these rules into the change record and confirm that the backup restore has been tested, not only taken. Between majors, the server also needs the monthly maintenance releases. Nextcloud publishes a new major every four months and supports each one for a year through these releases, which address known critical bugs and security problems. A server that skips maintenance releases between majors carries known vulnerabilities into the next upgrade, and the upgrade itself is then built on an unpatched base. Plan a recurring window for maintenance releases in addition to the major upgrade windows, and keep the patch level of each stop recorded. Support windows move, so do not plan from memory. Nextcloud 35 is listed with end of life in September 2027, Nextcloud 34 is supported until June 2027, Nextcloud 33 until February 2027, and Nextcloud 36 is scheduled for 17 February 2027. Check the maintenance and release schedule on the day you plan, because these dates can change. Any upgrade path should be timed so that the target major is still supported when the work finishes, with margin for testing. The practical decision is when to start the path and how many stops it needs. Ask for a written list of the majors between your current version and the target, the compatibility check for each installed app, the backup and restore test for each step, and the window reserved for maintenance releases. A quote that shows only one upgrade event is likely to understate the work.
What goes wrong in Nextcloud upgrades and how to prevent it
Most failed Nextcloud upgrades trace back to a short list of causes: version gaps, unchecked apps, missing prerequisites, and untested recovery. Each card names one failure, the step that prevents it, and what to verify before and after the upgrade.
Skipped major versions
Nextcloud does not allow skipping major releases, so a server several majors behind must move one major at a time. Plan the upgrade path from the current version to a supported target before touching production. Verify the installed version in the admin overview and confirm each intermediate step completes and passes basic file and login checks before the next.
Apps disabled without notice
Third-party apps that are not yet compatible with a new major can be disabled or break after the upgrade, sometimes without an obvious error. Inventory every installed app and its version, and confirm compatibility with the target release before starting. After the upgrade, check the apps page and the server log for disabled or failing apps and assign an owner to each one.
Database and PHP below requirements
Each major release sets minimum and recommended versions for the database, PHP and web server. An upgrade onto a target that expects newer components can fail partway or leave the instance unstable. Compare the current MariaDB or PostgreSQL, PHP and web server versions against the target's system requirements, and schedule any component upgrades as separate, tested changes.
Backups never restored
A backup that has never been restored is an assumption, not a recovery plan. Nextcloud needs the data directory or object storage, the database and the configuration backed up consistently at the same point. Restore the backup to a separate environment before the upgrade, confirm files, shares and users are intact, and record how long the restore took.
Upgrades run without maintenance mode
Running the upgrade while users are active risks writes to files and the database during schema changes, which can corrupt data or leave the instance half-migrated. Enable maintenance mode before the upgrade, announce the window to users, and disable it only after the upgrade and checks finish. Confirm the maintenance flag is off once the work is complete.
Background jobs and cron left unconfigured
Nextcloud relies on background jobs for tasks such as file scanning, notifications and cleanup. If cron is not set up, or runs under AJAX mode, these tasks stall after the upgrade and performance degrades slowly. Set background jobs to system cron, confirm the cron user can run the Nextcloud command, and check the last job run time in the admin overview after the upgrade.
Custom code and theming breaking
Custom themes, scripts, overridden templates and direct edits to core files often depend on internal behavior that changes between majors. These changes may pass testing on the old version and fail silently afterward. Keep customizations in supported extension points, record each one in a change register, and retest branding and integrations on a staging copy before production.
Clients left on old versions
Desktop and mobile clients that predate the new server may fail to sync, authenticate or show errors to users after the server moves. Identify client versions in use, set a minimum supported client version, and communicate the update path before the server upgrade. Verify a sample of each platform syncs and logs in against the upgraded server.
End of life passing without a plan
Each major receives maintenance releases for about one year, after which security fixes stop. An organization that delays upgrades can drift onto an unsupported release without a decision or budget for the next step. Track the end-of-life date for the installed major in the maintenance schedule, set an upgrade window well before it, and confirm who approves the change.
What does Nextcloud support cost after go-live?
This table compares the vendor support tiers with the recurring operating costs that remain after go-live, so you can see what a subscription covers and what your own team or partner still pays for. Read the Enterprise rows against the community row, then the operating rows, to build a full annual figure. The main takeaway is that the subscription is only one line of the total, and maintenance labor and infrastructure often matter as much.
| Cost item | What it covers | Cost driver and what to request in a quote |
|---|---|---|
| Community support | No vendor subscription. Maintenance releases come from the open source project, and your internal team or a partner handles upgrades, troubleshooting and monitoring. | Labor is the main cost. Ask the partner to estimate monthly release effort, upgrade effort per major version and the hours reserved for incident response. |
| Enterprise Standard | One-year maintenance and support. List price starts at 71.29 euros per user per year for 100 or more users, with a 100-user minimum, according to Nextcloud's pricing page. | Per-user pricing with lower rates from 200 users. Confirm the user count, tier, currency and whether the quote is list or discounted, and what renews annually. |
| Enterprise Premium | Maintenance lifecycle of five or more years, extended support hours and clustered instance support. List price starts at 104.99 euros per user per year for 100 or more users, according to Nextcloud's pricing page. | Choose Premium when you need clustered support or a longer lifecycle than one year. Ask whether clustered support applies to your planned high availability design. |
| Enterprise Ultimate | Support up to 24/7 with response times down to one hour. List price starts at 204.75 euros per user per year for 100 or more users, according to Nextcloud's pricing page. | Compare the response-time commitment with your own on-call model. Ask for the exact support hours, severity definitions and how response time is measured. |
| Hosting and infrastructure | Compute for app servers, database, Redis, reverse proxy and any object storage, in your cloud account or data center. This cost runs whether or not you buy a subscription. | Sized by user count, file volume and peak concurrency. Ask the implementer to state the assumed sizing and what changes if user count grows. |
| Monitoring and logging | Metrics, uptime checks, log retention and alerting on PHP-FPM, database, cron jobs and storage. Recurs as tooling and storage charges. | Driven by retention period and number of components monitored. Confirm who owns alert response and which tooling is already licensed. |
| Backup storage | Storage and retention for database dumps, data directory or object storage copies and configuration. Restore testing time is a separate recurring task. | Grows with data volume and retention policy. Ask for the backup schedule, retention periods and the cost of a periodic restore test. |
| Staff time for monthly releases | Applying monthly maintenance releases, checking the changelog, testing and scheduling maintenance windows. | Frequency is set by Nextcloud's monthly maintenance cycle. Ask for the hours per release, test environment requirements and rollback steps. |
| App review | Checking third-party apps for compatibility before each upgrade, and reviewing app updates and security advisories. | Grows with the number of installed apps. Ask how many apps are in scope and whether unsupported apps will be removed or replaced. |
| Retainer for upgrades | Planned work to move one major version at a time, with backups before each step, compatibility checks and post-upgrade verification. | Each major version requires its own upgrade cycle. Ask for the number of upgrades covered per year, what is excluded and how out-of-cycle emergency work is billed. |
How the upgrade work changes by starting point
A self-managed community server with many installed apps usually carries the most compatibility work. Each third-party app must be confirmed for the target major before the core upgrade starts, so planning for this group centers on inventory and app decisions as much as on the core update.
- App inventory: list every enabled and disabled app, its source, its maintainer and its installed version, including any app copied by hand into the apps directory.
- Compatibility decisions: Nextcloud's upgrade guidance is to disable third-party apps until they are confirmed compatible, so decide for each app whether it is kept, replaced or removed at every step.
- Business owners: assign an owner for each business-critical app who can test workflows such as shares, Talk or external storage after each step.
- Custom code: review customizations and integrations built on WebDAV or the APIs, since changes between majors can break them.
Confirm with each app maintainer which versions support your target major, and record the answers before you schedule the first step.
A server on an older major cannot jump straight to the current release. Nextcloud does not allow skipping major releases, so the plan becomes a sequence of single-major upgrades, and each step needs its own backup, test and rollback point.
- Path length: count the majors between your current version and the target, then record the support status of each intermediate major from the maintenance and release schedule.
- Support windows: check whether each intermediate major still receives monthly maintenance releases. For example, Nextcloud 33 is supported until February 2027 and Nextcloud 34 until June 2027.
- Requirements per step: check the PHP, database and web server versions at each stop, because the supported versions change from one major to the next.
- Backups: take a full backup before every step, not only before the first one.
- Schedule: avoid timing the final step close to the end-of-life date of the target major, and allow time to clear any app issues found at each stop.
Confirm the full sequence with Nextcloud's upgrade documentation and your own app inventory before you approve a change window.
Moving from the community edition to Enterprise changes who answers upgrade questions and how long a major receives maintenance. It does not remove the need for compatibility checks, and the subscription should be timed around your upgrade plan. Nextcloud GmbH sells Enterprise in Standard, Premium and Ultimate tiers, with a 100-user minimum.
- Tier fit: according to Nextcloud's pricing page, Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years with extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour.
- Pricing basis: list prices start at 71.29, 104.99 and 204.75 euros per user per year for Standard, Premium and Ultimate respectively, for 100 or more users, with lower rates from 200 users. Ask for a quote based on your user count.
- Coverage timing: confirm with Nextcloud when coverage starts and whether it applies to the major you are upgrading to.
- Installation path: confirm how the Enterprise package is installed on your existing server and whether any apps or configuration need to change.
- Ticket path: confirm who opens support tickets, which hours are covered and whether upgrade assistance is part of the subscription.
Confirm these terms in writing with Nextcloud before you change support tiers, because the upgrade schedule should follow the coverage start date.
Packaged installs move part of the upgrade path into the packaging layer. Nextcloud All-in-One bundles the server with supporting services, and the Helm chart handles Kubernetes deployments, so the plan follows the packaging version as well as the Nextcloud release.
- Version mapping: for All-in-One, confirm which Nextcloud major each release installs and whether its update path respects the one-major-at-a-time rule. For Kubernetes, confirm how each chart version maps to Nextcloud versions and how major upgrades are triggered.
- Bundled services: list the components the packaging updates, such as the database, Redis, APCu, Office, Talk and ClamAV, and list the parts you still update yourself, such as the reverse proxy.
- Backups: All-in-One includes BorgBackup-based backups. Confirm the backup job completes and test a restore before the upgrade starts.
- External services: for Kubernetes, confirm that external database and Redis settings carry over through the chart upgrade, and that background jobs and storage configuration are unchanged.
- Customization: check any changes made to container definitions or chart values, since upgrades can overwrite them.
Confirm these points against the release notes for your specific All-in-One or chart version before you run the first upgrade in a test environment.
In an air-gapped network, the upgrade cannot pull packages, containers or documentation from the internet at upgrade time. Everything needed for each step must be brought in through the approved transfer process, checked and recorded before it is used.
- Transfer inventory: list the server archive, app packages, container images or chart archives, and the PHP, database and web server packages needed for each step.
- Documentation set: keep copies of the upgrade manual and the release schedule, dated to the version you transfer, so the change record shows what guidance the team followed.
- Dependency availability: confirm that the PHP, database and web server packages required by each target major are available inside the enclave, because requirements change between majors.
- App updates: app updates need the same transfer, approval and compatibility checks as the core release, and each file needs a named approver.
- Integrity checks: verify checksums or signatures against values published by the vendor, and store the results with the change record.
Confirm the approved transfer route, the approval steps and the lead time for each transfer with your security team before you plan the upgrade window.
What the client must provide before a Nextcloud upgrade begins
The fastest way to shorten a Nextcloud upgrade is to have the client's inputs ready before the first maintenance window is booked. Nextcloud does not allow skipping major releases, so an upgrade is usually a sequence of steps, each one needing access, a recent backup and a compatibility check. If DeployOpen or the internal team has to chase these inputs mid-project, the sequence stalls. Start by confirming four access items: administrator access to the Nextcloud server itself, the database server, the web server (Apache or nginx with php-fpm), and the hosting platform where snapshots and firewall rules are managed. Confirm also who holds the root or sudo credentials and whether that person is available during the agreed windows. Next, provide a current inventory of installed apps, with a named owner for each one. Third-party apps are the most common cause of a blocked upgrade, because Nextcloud's guidance is to disable them until they are confirmed compatible with the target major version. An inventory that lists app name, version, install source, the group that uses it and the business owner lets the team test compatibility in one pass instead of discovering breakage app by app. Pair that inventory with a written decision for each app: keep, remove, or replace, and who approves that change. Without those decisions, the team cannot tell whether a failing app is a defect to fix or a feature the business has already agreed to drop. The backup location and a tested restore path are the most important inputs in the list. Nextcloud's upgrade process expects a backup before every upgrade, and that backup must cover the data directory or object storage, the database and the configuration. Ask the client to name where backups are stored, how long they are retained, and who can restore them. A backup that has never been restored in a test is a hope, not a rollback plan. Confirm the restore test was performed on a separate host, and record the date and the person who ran it. The remaining inputs are about people and records. Provide a change calendar that marks business freeze windows, such as month-end close, exam periods or school enrollment, so the upgrade is not scheduled into them. Name the owner who approves each change and a separate owner who speaks for affected users, so user notices and go or no-go calls do not depend on one person. Finally, document how LDAP or Active Directory, SSO and external storage are configured, including bind accounts, group filters, OIDC or SAML settings and mount definitions. These integrations are the places where an upgrade most often changes behavior unexpectedly. If this documentation is missing, the team must reverse-engineer it from a live server, which adds time and raises the risk of an incorrect change. Ask the client to treat each of these items as a closed deliverable before the project plan is signed.
Questions buyers ask about Nextcloud upgrades and support
How much does Nextcloud support cost?
Support cost depends on the edition, the number of users and the level of support you need. Nextcloud GmbH publishes list prices for Nextcloud Enterprise on its pricing page: Standard, Premium and Ultimate start at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users. Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Those are vendor subscription costs. Separately, you pay for infrastructure, administration time and any partner work such as upgrade planning or app review. Ask any partner for a quote that lists each of these items separately and states what recurs each year and what is one-time.
How long does a Nextcloud major upgrade take?
The duration depends on how many major versions you must cross, how many third-party apps you run, the size of your database and data directory, and the maintenance window you can get. Nextcloud does not allow skipping majors, so an installation several versions behind needs one upgrade per major, each with its own backup, compatibility check and verification. Large data directories and big databases lengthen the migration steps, and every disabled or updated app adds testing time. Confirm the expected steps and window with your administrator or partner against a copy of your production instance before you commit to a date, because no general duration applies to every environment.
Can our own team upgrade Nextcloud without a partner?
Yes, if your team has the skills and the window to do it safely. You need Linux administration, web server and PHP-FPM knowledge, database administration for your chosen engine (MariaDB, PostgreSQL or MySQL), backup and restore experience, and the ability to use the occ command-line tool and read upgrade logs. You also need someone who can review each installed app for compatibility, a staging environment that mirrors production, and a documented rollback plan. Teams that lack one of these areas usually benefit from a partner for planning, app review or runbooks, while keeping day-to-day operation in-house.
What does an upgrade need from our organization?
An upgrade needs decisions and access from several groups. Your business owners need to approve a maintenance window and accept a read-only or downtime period. Your IT team must provide server or cluster access, database credentials, backup storage with restore capability, and a staging copy of the instance. Application owners need to confirm which third-party apps are business critical and test them after the upgrade. Your security team should review the target version and any changed configuration. You also need a list of current versions for PHP, the database and the web server, so you can confirm them against the requirements of the target major before starting.
Does Nextcloud Enterprise support remove the need for a partner?
No. Enterprise support covers the vendor's help with the Nextcloud server and its supported components, subject to the tier you buy. It does not review the third-party apps in your environment, write your upgrade runbook, test your integrations with identity, storage or backup systems, or carry out the work in your infrastructure. Those tasks remain with your team or a partner. Ask the vendor exactly which apps and configurations are in scope for support, and ask a partner to document which parts of the upgrade are covered by your own staff and which are covered by the vendor.
How often must we upgrade Nextcloud?
Nextcloud publishes a new major version every four months and supports each major for one year, with monthly maintenance releases for critical bugs and security problems. That means a major version falls out of support about a year after release, so an installation that falls behind will leave support. Because upgrades must go one major at a time, a plan that tracks the release schedule is easier to run than a large catch-up project. Review the maintenance and release schedule published by Nextcloud, and plan a standing cadence for applying monthly maintenance releases as well as the major upgrades.
What happens to users and apps during an upgrade?
During the upgrade, the instance is normally put into maintenance mode, so users cannot sign in or sync until the process completes. Third-party apps are usually disabled until they are confirmed compatible with the target version, which means some features may be unavailable for a period. Background jobs and sync clients may show errors while the instance is offline. After the upgrade, you should check that files, shares and user accounts behave as expected, re-enable apps one at a time, and confirm that identity and storage integrations still work. Plan a communication to users about the window and the features that will be temporarily unavailable.
How DeployOpen scopes, delivers and hands over Nextcloud upgrades
DeployOpen plans, performs and documents Nextcloud upgrades inside your own infrastructure, one major version at a time. Engagements are fixed-scope, with the work, deliverables and timeline agreed in writing before changes start, and ongoing support is available as a retainer.
How we scope
- Inventory the current Nextcloud version, database, PHP, web server and every installed app against the target major version.
- Agree the upgrade path step by step, since major releases cannot be skipped and each step needs its own checks.
- Confirm in writing which environments, maintenance windows, rollback points and app decisions are included in the fixed scope.
How we build
- Run each major step in a staging copy with production-like data, then record which third-party apps need updating, replacing or disabling.
- Take and verify a backup before every upgrade step, covering the data directory or object storage, the database and the configuration.
- Test log in with your identity provider, sharing, client sync and key apps such as Office or Talk before approving each step for production.
How we hand over
- Deliver a runbook with the exact upgrade steps, commands, rollback procedure and post-upgrade checks used for your environment.
- Document the app compatibility decisions, pinned versions and any local changes so future upgrades start from a known state.
- Walk your administrators through the procedure and leave them with a dated record of each major version applied and tested.
How we support
- Agree a retainer that covers monitoring of Nextcloud maintenance releases, scheduled patching and planning for the next major version.
- Set a review cadence for the four-month major release cycle and the one-year support window for each major version.
- Confirm with Nextcloud whether your needs call for Enterprise maintenance tiers, since its support levels differ from the community edition.
