Why Nextcloud customization needs a plan before the first change
Customization is a build-and-maintain effort, and its main risk is breakage at the next upgrade. Teams often keep small branding and configuration work in-house, and bring in a partner for custom apps, integrations and upgrade testing. The decision about who owns which part should be made before the first theme file is edited or the first app is installed. The usual starting point is a Nextcloud instance that is already live and in use. The organization then wants a logo and color scheme, a list of approved apps, automated workflows, or links to a line-of-business system such as a document management platform, an HR system or a case tool. Each of these changes touches code or settings that Nextcloud does not promise to keep stable across major releases. A change that looks cosmetic can still depend on internal templates or styles that move in the next version.
Several events tend to trigger a customization project. A new department joins with its own folder structure and approval rules. An acquisition brings a second company's branding and identity requirements. A regulated file workflow, such as a records approval step or a restricted sharing path, needs automation that the standard interface does not provide. Replacing an old file share also creates pressure to recreate its behavior inside Nextcloud. In each case the request arrives as a feature, but it is really a new piece of the platform that someone must test on every upgrade.
Before the first change, ask who will own each item after go-live. Map every planned change to a component: theming files, installed apps, Flow rules, custom app code, or an integration through WebDAV or the APIs. For each one, record the owner, the test that proves it still works after a maintenance release, and what happens if a third-party app is disabled during a major upgrade. Nextcloud's upgrade guidance asks administrators to back up before every upgrade, to move one major version at a time, and to disable third-party apps until they are confirmed compatible. Those steps apply to your customizations as much as to the base platform. Ignore the idea that customization ends when the project closes. Each new major release, supported for one year through monthly maintenance releases, requires a fresh check of every custom element. Confirm with your team who will run that check, how much time it is allowed in the release calendar, and whether a support agreement covers the custom code. Put those answers in writing before the first change, because they determine whether customization stays an asset or becomes the reason an upgrade is postponed.
What a Nextcloud customization engagement includes
A customization engagement changes how Nextcloud looks, behaves and connects to other systems, and each change carries upgrade risk. The work below is grouped so that every package has a clear owner, a test path and a place in the upgrade runbook. Scope is agreed in writing before work starts, so the boundaries of each package are visible to both sides before any code or configuration changes.
Theming and branding
This package covers the logo, color palette, login page, mail templates and, where the client uses them, desktop and mobile client branding. Theming is applied through the supported theming configuration rather than by editing core templates, which keeps changes separable from server code. Check which client platforms the organization needs branded, because each one is a separate build and test target, and confirm who approves brand assets before work starts.
App selection and governance
This package defines how apps are vetted, which ones go on an approved list and who may install them. Each candidate app is checked for maintainer activity, compatibility with the target Nextcloud major version, its declared permissions and its data access. The install policy written in this package decides whether users, administrators or only the platform team can add apps, and it is the control that stops untested third-party code from reaching production during an upgrade.
Flow automation rules
This package designs the Flow rules that trigger on file, share or user events, such as tagging uploads, moving files between folders or notifying owners when a share is created. Each rule is documented with its trigger, condition, action and owner, because undocumented automations are a common source of surprises after an upgrade. Confirm which events each rule depends on and test them against the version the organization runs.
Custom app development
Where a requirement cannot be met by configuration or an existing app, custom development uses the supported app API and its documented extension points. The work includes an app manifest, declared dependencies, automated tests and a defined support boundary. Ask how the app will be maintained after handover, since an app built against one major version needs review and possibly changes before the next upgrade.
Integrations through WebDAV and OCS
This package connects Nextcloud to other systems through WebDAV for file access and the OCS API for users, shares and capabilities, along with other documented APIs where needed. Each integration defines its service account, its permission scope, its rate expectations and how failures are logged and retried. Check that every endpoint used is documented for the target version, and record the version that was tested so that breaking changes are caught during the upgrade test.
Deliverables and handover
Every engagement ends with a customization register that lists each change, its owner and its upgrade impact, plus a source repository with version control history. Test cases cover the branding, app, Flow and integration behavior, and an upgrade runbook sets out the order of steps, the backup point and the rollback path for each major upgrade. Handover notes explain support boundaries, the process for approving new apps and the checks to run before disabling third-party apps during an upgrade.
What drives customization cost and duration
This table lists the factors that most change the size of a Nextcloud customization quote, why each one matters and how to keep it under control. Each driver should be written into the fixed-scope quote with an explicit boundary, so that changes in scope are visible before work starts.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number and depth of custom apps | Each custom app adds code to build, test, document and maintain across every Nextcloud major release, and deeper apps touch internal APIs that change between versions. | Limit custom apps to features that cannot be met by approved apps or Flow, and agree the number of apps and their functional boundaries in writing. |
| Integrations and external systems | Each system adds authentication, data mapping, error handling and test cases, and each one needs access credentials and a named owner on the client side. | Prioritize integrations by business need, use WebDAV or documented APIs where possible, and agree which systems are in phase one. |
| Theming beyond supported settings | Changes to CSS or templates can break with each release and need regression checks on every upgrade, while settings-based branding usually survives upgrades. | Keep branding within supported theming settings where possible, and confirm in the quote which CSS or template overrides are included and who maintains them. |
| Number of environments | Development, staging and production each need deployment, data handling and testing effort, and the staging copy must match production closely to validate upgrades. | Agree in the quote how many environments are built, whether staging uses sanitized data, and how environments are refreshed. |
| Third-party apps needing review | Each app from the app store or elsewhere needs compatibility checks against the target version and a security review before it is approved for production. | Shortlist apps early, limit the approved list, and ask the partner to state the review steps and the number of apps covered by the fixed scope. |
| Compliance evidence required | Assessors may expect change records, test results, access reviews and documented configuration, and producing that evidence adds effort to each change. | Define the evidence set up front, such as change tickets and test records, and reuse templates so that evidence is produced as part of normal delivery. |
| Edition and support level | Nextcloud Enterprise tiers differ in maintenance length, support hours and response times, which affects who handles upgrade and incident work and how much DeployOpen or the client team must cover. | Confirm the edition before scoping, record which support obligations sit with Nextcloud and which sit with the implementation partner, and ask for the support model in the quote. |
How customization stays upgrade-safe on a four-month release cycle
Every Nextcloud customization is an upgrade decision, and the reason is the release rhythm. Nextcloud publishes a new major version every four months and supports each major for one year through monthly maintenance releases that address known critical bugs and security problems. A theme, a Flow rule, a custom app or an integration that works today may stop working at the next major. Administrators cannot skip majors either. Each upgrade moves one major version at a time, so a deployment that falls behind must cross every intermediate release, each with its own compatibility checks.
Because of this, three rules govern every upgrade. Back up before every upgrade so a failed step can be reversed. Disable third-party apps until they are confirmed compatible with the target major, then re-enable them one at a time. Treat the list of customizations as a living inventory that names each theme, app, script and integration, its owner, and the Nextcloud version it was last tested on. Without that inventory, the team cannot tell which change caused a failure after an upgrade.
Design choices reduce how much breaks. Prefer documented extension points and public APIs over editing core files or templates in the server code. A change to a core file is overwritten or conflicts on the next upgrade, while a documented hook or app-level setting usually survives. Where branding requires template-level changes, keep the list of overridden files short and record each one in the inventory. Keep custom code, theme files and Flow configuration exports in version control, and keep that code separate from the data directory, which holds user files and should never be used as a code location. Repository history then shows exactly what changed between majors.
Pin and test app versions rather than accepting whatever the app store offers on the day of an upgrade. Record the version of each app in the inventory, test the target combination on a staging copy of the instance, and only then approve the change for production. Confirm each app's stated compatibility range with its developer before you rely on it, because the range for an app is set by its maintainer, not by Nextcloud's release schedule.
Rehearse each major on a staging copy that matches production in server version, database, PHP version, app set and a recent copy of the data. Run the upgrade, then test login, sharing, sync clients, theming, Flow workflows and each integration against a written test list. Measure how long the rehearsal took so the production window can be planned. Before committing to a date, confirm the current release and end-of-life dates for each major in Nextcloud's maintenance and release schedule, because dates change and this page should not be the source for planning.
The phases of a customization project and the output of each
The sequence moves a Nextcloud customization from documented requirements to a tested, reversible change that your own team can upgrade later. Each phase ends with a named output so you can check progress before the next phase begins.
Discover requirements and current customizations
DeployOpen reviews the business needs, the existing server, installed apps, theme files, custom code, Flow workflows, and any integrations that call WebDAV or the Nextcloud APIs. Your administrators and the owners of each workflow confirm what must change and what must stay. The output is a requirements register and an inventory of every current customization, with the version it depends on and who owns it. The step is complete when your team has signed off the inventory and the list of in-scope changes.
Design extension boundaries and app governance
DeployOpen decides which changes belong in configuration, theming, Flow rules or a custom app, and which should not be built at all. The design sets extension boundaries, such as avoiding edits to core files, and defines an app governance policy covering who may request, vet and approve apps, and how apps are retired. Your security and identity owners review the design, particularly any app that touches authentication, sharing or external storage. The output is a written design document and an approved governance policy. The step is complete when both are accepted in writing.
Build in a development environment with code review
DeployOpen builds the approved changes in a development environment that matches your production server version, database and PHP setup. Custom code is kept in version control, follows the Nextcloud app APIs rather than patching core, and goes through peer review before merge. Configuration and theme assets are packaged so they can be reapplied on a clean install. The output is a versioned build, a reviewed change log, and a repeatable install script or playbook. The step is complete when every change has a recorded reviewer and can be deployed from source.
Test and rehearse the upgrade on a staging copy
DeployOpen deploys the build to a staging copy of production, including a restored database and data directory sample, and runs functional, permission and integration tests. Because Nextcloud requires one major version at a time and third-party apps must be confirmed before an upgrade, the staging copy is also upgraded to the next supported major release to rehearse the change, with each custom app checked for compatibility. Findings are logged and fixed before go-live. The output is a test report and an upgrade rehearsal record listing each app and its result. The step is complete when your team accepts the results.
Deploy under change control with a rollback plan
DeployOpen schedules the production change with your change board and runs a fresh backup of the database, data directory and configuration immediately before deployment. Maintenance mode is enabled for the change window, and the rollback plan defines the exact steps, data restore points and the decision criteria for reverting. Deployment is followed by smoke tests on login, sharing, sync clients and each custom feature. The output is a deployment record, validated backups, and a signed rollback plan. The step is complete when the smoke tests pass and maintenance mode is lifted.
Hand over documentation and an upgrade runbook
DeployOpen transfers the source code, build scripts, configuration inventory and governance policy to your team, and walks administrators through the customizations and how they behave under maintenance releases. The upgrade runbook describes the procedure for each future major version, including backup, disabling third-party apps until compatibility is confirmed, the compatibility checks, and the rollback path. Your team runs a supervised dry run of part of the procedure where agreed. The output is the documentation set and a runbook your team can execute. The step is complete when your administrators have demonstrated the procedure.
What usually goes wrong with Nextcloud customization and how to prevent it
Most Nextcloud customization problems do not show up when the change is made. They surface later, during a major upgrade, a rushed app update or a staff change, when nobody remembers why a setting exists. The cards below cover the failure modes we see most often and the controls that keep customization supportable across releases.
Custom code breaks after a major upgrade
Custom apps, server-side patches and scripts that call internal APIs can stop working when a new major version changes those interfaces. Nextcloud releases a new major version every four months, and administrators must move through them one at a time. Prevent this by keeping all custom code in version control, pinning dependencies, and rehearsing each major upgrade on a staging copy before production.
Third-party app blocks the upgrade
An installed app that has not been confirmed compatible with the target version can stop an upgrade or leave the instance in a broken state. Nextcloud's upgrade guidance is to disable third-party apps until they are confirmed compatible, so an app left enabled by default is a common cause of failed upgrades. Prevent this with a governance list that records each app's version, owner and compatibility status, and with a pre-upgrade check that disables anything not on the approved list.
Theme changes lost after an update
Branding changes made by editing core files or templates directly are overwritten or misaligned when Nextcloud is updated. Logos, colors and login pages then revert or break without warning, often discovered by users first. Prevent this by limiting branding to supported theming settings and custom app files kept in source control, and by checking the login page and main navigation as part of every upgrade test.
Undocumented scripts owned by one person
Cron jobs, occ command wrappers, storage cleanup scripts and integration glue often exist only on the server and in one administrator's memory. When that person leaves or is unavailable, nobody can safely change or restore them during an incident. Prevent this by recording each script's purpose, schedule, owner, inputs and rollback steps in a runbook, and by assigning a named backup owner who has run each one at least once.
Flow rules conflict with sharing or retention
Flow automations can move, tag, share or delete files on a schedule or trigger, and they can act against sharing restrictions or retention rules the organization has set elsewhere. A rule that auto-shares a folder externally, for example, can bypass a policy that administrators believed was enforced. Prevent this by reviewing every Flow rule against the sharing and retention policy, restricting who can create rules, and testing each rule with a test account before enabling it for real users.
Integrations store credentials in plain text
Scripts and integrations that call WebDAV or the Nextcloud APIs often hold a personal user password or an app password in a configuration file or script. A departure or password reset then breaks the integration, and the credential exposes far more access than the integration needs. Prevent this by creating a dedicated service account with the minimum group membership, storing its secret in a managed secrets store, and rotating it on a documented schedule.
Apps installed from unvetted sources
Apps downloaded from unofficial archives, copied between servers or installed directly from a developer's repository can carry unreviewed code and unclear update paths. They may also be incompatible with the current release line, which makes later upgrades harder. Prevent this by installing apps only from the official app store or from source you have reviewed and built internally, and by recording each app's origin in the governance list.
Which customization work teams keep in-house and which they outsource
This table compares each part of Nextcloud customization by who usually owns it and which skills it needs. Read it as a split: policy and content tend to stay with the organization, while build and upgrade testing are where teams most often bring in a partner. The main takeaway is that the work that touches upgrades and custom code needs engineering skills that outlast the initial project.
| Work part | Usually in-house or outsourced | Skills required |
|---|---|---|
| Brand decisions and content | In-house. Marketing, communications or IT leads own the decisions, with the platform team applying them. | Brand guidelines, plain-language writing for login and onboarding text, and access to the approved logo and color assets. |
| App approval policy | In-house. Security and IT governance set which apps are allowed and who may request new ones. | Risk assessment of third-party apps, understanding of app permissions and data access, and a written review process. |
| Day-to-day Flow rule requests | Mostly in-house. A trained administrator handles routine rules, with a partner for complex automations. | Working knowledge of Nextcloud Flow triggers and actions, testing rules on a non-production instance, and documenting each rule's owner. |
| Custom app architecture and coding in PHP and JavaScript/TypeScript | Often outsourced for initial build. Teams keep ownership of the code and its repository after handover. | PHP for server-side app logic, JavaScript/TypeScript for front-end work, familiarity with Nextcloud app APIs and secure coding practices. |
| WebDAV and API integration design | Often outsourced for design, with in-house review of data flows and permissions. | WebDAV protocol behavior, OAuth or app token handling, rate and load planning, and understanding of how sharing permissions apply to API calls. |
| Upgrade rehearsal and app compatibility testing | Frequently shared. A partner often runs the rehearsal on a staging copy, while the internal team signs off on results. | Staging environment management, the one-major-version-at-a-time upgrade sequence, backup and restore practice, and test scripts covering each custom app. |
| Ongoing maintenance of custom code | Decide early. Many teams keep it in-house after handover or place it under a retainer. | Ability to read and update PHP and JavaScript/TypeScript code, track changes in Nextcloud APIs across releases, and keep dependencies current. |
What custom code costs after go-live
The build cost of a Nextcloud customization is paid once, but the work that keeps custom code running is recurring. Every custom theme file, app, Flow rule and WebDAV or API integration has to be checked against each new Nextcloud release before the upgrade reaches production. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases, so a team with custom components is testing against two cadences at once: the major release and the monthly maintenance releases that address critical bugs and security problems. Budget for that testing as a standing activity, not a one-off project phase.
Nextcloud's upgrade guidance is strict on this point. Major versions cannot be skipped, administrators must move one major version at a time, back up before every upgrade, and disable third-party apps until they are confirmed compatible. Each custom app you maintain adds a compatibility item to that checklist. When an app loses compatibility, someone has to decide whether to update it, replace it with a maintained alternative, or retire the feature it provided. Document the owner, the Nextcloud versions each component was last tested against, and the rollback path for each one. Without that register, the cost of an upgrade grows with every custom component added.
Third-party apps need their own recurring review. Each new app request from users, and each update to an app already in use, should pass through a governance step covering the publisher, the permissions the app requests, its maintenance history and whether it interacts with your custom code. A customization that depends on a community app inherits that app's release timing. Plan for someone to read changelogs, test updates in a staging instance and make the call to hold or accept a version. This review is often the first recurring task that falls to nobody when a team is busy, so name the role responsible for it before go-live.
Support requests change shape after customization. Users who hit a problem in a theme, a Flow workflow or an integration will report it as a Nextcloud fault, so the help desk needs a triage path that separates core issues from custom-code issues. Confirm who answers for each custom component, what the response expectation is, and how fixes are released. Nextcloud Enterprise pricing is per user per year, and its tiers differ in maintenance period and response times: 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, according to Nextcloud's pricing page. Confirm in writing which tier and support scope covers your custom components, since vendor support may not extend to code you wrote or modified. Request current pricing directly from Nextcloud, because list prices change and volume rates apply from 200 users.
The hardest recurring cost is people. Staff who understand the custom code, its dependencies and the reasons behind its design become a dependency themselves. When they leave, every upgrade gets slower and riskier. Decide how knowledge is kept: documented code, a named maintainer for each component, a second person who can run the test cycle, and a retained partner or internal rota for emergency fixes. Ask any implementation partner to state in the quote who maintains the code after handover, what documentation is delivered and whether ongoing support is priced separately from the build.
Questions buyers ask about Nextcloud customization
Can we customize Nextcloud ourselves without a partner?
Yes, many customizations are within reach of an experienced in-house team, and the first step is sorting the work by type. Theming and branding through the supported theming settings, app selection from the app store, and Flow workflows for simple automation are usually configuration work that an administrator can run and document. Custom app development, deep integrations through WebDAV or the APIs, and changes that touch authentication or storage need PHP or JavaScript skills, a test environment that mirrors production, and someone who will own the code through every major release. Confirm your team's Nextcloud and PHP experience, and who will maintain the result after the first upgrade, before deciding what to build in-house.
What drives the cost of Nextcloud customization?
The cost follows the size and number of changes, and no single figure applies across organizations. The main drivers are the type of change (configuration is cheap compared with new app code), the number of integrations with identity, document or line-of-business systems, the testing required to prove each change survives an upgrade, and the documentation and handover your team needs to run it. Ongoing costs include maintaining custom code across each major release and reviewing third-party apps when they update. When requesting a quote, ask for the scope as a written list of changes, the acceptance tests for each, who pays for the test environment, and what support is included after delivery. Fixed-scope quotes make these trade-offs visible.
How long does a Nextcloud customization project take?
Duration depends on the scope and on how quickly your decision owners and test environment are available. Branding and app configuration can often be completed within a short engagement, while custom app development usually takes longer because it includes design, coding, testing against the target Nextcloud version, and a handover. Plan for time spent on approvals, security review of any custom code, and a test cycle that repeats after each planned upgrade. Ask the partner for a timeline tied to the agreed deliverables, and confirm which dependencies, such as access to a staging server or a named product owner, sit on your side.
Do custom apps break Nextcloud upgrades, and how do we prevent it?
Custom apps can break upgrades when they rely on internal APIs, database schema details, or behavior that changes between major versions. Nextcloud requires upgrading one major version at a time, backing up before each upgrade, and disabling third-party apps until they are confirmed compatible. To reduce the risk, build on documented APIs rather than internals, declare the supported version range in the app metadata, keep the app small and well tested, and run every upgrade in staging with the app enabled before production. Keep the code in version control and assign an owner for each release cycle. Confirm these practices in your partner's written scope.
Does Nextcloud Enterprise support cover our custom apps?
Nextcloud Enterprise support covers the Nextcloud product and its supported components, but custom apps written by your team or a partner are normally outside that coverage. Confirm the exact scope with Nextcloud GmbH before you rely on it, including how it treats third-party and custom apps and whether any app-level troubleshooting is included. Enterprise tiers differ in maintenance length and support hours, so check the current pricing page for the tier you are considering. Ask your partner to document how custom apps are tested, who fixes them when a Nextcloud release changes behavior, and how that responsibility is recorded in the statement of work.
What does a Nextcloud customization project need from our team?
The work needs three things from your side: people, environments, and decision owners. People include an administrator who understands your Nextcloud installation, and developers if custom code is in scope. Environments include a staging instance that matches production in version, database, storage and identity configuration, so upgrades and app changes can be tested before release. Decision owners approve branding, app selections, data-handling rules and acceptance criteria, and they should be named before work starts. Missing any of these usually causes delays, so confirm each role and its time commitment in the written scope.
Can Nextcloud Flow replace custom code?
Flow can replace some custom code, particularly simple automations such as tagging files, sending notifications or applying a workflow when a file is created or shared. It is a poor fit for logic that needs complex branching, data transformation, external system calls with error handling, or changes to core behavior. Before choosing Flow, list each requirement, confirm which triggers and actions your Nextcloud version provides, and test the workflows under expected load. Workflows also need the same upgrade testing as custom apps, since changes in the platform can affect them. Ask a partner to map each requirement to Flow, a configuration change, or a custom app, with reasons.
How do we decide between a configuration change and a custom app?
Choose a configuration change when a supported setting, existing app or Flow workflow meets the requirement, because it carries less upgrade risk and less code to maintain. Choose a custom app when the requirement needs behavior no supported option provides, such as a new interface, a specialized integration, or logic that must run inside Nextcloud. Ask four questions: Does a supported setting or existing app meet it? Does Flow handle the logic reliably? Who will maintain the code after the next major release? What does a failed upgrade cost in downtime and rework? Record the answers for each requirement so the decision can be reviewed when Nextcloud releases change.
What your team needs to provide before customization starts
Customization work goes faster and carries less upgrade risk when your team lands a clear set of inputs before the first line of code or theme file is written. The most important is a running or staging Nextcloud instance that matches production. Confirm the exact Nextcloud server version, the PHP and database versions, the web server, and the list of enabled apps against production. A theme or custom app built against a different minor release can behave differently after deployment, so ask for a snapshot of the production configuration and a staging copy restored from a recent backup. Next, grant admin access that is scoped to the work. Developers usually need a named admin account on the staging instance, access to the app directory or app folder, and the ability to change theming settings and the occ command line tool on the test server. They rarely need database superuser rights or root access to the host on production. Agree in writing which accounts will be used, who holds the credentials, and how access is removed when the engagement ends. Ask for a current list of customizations already in place, including custom CSS, theming values, Flow rules, scripts, cron jobs and any third-party apps, because these are the components most likely to break during an upgrade. Brand assets and style rules should arrive as a single package: logos in the formats your brand team uses, colour values, typography, favicon and login background images, and any accessibility requirements such as contrast minimums. Equally important are the integration endpoints the customization will call or be called by. For each one, provide the URL, the authentication method, and a dedicated service account with the minimum permissions needed. Do not share personal credentials for integrations. Service accounts should be documented, rotated on a schedule, and excluded from interactive login where the identity provider allows it. Decision owners need to be named before work starts. Someone must approve which apps are installed, who signs off on branding changes, and who accepts test results. Without these owners, customization often stalls at the point where a developer asks whether a change is allowed. Finally, recruit a test group of real users from the departments that will use the changes, and plan for them to test on staging against agreed scenarios. Their feedback catches layout and workflow problems that technical checks miss. In return, expect to receive and keep the source code in a repository you own, the configuration and theming files, documentation of each change and its reasons, and an upgrade runbook that lists the steps, the compatibility checks and the rollback plan for each future major release. Confirm the repository location, the licence of any custom code, and who will maintain it after handover.
How DeployOpen works on Nextcloud customization
DeployOpen plans and builds Nextcloud customization inside your own infrastructure, starting from a written scope that names each theme change, app decision, automation or integration. Work is delivered with documentation and checks designed to keep the instance upgradeable, and ongoing support is available as a retainer.
How we scope
- We list each branding, theme, app, Flow automation and integration item and record what it changes in the instance.
- We check which installed and planned apps are maintained for the Nextcloud major version you run or intend to adopt.
- We agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- We keep theme and branding changes in supported customization points so core upgrades do not overwrite them.
- We build custom apps and integrations against documented WebDAV and API endpoints, with versions pinned and dependencies recorded.
- We test each change on a staging copy of your instance, including the third-party apps it depends on, before production.
How we hand over
- You receive documentation of each customization, its configuration location, owner and the reason it exists.
- You receive an app inventory that records version, source, license and the compatibility status for each third-party app.
- We walk your administrators through the upgrade path, including backing up before each major upgrade and disabling unverified apps.
How we support
- Ongoing support can cover app compatibility checks before each planned Nextcloud upgrade, one major version at a time.
- Retainers can cover maintenance of custom apps, Flow workflows and integrations as Nextcloud and their dependencies change.
- Confirm with us during scoping which support hours, response expectations and escalation paths the retainer includes.
