Migrating an existing Nextcloud

Updated on Jul 28, 2026 Feedback on this page

Already using Nextcloud and want to move to server.camp? That works – and in both cases your files, calendars and contacts come along. Which path applies depends on exactly one question: can you reach the server and the database of your Nextcloud, or not?

Your situation	Path	Who does it	Downtime
Managed Nextcloud at another provider, no server access	Per-user export	you, as self-service	none
Self-hosted, with server and database access	Full migration	we do, in a maintenance window	yes, depending on data volume (from about 2 - 4 hours)

Before the move: order Nextcloud hosting

Both paths need a Nextcloud subscription at server.camp first – you can try Nextcloud free for 30 days and rehearse the migration during the trial.

Path A – without server access: migrate user by user

If your Nextcloud sits with a provider that gives you no shell and database access, you cannot get at a complete backup. In that case you move account by account – with the Nextcloud User migration app. It packs one user account into a single archive file (<user>.nextcloud_export) that you read back in on the new instance.

Requirements

The User migration app (user_migration) has to be installed and enabled on both sides. It is not part of a standard Nextcloud installation but comes from the App Store.
In your instance at server.camp you install it as an admin under Apps → Tools and enable it.
On the source side you need admin rights to install it – or the provider has already enabled it. If they cannot, the desktop client route remains (see below).

The process

Export on the old instance – each person opens Personal settings → Migration, selects what should come along (files, settings, profile, profile picture, calendars, contacts) and starts the export. Nextcloud then places the archive in their own file area.
Download the archive – save the <user>.nextcloud_export file locally.
Create the user on the new instance – as an admin under Users → New user, or connect single sign-on right away.
Import – the person uploads the archive again under Personal settings → Migration and starts the import.

Large accounts: let us do the import

Our instances accept uploads up to 1 GB. An account with a lot of data quickly produces a larger archive – which then cannot be read in through the web interface. In that case we do the import server-side with occ user:import; just contact our support. The same applies to the export: with admin access on the source side it also works via occ user:export <user> <target folder>.

What does not come along

The archive is a copy of one account – everything belonging to the instance as a whole is not in it and has to be recreated on the new instance:

Follow-up work	What to do
Groups and memberships	Recreate them before you set up shares again
Shares between users	Set them again – the archive does not know the recipients of the old instance
Public links	Create new ones; old links contain the old domain and stop working
Admin and system settings	Reconfigure them (language, quotas, sharing rules, password policies)
External storage	Set up again, including credentials
App passwords for devices	Create new ones and enter them in the clients
Configuration of individual apps	Check per app – whether an app exports its data is up to that app

Only after the files? Then the desktop client is enough

If all you care about are the files, you do not need the app at all: use the Nextcloud desktop client to sync everything from the old instance onto your computer, then connect the client to the new instance and upload the folder there. It is slower, but it works without any cooperation from the old provider. Calendars and contacts are exported separately as .ics and .vcf files in that case.

Running both instances means two versions of the truth

As long as work continues on the old instance, files and changes accumulate there that an archive created earlier no longer contains. So set a cut-off date after which everyone works on the new instance only – and set the old instance to read-only or shut it down afterwards.

Path B – from your own instance: full migration

If you have been running Nextcloud yourself and can reach the file system and the database – or can have your provider generate an export for you – we take the complete route: you create a backup, we restore it on our side. The result is a 1:1 copy of your instance – including users, groups, shares, calendars, contacts, file versions and trash.

The process and the files match the official Nextcloud guides Backup, Restore and Migrating to a different server.

How the maintenance window works

We agree on a time slot with you during which you can do without your Nextcloud and we can restore and verify the backup without rushing.

You put your instance into maintenance mode so the backup is consistent and nothing is written afterwards.
You create the backup and hand the files over to us – described step by step under how to create the backup.
We restore the database and the data into your new instance, carry over the key values from your config.php, and validate the import with occ files:scan --all and occ maintenance:data-fingerprint.
We release the instance, you sign it off.
You switch DNS and let your users know that their clients have to reconnect. The old instance stays shut down so nothing is written into two systems in parallel.

A pre-sync shortens the downtime considerably

With Nextcloud it is almost entirely the data volume that determines how long it takes – a data directory of several hundred GB does not transfer in minutes. That is why we like to copy the data in two stages: you transfer the bulk of it before the maintenance window while the instance is still live, and during the window only the remainder follows. The actual move then often takes no more than an hour. Talk to us about it if you have more than a few dozen GB.

What we need from you

In essence, we need four things:

File or directory	Contents
Database dump (`.sql`)	Users, groups, shares, calendars, contacts, file metadata, app data.
`data/`	The actual files, file versions and trash contents – and, if you use encryption, the encryption keys.
`config/config.php`	Your instance configuration. Critical: it contains `secret`, `passwordsalt` and `instanceid`.
`themes/` and your own apps	Only if you use a custom theme or apps you installed outside the App Store. Otherwise this does not apply.

config.php is the critical piece

The values secret, passwordsalt and instanceid from your config.php must not be regenerated – Nextcloud uses them to encrypt, among other things, the credentials of external storage and your app passwords. If you additionally use server-side encryption, it gets harsher still: Nextcloud puts it as losing the encryption keys or your instance secret resulting in permanent data loss. The keys live in data/<user>/files_encryption and data/files_encryption – so they come along with the data directory, as long as you transfer it completely. Secure config.php first, and tell us in advance whether encryption is active on your side.

We do not need Redis

