Nextcloud Datenimport der stille Umzug meistern

Der stille Umzug: Warum der Datenimport in Nextcloud oft zur Geduldsprobe wird

Wer sich für Nextcloud entscheidet, hat meist gute Gründe: Datenhoheit, flexible Erweiterbarkeit, Open‑Source‑Philosophie. Doch bevor die neue Plattform ihre Stärken ausspielen kann, steht eine kaum zu umgehende Hürde: der Import der Altlasten. Ob aus einer veralteten OwnCloud‑Instanz, von einem SharePoint‑Server, aus Google Drive oder einer lokalen Dateiablage – der Transfer großer Datenmengen in Nextcloud ist kein Spaziergang. Die Software selbst macht dabei vieles richtig, aber die Praxis zeigt: Wer nicht vorbereitet ist, verzweifelt an Timeouts, inkonsistenten Metadaten oder schlicht an der schieren Menge an Dateien.

Dieser Artikel richtet sich an all jene, die den Umzug nicht dem Zufall überlassen wollen – Administratoren, Entscheider und Techniker, die verstehen möchten, was unter der Haube passiert, wenn Terabyte an Daten in ein neues System wandern. Dabei geht es nicht um eine sterile Kommando‑für‑Kommando‑Anleitung, sondern um die Prinzipien, Fallstricke und bewährten Strategien, die einen erfolgreichen Datenimport ausmachen. Denn eines ist klar: Nextcloud ist kein Black‑Box‑Speicher, sondern ein lebendiges Ökosystem, das den Import mitdenkt – aber nur dann, wenn man seine Werkzeuge richtig einsetzt.

Das fundamentale Problem: Nextcloud ist nicht einfach ein Dateisystem

Der größte Fehler, den man bei einem Import machen kann, ist die Annahme, man könne die Daten einfach per rsync oder scp in das Datenverzeichnis der Nextcloud‑Installation kopieren und dann einmal occ files:scan ausführen. Zwar funktioniert dieser Weg technisch, doch er ignoriert die interne Logik der Plattform. Nextcloud speichert nicht nur die reinen Dateien, sondern auch Metadaten wie Freigaben, Kommentare, Versionen, Tags und Einstellungen in der Datenbank. Diese Verknüpfungen lassen sich nicht nachträglich aus einem simplen Dateibaum rekonstruieren.

Hinzu kommt das Konzept der „Mounts“: Nextcloud kann externe Speicher anbinden – von SMB‑Shares über S3‑Buckets bis zu FTP‑Servern. Werden Daten manuell in den primären Storage (meist ein lokaler Ordner mit einer bestimmten Verzeichnisstruktur) kopiert, fehlt die Zuordnung zu diesen Mounts, falls die Quelle einmal von einem externen Speicher stammt. Die Konsequenz: Dateien tauchen zwar im Dateisystem auf, aber das Web‑Interface sieht sie nicht, oder sie erscheinen ohne Besitzer‑Zuordnung. Besonders ärgerlich wird es, wenn Benutzerkonten gelöscht oder umbenannt wurden – dann hängen die Dateien quasi in der Luft.

Noch ein Aspekt, der oft übersehen wird: Die Verschlüsselung auf Dateiebene. Aktiviert man die serverseitige Ende‑zu‑Ende‑Verschlüsselung, greift ein Schlüsselmanagement, das nur über die Datenbank und die Clients funktioniert. Ein simpler Dateitransfer würde die Verschlüsselung zerstören. Auch die integrierten Antiviren‑ und Content‑Prüfungen können bei einem Massenimport unvorbereitet einen Speicher‑ oder CPU‑Kollaps verursachen.

Der erste Grundsatz lautet daher: Ein Datenimport ist immer ein Projekt für sich, das Planung und Testdurchläufe erfordert. Wer glaubt, er könne das an einem Freitagnachmittag nebenbei erledigen, wird am Montagmorgen eine böse Überraschung erleben.

