Nextcloud: Alles rund um die eigene Cloud – und warum ein Hoster-Wechsel kein Hexenwerk ist

Nextcloud gehört inzwischen zur Grundausstattung vieler Organisationen. Was einst als private Dateiablage begann, hat sich zu einer Plattform entwickelt, auf der Teams Dokumente bearbeiten, über Video konferieren, Termine koordinieren und sogar Formulare auswerten. Genau das macht den Dienst so wertvoll – und genau das macht einen Umzug zu einem Projekt, das man nicht mal eben nebenbei erledigt. Wer sich zum ersten Mal mit der Frage beschäftigt, den Nextcloud-Hoster zu wechseln, stößt schnell auf Begriffe wie Datenbank-Dump, occ-Kommando und LDAP-Anbindung. Das klingt komplizierter, als es ist. Aber es erfordert Sorgfalt, einen klaren Plan und ein bisschen Geduld. Wer vorher weiß, wo die Stolperfallen liegen, spart sich schlaflose Nächte und am Ende womöglich den Verlust von Daten.

Warum Nextcloud mehr als ein Dateispeicher ist

Nextcloud war einmal ein simpler Dropbox-Ersatz, der sich selbst hosten ließ. Heute ist die Software ein ganzes Ökosystem. Dateien lassen sich über WebDAV synchronisieren, per Link teilen, mit einem Kennwort schützen und mit Ablaufdaten versehen. Unter Windows, macOS, Linux, iOS und Android gibt es Clients, die das Ganze beinahe nahtlos in den Arbeitsalltag integrieren. Doch der eigentliche Wert liegt in der Kombination aus Speicher und Werkzeugen: Kalender, Kontakte, E-Mail-Integration, Videokonferenzen mit Nextcloud Talk, ein Office-Paket auf dem Server, Aufgabenverwaltung, Notizen, Passwortmanager und ein App-Store für Erweiterungen. Aus einer Datenablage ist eine Digitalisierungsplattform geworden, die in vielen Unternehmen mittlerweile das Rückgrat der Zusammenarbeit bildet.

Dabei zeigt sich ein interessanter Effekt. Die meisten Nutzerinnen und Nutzer merken gar nicht, wie tief Nextcloud in ihre Arbeitsprozesse eingewebt ist. Sie gehen in den Dateimanager und sehen eine „Cloud-Schublade“; sie öffnen einen Termin und wundern sich, wenn die Einladung nicht synchronisiert. Sie klicken auf einen Link zu einem internen Dokument und erwarten, dass dieser Link funktioniert. Wenn dann ein Hoster wechselt, betrifft das also weit mehr als das „nur die Dateien“. Es betrifft die Kontinuität von Links, das Benutzerkonto, die Versionierung, gespeicherte Geräte, Clients und Dritt-Applikationen, die über die OAuth-Schnittstelle angebunden sind. Nicht zuletzt aus diesem Grund sollte der nächste Hoster nicht nach Bauchgefühl, sondern nach klaren technischen Eckdaten ausgewählt werden.

Selbst hosten oder Hoster? Zwei Welten

Bei Nextcloud gibt es zwei grundsätzliche Betriebsmodelle, die regelmäßig vermischt werden. Die erste Variante ist der Selbstbetrieb. Nextcloud wird dabei auf eigenem Server, auf einem Cloud-Rechner bei einem Infrastructure-Anbieter oder auf einem NAS im Büro installiert. Die zweite Variante ist der Betrieb durch einen externen Dienstleister. Dieser kümmert sich um Server, Updates, Backups, Monitoring und teils auch um Support. Man mietet also gewissermaßen die Plattform. In der Praxis gibt es zahlreiche Zwischenstufen: Einige Hosting-Firmen verkaufen Nextcloud als „Managed Nextcloud“, andere bieten nur ein vorkonfiguriertes Image für den eigenen Root-Server.

Nextcloud in der eigenen Hand