Your Nextcloud probably uses Redis or Memcached as a cache. That is pure acceleration and holds no persistent data – we need none of it. Active sessions are lost in the process, which means every user has to log in once after the move.

To clarify up front: version and database

Version and database type have to match

We run a fixed Nextcloud version with MariaDB. We need to reconcile both before the maintenance window, not during it.

Find your version: it is shown in the web interface under Administration settings → Overview, or via occ status.
Ask for our target version: we currently host Nextcloud 34. Because we update versions regularly, our support team will tell you the exact version at the time of your migration.
Are you older? Then bring your instance up to our version before taking the backup. Important: Nextcloud does not allow skipping major versions – going from 31 to 34 only works via 32 and 33, step by step. That is the preferred route, because the upgrades then run on your system rather than under time pressure inside the maintenance window.
Database: if you run MySQL or MariaDB, the dump fits directly. If you use SQLite, convert it to MariaDB beforehand with occ db:convert-type. If you are coming from PostgreSQL, there is no official conversion route – please tell us early, then we plan it together or use path A for the accounts.

How to create the backup

The following steps match the official guide and assume a classic installation under /var/www/nextcloud with MariaDB. Adjust the paths to your installation; if your Nextcloud runs in Docker, see the note further down.

Step 1 – Enable maintenance mode so nothing is written during the backup:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on

Step 2 – Back up the database:

mysqldump --single-transaction -h localhost -u nextcloud -p nextcloud > nextcloud-db.sql

Step 3 – Back up the directories. The data directory is the big one – this is where the hours go:

rsync -Aavx /var/www/nextcloud/config/ nextcloud-backup/config/
rsync -Aavx /var/www/nextcloud/themes/ nextcloud-backup/themes/
rsync -Aavx /var/www/nextcloud/data/   nextcloud-backup/data/

Step 4 – Check the result. These four things are then ready for us:

nextcloud-db.sql
nextcloud-backup/data/
nextcloud-backup/config/config.php
nextcloud-backup/themes/          # only with a custom theme

Afterwards you leave the instance in maintenance mode or shut down until the move has been signed off.

Docker and other installation types

If your Nextcloud runs in Docker, you run occ via docker exec -u www-data <container name> php occ maintenance:mode --on; config/, data/ and themes/ then live in the mounted volumes, and you create the database dump in the database container (docker exec <db container> mysqldump …). If you use Nextcloud All-in-One, it has its own backup and migration procedure – get in touch with us before you start in that case. If you are unsure which case applies to you, just ask us beforehand.

Handing the files over

The data directory is typically the largest part and quickly reaches several hundred GB. We provide an upload area for the handover, or you use scp/rsync into a directory we prepare for you – with large data volumes rsync is the better choice, because it can be repeated and resumed.

config/config.php contains secrets in plain text. Hand it over separately from the data and encrypted – for example as an entry in a shared Vaultwarden vault, via Hemmelig or GPG-encrypted.

We do not adopt your config.php as-is

We configure your instance at server.camp on the platform side – reverse proxy, certificates, database, cache, cron and the performance parameters are ours and derived from your plan. A config.php dropped in by hand would be overwritten on the next deployment.

So we read it, go through it with you where needed and decide setting by setting:

Setting in your `config.php`	At server.camp
`secret`, `passwordsalt`, `instanceid`	We carry these over unchanged – without them encrypted values are lost
`trusted_domains`, `overwrite*`, `dbhost` and credentials	We set these on the platform side – see Your own domain
`datadirectory`, storage paths	Fixed on our side; storage always stays at server.camp
Mail delivery	Our mail delivery by default; your own mail server is configurable in the portal
Redis/Memcache, cron, PHP limits	Derived from the resource allocation of your plan
Office integration (Collabora, OnlyOffice, Euro-Office)	Provided by the platform, selectable in the customer portal
LDAP, SAML, OIDC and other functional settings	We carry these over

That is why you should send us the config.php early, not on moving day: anything to be carried over is a change to your subscription – and we plan those together before the maintenance window.

After the migration

These points apply to both paths:

Your own domain: if you want to keep using your previous domain, we will set it up together with you – see Your own domain.
Reconnect the clients: after the move, desktop and mobile clients have to log in once more. If the address changes, your users add the account in the client again with the new server URL – the local folders stay in place and are only reconciled, not downloaded again.
Calendars and contacts in external programs: CalDAV and CardDAV addresses stored in Thunderbird, on an iPhone or in Outlook may still point to the old domain and have to be updated.
Public links: share links contain the domain. Under a new address the old links stop working – tell the recipients or create the links anew.
Check external storage: under Administration settings → External storage, verify once that all connections are green. Credentials are encrypted with secret and only keep working if that value came along (path B).
Verify encryption (path B only): if you use server-side encryption, open files of several users as a test after the move, before you release the old instance.
Backups and monitoring run automatically from the first deployment onwards. There is nothing for you to set up.
The old instance: leave it shut down – but not yet deleted – until you have signed off the migration and worked productively on the new instance for a few days.

Requesting a migration

Write to us via the customer portal if you want to move. The following details help us give you a useful first answer:

Do you have server and database access to your current Nextcloud, or is it hosted by a provider?
Which Nextcloud version are you running (Administration settings → Overview)?
Which database do you use – MariaDB/MySQL, PostgreSQL or SQLite?
Is server-side encryption active?
How large is your data set (number of users, size of the data directory)?
Do you have a preferred date for the maintenance window?

For the per-user export in path A you can start right away without asking us – just get in touch if anything does not work as expected.