Die Werkzeugkiste: Welche Methoden Nextcloud für den Import bereithält

Nextcloud bietet eine Reihe von offiziellen und inoffiziellen Wegen, Daten ins System zu bekommen. Die Wahl der Methode hängt stark von der Quelle, der Datenmenge und der gewünschten Tiefe der Metadaten‑Übernahme ab.

Der Klassiker: Manuelles Kopieren und erneutes Scannen

Einfach und schnell, aber nur für absolute Notfälle oder leere Installationen geeignet. Man kopiert die Dateien in den Ordner data/username/files. Danach muss man als Administrator occ files:scan --all ausführen. Nextcloud liest dann die Verzeichnisstruktur und trägt die Dateien in die Datenbank ein – allerdings ohne jegliche Benutzerzuordnung für geteilte Ordner, ohne Versionshistorie und ohne Kommentare. Freigaben müssen neu gesetzt werden. Das Verfahren eignet sich also nur für frische Accounts ohne bisherige Nutzung. Wer auf bestehende Benutzerdaten aufspielen will, riskiert Konflikte bei Dateinamen oder die Überschreibung vorhandener Versionen.

Ein kleiner Trick: Mit occ files:scan --path=/username/files/import kann man den Scan auf einzelne Unterverzeichnisse beschränken, was bei großen Migrationsprojekten hilft, den Überblick zu behalten.

Der offizielle Weg: occ data-import und occ files:transfer-ownership

Nextcloud bringt mehrere Kommandozeilen‑Befehle mit, die speziell für Datenimporte gedacht sind. So erlaubt occ data-import (in neueren Versionen) das Einlesen eines Archive‑Imports, der zuvor mit dem data-export‑Befehl erstellt wurde. Die Idee: Man exportiert einen Datensatz aus einer anderen Nextcloud‑Instanz oder einer kompatiblen Quelle und importiert ihn direkt mit allen Metadaten. Leider ist der Befehl noch nicht sonderlich bekannt, und die Exporte benötigen ein einheitliches Format. Für den Eigenbedarf kann das aber eine saubere Lösung sein.

Praktischer im Alltag ist der Befehl occ files:transfer-ownership. Er erlaubt, ganze Dateibäume von einem Benutzer auf einen anderen zu verschieben – inklusive aller Freigaben, sofern der neue Besitzer die entsprechenden Rechte hat. Wer also eine Altdaten‑Sammlung unter einem Administrator‑Account abgelegt hat, kann diese gezielt an die echten Benutzer vererben. Das ist besonders nützlich, wenn man Daten aus einem externen System zunächst in einem temporären Account sammelt und dann verteilt.

Die Import‑Apps: Nextcloud Import/Export und Data Migration

Im Nextcloud App Store gibt es zwei Apps, die den Import erleichtern sollen: Data Migration (vormals bekannt als „Import/Export“) und die etwas neuere Nextcloud Import/Export. Die ersten Versionen waren eher für kleine bis mittlere Datenmengen ausgelegt – ein paar Gigabyte, nicht Terabyte. Sie bieten eine grafische Oberfläche, um Zip‑Archive hochzuladen, die man zuvor mit derselben App aus einer anderen Nextcloud exportiert hat. Die Metadaten werden dabei weitgehend übernommen – zumindest soweit die App das hergibt. In der Praxis zeigt sich jedoch, dass die App bei großen Archiven schnell an ihre Grenzen stößt: PHP‑Timeout, Speicherlimit oder schlicht die Trägheit des Browsers machen das Hochladen mehrerer Gigabyte per Web‑Interface zur Qual.

Besser geeignet ist die App als Backup‑Tool für einzelne Benutzer:innen, die ihre persönlichen Daten sichern und auf einem anderen Server wiederherstellen wollen. Für den unternehmensweiten Import von mehreren hundert Benutzern ist sie weniger tauglich – hier kommt man um die Kommandozeile nicht herum.

Der pragmatische Ansatz: Externe Speicher und lokale Skripte