Selbsthosting gibt einem maximale Kontrolle. Man entscheidet, auf welchem Server die Daten liegen, welche Apps aktiviert werden und wann Updates erfolgen. Für technisch affine Administratoren ist das reizvoll, zumal sich Nextcloud mit ein paar Grundkenntnissen in Docker und Linux aufsetzen lässt. Allerdings fällt die gesamte Verantwortung auf den Betreiber zurück: Sicherheitsupdates müssen eingespielt werden, Backups regelmäßig erstellt und im Ernstfall getestet werden. Wer das unterschätzt, steht schnell vor einem kaputten System, das genau dann streikt, wenn es auf die lange Liste unterstützter PHP-Versionen ankommt oder ein Upgrade fehlschlägt. Ich habe schon Konfigurationen gesehen, in denen Nextcloud über einem alten Apache mit einer inzwischen unsicheren PHP-Version lief – der Betreiber wusste es, aber das Risiko war ihm bewusst. Das ist legitim, aber nur so lange, wie es nicht um echte Produktivdaten geht.

Managed Nextcloud beim Hoster

Die managed Variante nimmt einem viel Arbeit ab. Seriöse Anbieter sorgen für die Aktualisierung der Software, überwachen Speicherplatz und Verfügbarkeit und halten einen Support bereit. Für Unternehmen, die ihre personellen Ressourcen lieber in Fachanwendungen stecken als in Nextcloud-Upgrades, ist das oft die sinnvollere Wahl. Der Preis dafür ist ein gewisser Kontrollverlust. Man muss darauf vertrauen, dass der Hoster die Server sicher betreibt und im Ernstfall die Backups funktionieren. Nicht alle Anbieter sind gleich gut, das zeigt sich häufig erst bei einem Incident. Deshalb ist es ratsam, sich die Datenschutzerklärung, die Serverstandorte und die mitgelieferte Servicebeschreibung genau anzusehen. Wenn dort steht, dass ein „Basis-Backup“ enthalten ist, lohnt die Nachfrage: Wo liegt das Backup? Wie lange werden Versionen vorgehalten? Gibt es ein Restore-Training? Geschulte Admin-Aussagen dazu sind oft sehr aufschlussreich.

Gründe für einen Wechsel des Nextcloud-Hosters

Es gibt viele legitime Gründe, den Nextcloud-Hoster zu wechseln. Einer ist das Wachstum. Was mit zwanzig Benutzern und ein paar hundert Gigabyte beginnt, entwickelt sich irgendwann zu einer Umgebung mit mehreren Terabyte und vielen angeschlossenen Services. Dann wird der Server zu klein, die Latenz zu hoch, und die Kosten explodieren, weil das Paket nicht mehr passt. Ein anderer Grund ist die Serverlokalität. Wer in Deutschland sitzt und seine Daten plötzlich in einem Rechenzentrum außerhalb der EU findet, weil der Hoster umstrukturiert wurde, hat ein Problem. Auch der Support spielt eine Rolle. Wenn Tickets tagelang unbeantwortet bleiben oder bei einem Ausfall keine klare Kommunikation erfolgt, sinkt das Vertrauen.

Manchmal ist es auch die simple Preis-Leistungs-Rechnung. Ein neuer Anbieter bietet mehr Speicherplatz, bessere Performance oder eine modernere Infrastruktur zum gleichen Preis. Manchmal fehlen schlicht bestimmte Features – etwa die Anbindung an einen S3-Objektspeicher, umfassende LDAP-Integrationen oder eine höhere Anzahl an verschlüsselten Endpoints. Nicht selten kommen interne Vorgaben von Datenschutz- oder IT-Revision dazu. In jedem Fall gilt: Ein Hosterwechsel ist kein Zeichen von Scheitern, sondern eine normale Lebensphase digitaler Infrastruktur. Entscheidend ist, dass er geplant und nicht erzwungen wird.

Der Wechsel ist kein Projekt für einen Nachmittag

Wer schon einmal einen Server von einer Firma zur anderen migriert hat, weiß: Der eigentliche Transport der Daten ist oft der einfachste Teil. Die Herausforderung liegt in der Vorbereitung und in der Koordination. Zuerst muss man sich einen vollständigen Überblick über die eigene Nextcloud-Instanz verschaffen. Dazu gehört mehr als die Frage, wie groß das Datenverzeichnis ist. Man sollte wissen, wie viele Benutzerkonten aktiv sind, ob sie per LDAP/AD angebunden sind oder lokal verwaltet werden, welche Apps verwendet werden und ob es Sonderlocken wie externe Storage-Anbindungen, App-Passwörter oder integrationsfremde Themen gibt. Eine solche Bestandsaufnahme ist in einer Stunde erledigt, wenn man die passenden occ-Befehle kennt. `occ app:list` zeigt alle aktiven Apps, `occ user:list` listet die Benutzer auf, und die Dateien im Verzeichnis `config` verraten die wichtigsten Einstellungen. Ich bin immer wieder überrascht, wie viele Administratoren diese Kommandozeile nie nutzen – schade, denn über die Web-Oberfläche bekommt man nur einen Bruchteil der Infrastruktur zu sehen.

