Open source without a tested exit is only a good feeling.

Plan the exit when you introduce the system

When you choose a company application or have one built, a practical question belongs with it: how can another team take it over later — without midnight heroics? For neurofunken, custom development and open source take priority. Our conclusion from the checked operations docs: that decision should be paired with a demonstrably working handoff path. That includes usable data, a restorable application, and instructions a second person understands.

The Nextcloud guide to server migration shows how concrete that path becomes: it considers the target environment, database, files, configuration, and functional checks before cutover. The described move includes an interruption. From that we derive a project requirement: have prerequisites and interruptions named early. Then you can plan a later operator change against checkable conditions — instead of selling it as a theoretical option.

Export and restore are two checks

A business export should make data usable for another application. A backup should make a defined state restorable. Both goals can overlap technically, but they need their own acceptance criteria. Example: for switching a project tool you agree project numbers, descriptions, and attachments as a handoff package. Then you check in the target whether each attachment still belongs to the right project. A visible list alone would be insufficient evidence — it only soothes.

A database export also has limits. PostgreSQL 18 documents that pg_dump exports one database at a time. Cross-cutting objects such as roles are not included; the docs point to pg_dumpall for that. It also recommends against using pg_dump as the method for regular backups of production databases outside simple cases.

Our recommendation: for an export, agree content, format, and import check explicitly. For the backup, additionally define which state must be restored and how current it should be. Procedure choice follows those requirements — not the tool that currently feels familiar.

Capture the full application — not just one folder

For Nextcloud 32 the backup guide names five parts: configuration, additionally installed custom apps, data directory, theme directory, and database. The restore guide explicitly requires database, data directory, and configuration files. Anyone planning a backup therefore needs an inventory of all required parts. One saved folder does not yet prove full restorability.

For custom applications we recommend a short inventory accordingly: which data live where? Which software versions and extensions are required? Which settings belong to operations? Add owners and the intended backup path.

Also consider how related data keep a consistent state. Nextcloud describes maintenance mode for that, which blocks running user sessions and prevents new logins. Which approach fits your application must be checked against its architecture. A generic copy recipe does not replace that decision.

Accept the restore on substance

Backup tools check different things. With restic the default check examines structure and consistency of the backup store without fully verifying every stored data pack for unchanged content. The additional full data check reads those packs as well. That takes longer and can cause extra transfer cost with remote storage.

Our conclusion: complement such checks with an application test. Example flow: a second person restores a project tool from the instructions in a separate test environment. Email sending and production interfaces stay off. Then they sign in with planned test accounts, open defined projects, check attachments, and compare access rights with expected results.

Record backup time, versions used, time needed, and deviations. Define beforehand which checks must succeed. The trial then yields traceable evidence for exactly that scope. It still allows no claim about untested datasets or performance under full load — and the protocol should say so.

Start with one application and one handoff

As a first step, choose a manageable, important application. Name a responsible person and a second person for restore. Agree with the affected teams which interruption and which possible loss of new changes would be tolerable. Those constraints become the yardstick for the backup concept.

Create a short handoff guide with data locations, versions, restore steps, acceptance criteria, and contacts. Also describe how authorised people obtain the necessary access. Have the second person run the flow and add every missing prerequisite. The result should be a test protocol and concrete improvement tasks. For custom builds we recommend agreeing this evidence as an acceptance criterion — before anyone books “open source” as independence.

As of 18 September 2026. Technical statements refer to Nextcloud 32, PostgreSQL 18, and the checked restic documentation for version 0.19.1. Before implementation, check the documentation of your deployed version and repeat the dry run after material changes.