Ein oft übersehener Weg ist die Einbindung der Quelle als externen Speicher. Nextcloud kann per External Storage‑App auf SMB‑Freigaben, S3‑kompatible Objektspeicher oder WebDAV zugreifen. Wenn die Quelldaten also bereits über ein Netzwerkprotokoll erreichbar sind, kann man sie temporär als externen Speicher einhängen. Anschließend lassen sich die Dateien per Kopierbefehl innerhalb von Nextcloud in den lokalen Storage verschieben – entweder über die Web‑GUI (mühsam) oder per occ‑Befehl, sofern man sich ein Skript schreibt, das die Dateien schrittweise verschiebt.

Der Vorteil: Nextcloud behält die volle Kontrolle über die Metadaten, weil die Dateien über die interne API kopiert werden. Der Nachteil: Der Kopiervorgang läuft über den Webserver und beansprucht Ressourcen. Bei großen Datenmengen kann man das nur nachts oder am Wochenende machen. Ein Workaround besteht darin, die Quelldaten direkt auf dem Storage‑Server in das Nextcloud‑Datenverzeichnis zu mounten – das ist aber wegen der bereits erwähnten Datenbanklogik nur mit anschließendem Scan aller Dateien sinnvoll.

Migration von Fremdsystemen: OwnCloud, SharePoint, Google Drive und Co.

Je nach Herkunft der Daten unterscheiden sich die Anforderungen fundamental. Eine OwnCloud‑Instanz lässt sich oft überraschend einfach nach Nextcloud migrieren, weil beide Systeme architektonisch ähnlich sind. Bei proprietären Diensten wie SharePoint oder Google Drive wird es komplexer – und manchmal schmerzhaft.

OwnCloud nach Nextcloud: Der Königsweg

OwnCloud und Nextcloud haben sich vor Jahren getrennt, aber beide teilen noch viele Code‑Ähnlichkeiten. Ein direkter Upgrade‑Pfad – also das Austauschen der Binärdateien und der Datenbank‑Struktur – ist offiziell nicht mehr vorgesehen, weil die Datenbankschemata inzwischen stark auseinanderlaufen. Dennoch gibt es einen relativ klaren Migrationspfad: Man exportiert die OwnCloud‑Datenbank und das Dateiverzeichnis, startet eine frische Nextcloud und importiert dann die Benutzer und Dateien über die occ‑Befehle. Die Mühe lohnt sich aber nur, wenn man auch die Metadaten (Freigaben, Kommentare, Favoriten) übernehmen will. Andernfalls reicht ein reiner Dateitransfer mit anschließender manueller Freigabe.

Ein interessantes Detail: OwnCloud speichert die Dateien in der gleichen Verzeichnisstruktur unter data/username/files wie Nextcloud. Wenn man also die OwnCloud‑Installation sauber herunterfährt, das Datenverzeichnis auf den neuen Server kopiert und dann mit occ files:scan die Benutzerordner neu einliest, funktioniert das erstaunlich gut. Voraussetzung ist, dass die Benutzerkonten auf der Zielinstanz bereits existieren und exakt dieselben Namen haben. Auch die Datenbank‑Metadaten wie Freigaben lassen sich so nicht übernehmen – dafür bräuchte man eine Extraktion aus der OwnCloud‑Datenbank.

Für Unternehmen mit vielen Benutzern und komplexen Freigabestrukturen empfiehlt sich der Einsatz der OwnCloud to Nextcloud Migration‑App (leider nicht offiziell im Nextcloud Store, aber über GitHub erhältlich). Sie kann die Freigaben aus der OwnCloud‑Datenbank auslesen und in Nextcloud neu anlegen. Der Aufwand ist nicht trivial, aber machbar.

SharePoint, Google Drive, OneDrive: Das große Mapping‑Problem