Inventar der Nextcloud-Instanz

Ein gutes Inventar enthält mindestens folgende Punkte: die Version der Nextcloud-Instanz, die PHP-Version und die verwendete Datenbank, den Speicherort des Datenverzeichnisses, die Liste aller lokal installierten Apps und deren Versionen, die Anzahl, Größe und Struktur der angeschlossenen externen Datenspeicher. Auch die Konfigurationsdatei `config.php` sollte man durchgehen, denn darin verstecken sich Einträge wie `trusted_domains`, `overwrite.cli.url`, Einstellungen für Redis, S3-Buckets oder den Mailversand. Wer diese Punkte vorab dokumentiert, hat später beim neuen Hoster einen unschätzbaren Vorteil: Er kann die Umgebung exakt nachbilden, statt sich durch Trial-and-Error zu hangeln. Ein weiterer wichtiger Aspekt ist die Datenbankgröße. Sie wächst proportional zur Anzahl der Dateien, Benutzer und Ereignisse. Gerade wer viele gemeinsame Aktivitäten über Talk oder Aktivitäten-Feed verfolgt, hat oft eine deutlich größere Datenbank, als der Speicherplatz der Dateien vermuten lässt.

Neuen Hoster festlegen

Die Entscheidung für einen neuen Hoster sollte nicht allein auf einer Website-Liste mit Preisen basieren. Sinnvoll ist ein Blick in die Doku: Wie wird Nextcloud dort gehostet? Läuft die Instanz auf einem dedizierten Server, in einem Kubernetes-Cluster oder als geteilte Multi-Tenant-Installation? Wie erfolgen Backups? Gibt es ein Restore-Konzept, das im Notfall auch wirklich greift? Lassen sich eigene Apps installieren oder ist der App-Store eingeschränkt? Wie sieht es mit 2-Faktor-Authentifizierung, LDAP, OIDC aus? Seriöse Anbieter können das alles in einem technischen Steckbrief beantworten. Ein Kriterium, das oft unterschätzt wird, ist die maximale Dateigröße. Wer mit großen Videodateien oder 3D-Modellen arbeitet, braucht einen Server, der Uploads von mehreren Gigabyte verarbeiten kann. Bei Managed-Anbietern sind da mitunter Limitierungen eingebaut, die man erst bemerkt, wenn es zu spät ist.

Zeitpunkt und Kommunikation

Der Zeitpunkt des Wechsels sollte möglichst außerhalb der Kernarbeitszeiten liegen. Ein Umzug am Wochenende ist typisch, auch wenn er für manche Administratoren ein Graus ist. Die Nutzerinnen und Nutzer sollten vorher informiert werden: Ab wann ist mit der Umstellung zu rechnen? Müssen Dateien vorher geschlossen werden? Gibt es eine Daten-Synchronisationspause? In vielen Fällen kann man den Umzug so planen, dass die letzte Synchronisation am frühen Morgen läuft und der Dienst zum Dienstbeginn wieder verfügbar ist. Das funktioniert, wenn die Datenmenge überschaubar ist und die Infrastruktur des neuen Hosters nicht überrascht. Bei einem mehrköpfigen Team lohnt es sich, einen internen Verantwortlichen zu benennen, der den Überblick über die einzelnen Schritte behält und im Zweifel Entscheidungen treffen kann. Diese Rolle sollte nicht derjenige haben, der parallel noch Tickets bearbeiten muss.

Migration Schritt für Schritt

Jetzt wird es handfest. Die Migration einer Nextcloud-Instanz folgt meist einem ähnlichen Muster: neue Umgebung aufsetzen, Daten kopieren, Konfiguration anpassen, Testen, Umschalten. Der wichtigste Grundsatz dabei lautet: Der alte Dienst bleibt bis zum Schluss unangetastet. Man sollte den alten Hoster keinesfalls vorab kündigen oder gar die Instanz löschen. Erst wenn die neue Umgebung vollständig läuft und die Nutzer freigeschaltet sind, darf die alte Instanz abgebaut werden. So lässt sich im Fehlerfall einfach zurückrollen, ohne dass Daten verloren gehen.

Die neue Umgebung vorbereiten

Auf der neuen Server-Umgebung muss eine Nextcloud-Instanz bereitstehen, deren Basisversion möglichst exakt der alten Version entspricht. Eine Überraschung ist sonst vorprogrammiert: Nextcloud führt bei älteren Versionen ein Datenbank-Upgrade automatisch durch, wenn man nach dem Dateikopieren die Seite das erste Mal aufruft. Wenn zwischen Ausgangs- und Zielversion mehrere Hauptversionen liegen, kann das Upgrade schrittweise durch mehrere Versionen laufen. Das ist zwar möglich, aber fehleranfällig. Besser ist es, auf dem neuen Server die identische Nextcloud-Version zu installieren, dann die Migration durchzuführen und erst anschließend das Update auf die neueste Version zu fahren. Die Installation selbst kann über das bekannte Nextcloud-Installationsskript, einen Docker-Container oder das Setup des Hosters erfolgen. Dabei sollte man die Datenbank bereits konfigurieren, auch wenn sie im ersten Schritt noch leer ist. Ob MySQL/MariaDB oder PostgreSQL – beides sind gängige und unterstützte Datenbanken. Einige Managed-Hoster setzen standardmäßig SQLite ein, was für kleine Testinstallationen in Ordnung ist, für den Produktivbetrieb mit mehreren Benutzern aber keine gute Idee darstellt. Ich rate davon ab, eine Nextcloud-Instanz, die mehr als drei oder vier Personen nutzen, mit SQLite zu betreiben. Die Performance leidet, und die Migrationsoptionen sind unnötig eingeschränkt.

Datensicherung auf dem alten System

Bevor irgendetwas kopiert wird, braucht es eine saubere Sicherung. Die `config.php` gehört dazu, ebenso das Datenverzeichnis und die Datenbank. Wer sich ein `dump` der Datenbank erzeugt, sollte auf das Format achten: `mysqldump` unter MariaDB erzeugt SQL-Dateien, die tabellenweise eingespielt werden können. Für PostgreSQL nutzt man `pg_dump`. Wichtig ist, das Datenbank-Backup zu erstellen, während die Nextcloud-Instanz sich im Wartungsmodus befindet. Sonst kann es zu inkonsistenten Zuständen kommen, weil einzelne Tabellen während des Dumps verändert werden. Den Wartungsmodus aktiviert man mit occ maintenance:mode --on. Danach sollten alle Dienste, die auf die Datenbank zugreifen, deaktiviert werden. Besonders bei laufenden Synchronisations-Clients ist das ein entscheidender Punkt. Wenn während der Sicherung noch ein Desktop-Client Dateien hochlädt, stimmen Spiegelbild und Datenbank nicht mehr überein. Das führt später zu Baggerschäden, die sich nur schwer diagnostizieren lassen.

Datenverzeichnis und Dateien kopieren

Der eigentliche Transfer des Datenverzeichnisses lässt sich am Besten mit Werkzeugen wie `rsync` bewerkstelligen. Beim ersten Durchgang kann man die Instanz noch im laufenden Betrieb kopieren, um einen Großteil der Daten zu übertragen. Der zweite Lauf erfolgt dann im Wartungsmodus und gleicht die letzten Änderungen ab. Wer nur eine kleine Instanz mit einigen hundert Gigabyte hat, kann auch direkt im Wartungsmodus kopieren. Wichtig ist, dass der Datei- und Verzeichnis-Name im Datenverzeichnis exakt erhalten bleibt. Nextcloud speichert die Dateien nicht unter ihren ursprünglichen Dateinamen, sondern in einem internen Verzeichnislayout mit einem Basisnamen, der in der Datenbank auf den eigentlichen Namen verweist. Wenn man die Daten einfach aus dem Dateimanager kopiert, ist das Layout unverändert. Trotzdem muss man darauf achten, dass keine symbolischen Links oder Access-Control-Listen verloren gehen. Bei einem reinen Dateisystem-Kopieren auf dem neuen Server ist das unkompliziert; wer allerdings in einen Objektspeicher migrieren möchte, braucht eine eigene Vorgehensweise.