Wer Daten aus einem Microsoft SharePoint oder einem Google Drive importieren will, steht vor einem grundlegenden Problem: Beide Dienste arbeiten mit anderen Konzepten von Ordnern, Freigaben und Versionen. SharePoint zum Beispiel unterscheidet zwischen Dokumentenbibliotheken und standardmäßigen Ordnern, während Nextcloud ein reines Datei‑ und Ordnermodell verwendet. Auch die Versionierung ist anders strukturiert: SharePoint speichert jede Version eines Dokuments als vollständige Kopie im gleichen Container, Nextcloud hingegen in einer versteckten Versionshistorie. Ein direkter Metadata‑Import ist daher kaum möglich.

Praktikabel ist meist ein zweistufiger Prozess: Zuerst exportiert man die Daten aus dem Quellsystem in eine lokale Verzeichnisstruktur – am besten als flaches, gut organisiertes Dateisystem. Tools wie SharePoint Migration Tool (Microsoft) oder Google Takeout liefern in der Regel ZIP‑Archive oder Ordnerstrukturen, die sich dann per occ‑Scan in Nextcloud importieren lassen. Die Freigaben müssen allerdings neu konfiguriert werden. Auch die Versionsgeschichte geht verloren – es sei denn, man packt jede Version in einen separaten Ordner (was kaum praktikabel ist).

Ein kleiner Tipp für SharePoint‑Migrationen: Die Dokumentenbibliothek lässt sich über WebDAV direkt in Nextcloud als externer Speicher einbinden. Dann kann man die Dateien von dort per copy in den lokalen Nextcloud‑Storage verschieben. Die Performance ist allerdings bescheiden, weil jede Datei den Umweg über den Webserver nimmt. Für ein paar hundert Dateien okay, für Tausende wird es zur Qual.

Google Drive: Die Daten erstmal lokal bündeln

Google Drive kennt ebenfalls keine echten Pfade im Dateisystem – die Ordnerstruktur wird über eine Datenbank abgebildet. Der Export über Google Takeout produziert eine Hierarchie, die oft verschachtelt ist und bei der mehrere Ordner gleiche Namen haben können. Nach dem Herunterladen liegt eine große Menge an Dateien und Ordnern, die nicht immer eindeutig zuzuordnen sind. Hier hilft ein Skript, das die Metadaten aus der Takeout‑Ausgabe extrahiert und die Dateien in eine saubere Baumstruktur sortiert. Erst dann sollte der Import nach Nextcloud beginnen.

Wichtig: Google Drive Dateien, die von mehreren Personen gemeinsam bearbeitet wurden, haben in der Takeout‑Ausgabe keine Informationen über die Freigaben. Das muss später auf der Nextcloud‑Seite neu aufgesetzt werden. Auch Google Docs, Sheets und Slides landen als ODF‑Export (oder PDF) im Archiv – die Kollaborationshistorie und die Kommentare sind futsch.

Die technischen Fallstricke: Timeouts, Speicherplatz und Performance

Selbst mit der richtigen Methode kann der Import ins Stocken geraten. Die häufigsten Probleme sind:

– **Ausführungszeit:** Der occ‑Befehl files:scan hat ein Timeout, das durch die PHP‑Konfiguration (max_execution_time) begrenzt ist. Bei sehr vielen Dateien (mehrere hunderttausend) bricht der Scan nach einer gewissen Zeit ab. Abhilfe: occ files:scan mit der Option –no-cache oder in Etappen über eigene Skripte ausführen. Die Datenbank wird dabei nach und nach befüllt, ohne dass der Vorgang in einem Rutsch geschehen muss.

– **Speicherplatz:** Der Import verdoppelt vorübergehend den Speicherverbrauch, wenn man Daten zunächst in einen temporären Ordner kopiert und dann in die Benutzerbereiche verschiebt. Wer wenig SSD‑Platz hat, sollte auf direkte Datenbewegungen setzen. Auch die Generierung von Thumbnails kann während des Scans viel Speicher kosten – insbesondere bei vielen Bildern. Hier kann man die Thumbnail‑Generierung vorerst deaktivieren und später per cronjob nachholen.