Für die Datenbank gilt etwas Ähnliches. Der Dump der alten Datenbank wird auf dem neuen Datenbankserver importiert, noch bevor die neue Nextcloud-Instanz gestartet wird. Dabei muss die Datenbank denselben Namen, denselben Benutzer und dieselbe Passwort wie in der neuen `config.php` haben. Wenn sich die Zugangsdaten geändert haben, trägt man sie in die `config.php` ein. Genauso wichtig ist das `datadirectory` in dieser Datei. Es zeigt auf den Pfad des Datenverzeichnisses auf dem neuen Server. Wer hier einen anderen Pfad verwendet als in der alten Umgebung, muss den Eintrag anpassen. Außerdem verdient `trusted_domains` Beachtung: Nur die dort eingetragenen Hostnamen und IP-Adressen dürfen sich später mit der neuen Instanz verbinden.

Konfiguration und Apps

Die `config.php` ist das Herzstück der Nextcloud-Konfiguration. Sie enthält nicht nur die Datenbankverbindung und den Datenpfad, sondern auch Werte wie `instanceid`, `secret`, `passwordsalt` und `version`. Diese Werte dürfen keinesfalls geändert werden, weil sonst alle bestehenden Sitzungen, App-Passwörter und vielleicht sogar verschlüsselte Dateien unlesbar werden. Das klingt banal, passiert aber immer wieder, wenn man eine frische Nextcloud-Installation als Grundlage für die Migration nutzt. Deshalb sollte man die aus der `config.php` der alten Instanz übernehmen und nur die Werte anpassen, die sich durch die neue Umgebung wirklich ändern – also Datenbank-Zugangsdaten, Pfade und gegebenenfalls die Liste der `trusted_domains`. Wenn der neue Hoster einen anderen E-Mail-Server oder ein anderes Redis-System bereitstellt, wird auch die entsprechende Konfiguration angepasst.

Die Apps liegen in der Regel im Verzeichnis `apps` der Nextcloud-Installation. System-Apps sind dort standardmäßig enthalten; zusätzlich installierte Apps können in einem separaten App-Verzeichnis liegen. Für die Migration ist es am einfachsten, das gesamte Verzeichnis zu übernehmen. Danach müssen die Apps auf dem neuen Server aktiviert werden, falls sie es nicht bereits von selbst sind. Ein häufiger Fehler ist, dass die App-Versionen der alten Installation nicht zur neuen Nextcloud-Version passen. Das Upgrade von Nextcloud-Versionen führt normalerweise dazu, dass inkompatible Apps als „kostenlos“ deaktiviert werden. Das ist aber nicht immer wünschenswert, wenn bestimmte Apps unverzichtbar sind. Insofern sollte man vor dem Upgrade prüfen, ob alle wichtigen Apps in einer kompatiblen Version vorliegen.

Der große Augenblick: Aufruf und Update

Nachdem die Daten kopiert, die Datenbank importiert und die `config.php` angepasst ist, steht der erste Start auf der neuen Umgebung an. Dabei ist es ratsam, die eigene Domain noch nicht umzustellen, sondern zunächst mit einer Test-URL oder einer Hosts-Eintragung zu prüfen, ob die Instanz funktioniert. Wenn die Seite lädt und keine Fehlermeldungen erscheint, kann man die einzelnen Bereiche durchgehen: Benutzerliste, Dateien, Dashboard, Apps. Ein genauer Blick auf die Aktivitäts- und Logdateien ist unerlässlich. Nextcloud schreibt ausführliche Logs in das Datenverzeichnis oder in einen konfigurierten Log-Ordner. Jede PHP-Warnung oder jeder Datenbankfehler sollte ernst genommen werden, auch wenn er sich nur als „intermittierender Fehler“ zeigt. Nach der erfolgreichen Prüfung wird die alte und die neue Instanz noch einmal synchronisiert – sofern die Alte noch erreichbar ist. Dabei werden die letzten Änderungen seit dem ersten Transfer übertragen. Für die Synchronisation des Datenverzeichnisses reicht ein erneuter `rsync`, für die Datenbank ein erneuter Dump und Import. Nun geht man auf dem alten System erneut in den Wartungsmodus, um sicherzustellen, dass keine Änderungen mehr passieren.

Dann kann die Domain umgestellt werden. Dazu wird der DNS-A-Record oder der CNAME-Eintrag auf die IP-Adresse des neuen Servers geändert. Die TTL (Time-to-Live) sollte bereits im Vorfeld auf einen niedrigen Wert, etwa 300 Sekunden, gesetzt worden sein, damit die Neuerung schnell ankommt. Wer nur eine IP-Adresse per A-Record benutzt, hat es hier leicht. Bei IPv6 muss zusätzlich der AAAA-Record angepasst werden. Nach der Umstellung heißt es: warten. Der DNS-Wechsel kann je nach Konfiguration und ISP noch einige Zeit dauern. Währenddessen sehen einige Nutzer die alte, andere bereits die neue Instanz. Wenn beide Instanzen die gleiche SSL-Zertifikatskette verwenden, ist das einigermaßen geschmeidig. Wer beim Umzug ein neues Zertifikat nutzt, sollte bedenken, dass ältere Clients mitunter noch das alte Zertifikat zwischengespeichert haben. Das kann zu Zertifikatswarnungen führen, die man durch einen kurzen Hinweis an die Nutzer abmildern sollte.

Nacharbeiten und Tests

Ist die Umstellung abgeschlossen, beginnt die eigentliche Feinarbeit. Alle Desktop-Clients, die zuvor auf der nächsten Synchronisierung scheitern, sollten durch ein manuelles Anmelden oder einen Neustart des Clients zur Bestätigung der neuen Serververbindung gebracht werden. Gerade bei älteren Nextcloud-Clients kann es vorkommen, dass sie auf die alte Server-URL festgenagelt sind und nicht bemerken, dass der DNS-Eintrag geändert wurde. Ein Neustart des Clients oder eine erneute Anmeldung behebt das. Wer eine App wie Nextcloud Talk nutzt, sollte nach der Migration einen kurzen Testanruf machen, um die WebRTC- und Signalwege zu prüfen. Auch der Versand von E-Mails über den neuen Server muss getestet werden, weil die Konfiguration des Mailservers nicht selten von den alten Gegebenheiten abweicht. Und schließlich sollten die Backup-Einstellungen auf dem neuen Hoster geprüft werden. Man möchte schließlich nicht feststellen, dass die automatischen Backups deaktiviert sind, wenn man sie braucht.

Das sind die typischen Fallstricke

Ein sehr verbreiteter Fehler ist die Verwechslung von Datenverzeichnis und Installationsverzeichnis. Nextcloud beinhaltet in der Regel einen Ordner `data/`, der unter dem Web-Root liegt. Die Installation liegt meist in `nextcloud/`, oft auf demselben Server. Wer nur das Datenverzeichnis kopiert und das Installationsverzeichnis frisch aufsetzt, muss sorgfältig die `config.php` anpassen. Wer zusätzlich noch Themes oder custom Apps im Installationsverzeichnis hat, darf sie nicht vergessen. Diese Details lassen sich leicht übersehen, weil sie auf den ersten Blick nicht mit den Nutzerdaten zu tun haben. Erst später, wenn das Erscheinungsbild oder ein Autologin nicht stimmt, merkt man den Fehler.

Ein anderer Klassiker ist das Problem mit den Dateiberechtigungen. Nextcloud läuft unter einem bestimmten Webserver-Benutzer, etwa `www-data` oder einem eigenen Service-Account. Wurde das Datenverzeichnis auf dem neuen Server mit `rsync` und der Option zur Erhaltung von Berechtigungen kopiert, können alte Ownerships zu Kuriositäten führen. Wenn die Dateien dem alten Benutzer gehören, dem neuen Webserver aber den Zugriff verweigert wird, zeigt sich das nur an der Web-Oberfläche, nicht im Dateisystem. Die Lösung ist simpel: man setzt die Dateiberechtigungen neu, etwa mit chown -R www-data:www-data datadir und stellt sicher, dass Verzeichnisse die Permissions `755` und Dateien `644` haben. Für erfahrene Admins ist das Routine, aber ich habe schon Migrationen gesehen, die daran kläglich scheiterten, weil ihnen der Schritt nicht bewusst war.