– **Dateinamen und Sonderzeichen:** Nextcloud verwendet UTF‑8, aber viele Altsysteme arbeiten mit anderen Kodierungen, etwa ISO‑8859‑1 oder Windows‑1252. Dateinamen mit Umlauten, Leerzeichen oder Sonderzeichen führen zu Fehlern beim Scan, wenn die Kodierung nicht konsistent ist. Vor dem Import sollte man daher alle Dateinamen und Pfade normalisieren – am besten mit einem Skript, das in UTF‑8 normalisiert (NFC oder NFD, je nach Betriebssystem). Nextcloud unterstützt beide, aber man sollte sich entscheiden und die Metadaten entsprechend anpassen.

– **Symbolische Links und versteckte Dateien:** Nextcloud ignoriert standardmäßig symbolische Links und versteckte Dateien (mit Punkt am Anfang). Wenn die Quelldaten solche Elemente enthalten, werden sie nicht importiert. Das muss man vorher bereinigen oder durch echte Kopien ersetzen.

Automatisierung und Skripting: Der Import im großen Stil

Für den Import von mehreren Dutzend Terabyte und Hunderten von Benutzern kommt man an automatisierter Skripterei nicht vorbei. Hier ein bewährtes Grundgerüst, das sich an die eigenen Gegebenheiten anpassen lässt.

Zuerst erstellt man auf der Nextcloud‑Kommandzeile eine Liste aller Benutzer, für die Daten importiert werden sollen: occ user:list. Dann legt man für jeden Benutzer einen temporären Account an oder nutzt existierende. Die Quelldaten liegen idealerweise in einer Verzeichnisstruktur, die nach Benutzernamen sortiert ist: /imports/benutzername/.

Ein Bash‑Skript durchläuft dann diese Verzeichnisse, kopiert die Daten per cp -a in den entsprechenden data/benutzername/files/import_yyyymmdd‑Ordner und führt anschließend occ files:scan --path="/benutzername/files/import_yyyymmdd" aus. Um die Serverlast zu reduzieren, sollte man zwischen den Scans eine Pause einbauen und gegebenenfalls die Anzahl der parallelen Prozesse begrenzen.

Nach dem erfolgreichen Scan können die Daten entweder im importierten Ordner belassen oder mit occ files:transfer-ownership an den endgültigen Benutzer übertragen werden. Letzteres empfiehlt sich, wenn die Importdaten ursprünglich keine gültigen Benutzerzuordnungen hatten.

Für die Überwachung des Fortschritts bieten sich kleine Logging‑Funktionen an, die die Anzahl der importierten Dateien und Fehler in eine Datei schreiben. Im Fehlerfall (z.B. Dateiname nicht UTF‑8‑konform) sollte das Skript die Datei überspringen und später zur manuellen Prüfung auflisten.

Nach dem Import: Aufräumarbeiten und Qualitätssicherung

Ein Datenimport ist erst dann abgeschlossen, wenn die Integrität der Daten geprüft ist. Nextcloud bietet dafür den Befehl occ integrity:check für die App‑Integrität, aber für die Dateien selbst gibt es keine integrierte Prüfung. Man sollte daher vor dem Import eine Liste der Dateien mit Prüfsummen (z.B. SHA256) erstellen und nach dem Import erneut über das Web‑Interface oder die Datenbank abgleichen – zumindest stichprobenartig.

Weiterhin sollte man die Speicher‑Nutzung pro Benutzer kontrollieren: occ user:info benutzername zeigt die belegte Kapazität. Auch die Freigaben müssen getestet werden: Sind alle Freigaben, die auf dem Altsystem existierten, korrekt abgebildet? Bei manuellen Importen sind sie es nicht – das muss man in der Planung berücksichtigen und entsprechende Ressourcen für die Nacharbeit einplanen.