Ein dritter Fallstrick betrifft die serverseitige Verschlüsselung. Nextcloud kann wahlweise die Dateien auf dem Server verschlüsseln. In diesem Fall werden die Schlüssel im Datenverzeichnis unter `files_encryption` abgelegt. Wer diese verschlüsselten Dateien einfach kopiert, ohne die Schlüssel zu übertragen, macht die Daten nicht nur unlesbar, sondern zerstört im schlimmsten Fall die Verschlüsselungsstruktur. Die Schlüssel sind ebenso wie die `config.php` ein integraler Bestandteil der Instanz und müssen unbedingt mitkopiert werden. Gleiches gilt für die Ende-zu-Ende-Verschlüsselung, bei der die Schlüssel auf den Clients liegen. Deren verschlüsselte Dateien lassen sich nur wiederherstellen, wenn sämtliche Client-Benutzern die Apps und Geräte wieder mit der neuen Instanz koppeln. Das sollte man den Nutzern rechtzeitig erklären, sonst herrscht nach der Migration Verwirrung, warum plötzlich „unlesbare Dateien“ auftauchen.

Auch die Nutzung von External Storage kann zu Problemen führen. Wenn die Nextcloud-Instanz an S3, einen SFTP-Server oder eine andere Datenquelle angebunden war, müssen diese Zugangsdaten in der `config.php` oder in den entsprechenden App-Einstellungen nachgezogen werden. Manchmal ist der neue Hoster aus Sicherheitsgründen nicht bereit, eine Verbindung in ein externes Rechenzentrum zu erlauben. Dann muss man eine Firewall-Regel oder eine Netzwerkverbindung zwischen dem neuen Server und dem externen Storage einrichten. Das erfordert eine enge Abstimmung mit dem neuen Dienstleister und nicht selten zusätzliche Dokumentation.

Last, but not least: der berühmte „white screen“. Wenn Nextcloud nach dem Kopieren nur noch eine leere Seite anzeigt, liegt das häufig an einem fehlenden PHP-Modul oder einem inkompatiblen Opcache. Der einfache Test mit php -m auf dem neuen Server sollte vor dem Umschalten erledigt werden. `occ` hilft ebenfalls: `occ check` und `occ status` geben Aufschluss, ob die Umgebung als zuverlässig eingestuft wird. Es schadet nicht, diese Diagnose frühzeitig durchzuführen, also bevor man sich in die eigentliche Datensicherung stürzt. Ein fehlendes GraphQL-Modul oder ein nicht installierter Redis-Server ist schnell behoben, ärgerlich ist nur, wenn man es erst nach der Migration merkt.

Der neue Hoster: Worauf kommt es an?

Die Auswahl des künftigen Hoster ist fast so wichtig wie die Migration selbst. Ein guter Anbieter zeichnet sich nicht dadurch aus, dass er die neueste Nextcloud-Version anpreist, sondern dass er klare, überprüfbare Aussagen zu Betrieb und Support machen kann. Dazu zählt insbesondere das Rechenzentrum. Wer seine Daten in Deutschland oder Österreich belassen möchte, sollte einen Anbieter wählen, der dies vertraglich garantiert. Ein schöner Webshop mit SEO-Texten ist noch kein Beweis für eine saubere Infrastruktur. Es ist daher keine Schande, den Support vor einer Buchung mit fachlichen Fragen zu löchern. Anbieter, die bei Fragen zu PHP-Versionen oder Backup-Strategien ausweichen, sind in meinen Augen verdächtig.