Ein nicht zu unterschätzender Punkt ist die Performance nach dem Import. Die Datenbank ist mit vielen neuen Einträgen gefüllt, und die Indizes müssen aktualisiert werden. Ein occ maintenance:repair und ein occ db:add-missing-indices sollte man auf jeden Fall durchführen. Bei wirklich großen Datenmengen (Millionen von Dateien) kann es sinnvoll sein, die Datenbank‑Engine von MySQL auf PostgreSQL zu wechseln, weil die Indizierung und die Query‑Performance dort oft besser skaliert.

Nextcloud All‑in‑One und Import: Der bequeme Weg mit Grenzen

Seit einiger Zeit propagiert Nextcloud die All‑in‑One‑Instanz (AIO), die als Docker‑Container ausgeliefert wird und viele Konfigurationsschritte automatisiert. Auch für den Import gibt es gute Nachrichten: AIO stellt über das sogenannte „Mastercontainer“‑Interface einen einfachen Zugriff auf die occ‑Befehle zur Verfügung. Man kann direkt im Browser die Befehle ausführen oder sich per Shell im Container verbinden.

Allerdings erbt AIO auch die Einschränkungen der Docker‑Umgebung: Das Datenverzeichnis ist in einem Volume gemountet, und direkte Zugriffe auf die Dateien sind nur über einen Extra‑Docker‑Container oder über die Kommandozeile des Hosts möglich. Für den Import kann man die Quelldaten in einen temporären Order innerhalb des Containers kopieren (z.B. /var/www/html/data/import) und dann wie gewohnt scannen.

Ein spezielles Feature von AIO ist die Integration des „Nextcloud Import/Export“‑Formats. Über die Systemkonsole kann man eine Sicherung der gesamten Instanz erstellen und auf einem anderen AIO‑System wiederherstellen. Das eignet sich hervorragend für den Umzug von einer Testinstanz auf den Produktionsserver – aber nur, wenn das Quellsystem ebenfalls AIO ist. Für den Import aus Fremdsystemen hilft auch AIO nicht weiter.

Exotische Quellen und Sonderfälle

Nicht jeder Import stammt von einer Cloud‑Plattform. Manchmal müssen Daten von einem NAS, einer alten Windows‑Freigabe oder sogar von einem Tape‑Backup in Nextcloud landen. In solchen Fällen ist die größte Hürde die Ingest‑Geschwindigkeit.

Netzwerkfreigaben per SMB sind oft langsam, besonders wenn über WAN gearbeitet wird. Hier sollte man vorab das lokale Netzwerk prüfen und gegebenenfalls die Daten erst auf einen Zwischenspeicher (SSD im Server) kopieren, bevor der Import startet. Auch das Mounten per NFS ist meist effizienter als SMB.

Ein weiterer Sonderfall sind Archive mit sehr vielen kleinen Dateien (z.B. Log‑Exporte oder E‑Mail‑Archive). Nextcloud ist nicht für Millionen winziger Dateien optimiert – der Overhead der Datenbank‑Einträge und der Thumbnail‑Generierung wird schnell zum Flaschenhals. In solchen Fällen sollte man die Daten vor dem Import zu größeren Paketen (ZIP, TAR) zusammenfassen oder in Nextcloud als „Archive“ speichern, die nicht individuell indexiert werden müssen. Je nach Use‑Case kann auch die Umstellung auf einen S3‑kompatiblen Objektspeicher helfen, weil dort die Metadaten weniger aufwendig sind.

Darf man das überhaupt? Lizenz‑ und Datenschutzaspekte

Ein oft unterschätzter Punkt beim Datenimport ist die rechtliche Seite. Wer Daten aus einem externen Dienst wie Google Drive oder SharePoint exportiert, muss sicherstellen, dass die Lizenz‑ und Nutzungsbedingungen des Quellsystems den Export erlauben. Bei Google Workspace ist das in der Regel der Fall, bei manchen SaaS‑Anbietern kann es jedoch Beschränkungen geben, etwa wenn Daten aus einer Branchensoftware stammen, die an die Plattform gebunden sind.

Weiterhin sollten die Datenschutz‑Grundverordnung (DSGVO) und eventuelle Betriebsvereinbarungen beachtet werden. Bei Cloud‑to‑Cloud‑Migrationen ist es nicht ungewöhnlich, dass personenbezogene Daten in Kopie vorliegen; der Transport muss verschlüsselt erfolgen. Nextcloud unterstützt verschlüsselte Verbindungen (HTTPS, SFTP, WebDAV über TLS) – das sollte man nutzen. Auch die Logging‑Mechanismen des Imports sollten keine unnötigen Daten preisgeben.

Ein Tipp aus der Praxis: Vor dem Import sollte man die Datenschutz‑Folgenabschätzung der Migration durchführen, vor allem, wenn die Zielinstanz in einer anderen Jurisdiktion betrieben wird. Das ist kein rein technisches Thema, aber ein verantwortungsvoller Administrator sollte es auf dem Schirm haben.

Die Frage der Nachhaltigkeit: Import als Projekt organisieren

Vielleicht der wichtigste Ratschlag: Nehmen Sie sich Zeit. Unterschätzen Sie nicht, wie lange ein Datenimport dauert – nicht nur die Übertragung selbst, sondern auch die Nachbearbeitung. Ein typisches Projekt (50 Benutzer, 500 GB Daten, gemischte Quellen) kann inklusive Planung, Testphase und Qualitätssicherung zwei bis drei Wochen in Anspruch nehmen. Bei mehreren Terabyte werden daraus schnell mehrere Monate, wenn nebenbei der Produktivbetrieb nicht gestört werden soll.

Teilen Sie den Import in Phasen ein: Zuerst eine Testgruppe mit einem Dutzend Benutzern, dann die restlichen Accounts nach und nach. Legen Sie einen Zeitplan fest, an dem die Benutzer über den Umzug informiert werden. Bieten Sie Schulungen oder zumindest eine Anleitung an, wie sie nach dem Import ihre Daten wiederfinden.

Und nicht zuletzt: Dokumentieren Sie jeden Schritt. Denn spätestens beim nächsten Import (und der kommt garantiert, weil Firmen wachsen, sich neu organisieren oder von einem anderen Dienst umziehen) wird man auf die gemachten Erfahrungen zurückgreifen wollen.

Fazit: Kein Allheilmittel, aber machbar

Nextcloud ist kein „plug and play“‑System, wenn es um Datenimporte geht. Das klingt erstmal nach einem Manko, ist aber eigentlich eine Stärke: Wer die internen Abläufe kennt, kann den Import so steuern, dass Daten nicht nur ankommen, sondern auch nutzbar sind. Die Unterschiede zu proprietären Diensten zeigen sich gerade in diesem Punkt: Während Google oder Microsoft die Migration oft als Black‑Box anbieten, kann der Nextcloud‑Administrator jeden Schritt selbst beeinflussen – von der Kodierung der Dateinamen bis zur Verteilung der Freigaben.

Der Preis für diese Freiheit ist Aufwand. Aber ein gut geplanter Import ist kein Hindernis, sondern die Basis für eine nachhaltige, souveräne Datenhaltung. Nextcloud selbst verbessert seine Import‑Werkzeuge kontinuierlich – die occ‑Befehle und die Import‑Apps reifen von Version zu Version. Für den Moment gilt: Wer die Grundprinzipien versteht, sich auf die wichtigsten Werkzeuge beschränkt und nicht an der falschen Stelle spart (Zeit, Speicher, Testläufe), wird am Ende ein System haben, das den Namen „Datenplattform“ wirklich verdient.

Und vielleicht ist genau das der Reiz: Ein bisschen Handarbeit, ein wenig Skripting, und schon entsteht aus einem Haufen alter Dateien eine strukturierte, durchsuchbare, gemeinsam nutzbare Umgebung – die Nextcloud eben.