Ein weiterer Punkt ist die Skalierbarkeit. Wächst die Instanz, benötigt man womöglich mehr RAM, mehr CPU und noch mehr Speicherplatz. Ein Hoster, der Festplatten-Kapazität nur in festen Paketen anbietet, ist dann weniger flexibel als einer, der ein Cloud-basiertes Setup mit „Pay-as-you-grow“-Modellen ermöglicht. Für die meisten Teams ist die Frage der Datenkapazität allerdings weniger kritisch als die Frage der Backup-Garantien. Wie oft werden Backups erstellt? Werden sie im gleichen Rechenzentrum oder georedundant gelagert? Kann im Ernstfall eine Wiederherstellung einzelner Dateien oder des gesamten Systems erzwungen werden? Diese Fragen sollten im Vertrag klar beantwortet sein. Ebenso sollten die Bedingungen für die Kündigung festhalten, dass die Daten exportiert werden können, zum Beispiel per `occ`, File-Sync oder Datenbank-Dump. Ein guter Hoster hat kein Interesse daran, Daten „einzuschließen“. Er erleichtert einen späteren Wechsel ausdrücklich.

Der Kostenfaktor ist nicht zu unterschätzen, aber er sollte nie das einzige Kriterium sein. Ein Billig-Hoster, der Nextcloud als einfaches PHP-Skript auf einem Webspace ablegt, spart zwar Geld, aber es fehlen oft zentrale Funktionen wie Echtzeitmeldungen, Hintergrundjobs, Redis-Cache oder ein sauberer Cron-Dienst. Ohne einen korrekt eingerichteten Cron laufen viele Nextcloud-Apps wie Talk oder Push-Benachrichtigungen nur mittelmäßig. Die Folge sind langsamer Sync und veraltete Aktivitätsfeeds. Auf einem gemanagten Nextcloud-Server sollte dies problemlos funktionieren; auf einem simplen Webhosting ist es mitunter Glückssache, ob der Hoster die Hintergrundjobs so konfiguriert, wie es Nextcloud benötigt. Wer solche Details ignoriert, wird sich nach dem Wechsel über eine träge Instanz wundern, obwohl das Problem nicht am Netz, sondern am unzureichenden Server-Set-Up liegt.

Nicht zuletzt spielt die Region eine Rolle, in der die Daten verarbeitet werden. In der EU gilt die DSGVO, aber nicht jeder Serverbetreiber in der EU ist automatisch DSGVO-konform, und nicht jedes Rechenzentrum in Dresden ist besser als eines in Amsterdam oder Zürich. Wer sensible Kundendaten verarbeitet, sollte die Serverstandorte und die Vertragsbedingungen genau prüfen. Manchmal ist der Server physisch in Deutschland aufgestellt, aber der Anbieter nutzt zur Verwaltung Zugriff von einem Team außerhalb der EU. Das mag im Einzelfall zulässig sein, wenn Standardvertragsklauseln greifen, aber es zeigt, dass die einfache Frage des Standorts längst nicht mehr alles ist.

Fazit: Planung schlägt brachialen Aktionismus

Ein Hosterwechsel bei Nextcloud ist kein Hexenwerk, aber eine Aufgabe, die man nicht unterschätzen sollte. Wer sich die Zeit für eine saubere Bestandsaufnahme nimmt, die neue Umgebung exakt vorbereitet und die Migration mit Wartungsmodus, `occ`, `rsync` und einer klaren Testroutine durchführt, wird das Vorhaben ohne großen Schaden überstehen. Das Wichtigste ist die innere Haltung: Der Vorgang ist eine geplante Operation, kein Blindflug. Die Mischung aus großzügigem Zeitpuffer, sorgfältigen Tests und einer funktionierenden Kommunikation mit den Nutzern macht am Ende deutlich weniger Stress.

Ein Wechsel kann eine gute Gelegenheit sein, nicht nur die Infrastruktur zu modernisieren, sondern auch die Organisation der Nextcloud-Instanz aufzuräumen. Überflüssige Apps werden deinstalliert, eine saubere Ordnerstruktur eingeführt, unnötige Dateien gelöscht. Viele Teams nutzen genau diesen Moment, um endlich eine Backup-Strategie zu implementieren, die zuvor nur in der Theorie existierte. Und wenn der neue Hoster besser erreichbar ist als der alte und die Leistungsdaten stimmen, dann vergisst das Team die Migration schnell. Die alltägliche Zusammenarbeit läuft einfach weiter – was letztlich das Ziel jeder Cloud-Infrastruktur sein sollte: Technik in den Hintergrund zu rücken und den Menschen die Werkzeuge zu geben, die sie brauchen. Dass diese Werkzeuge ab und zu umziehen müssen, gehört zum Geschäft digitaler Infrastruktur – nicht mehr und nicht weniger.