Irgendwann steht jede gewachsene Community vor einem Umzug: der alte Server wird zu klein, die Engine wird nicht mehr gepflegt, oder das Diskussionsformat passt nicht mehr. Ein Umzug ist kein Klick — es ist ein Projekt mit klarer Reihenfolge. Wer sie einhält, verliert weder Daten noch die über Jahre aufgebaute Sichtbarkeit in Suchmaschinen.

Zuerst: Was genau ziehst du um?

Es gibt zwei grundverschiedene Szenarien, die oft verwechselt werden.

• Server-Umzug bei gleicher Engine. Du bleibst bei phpBB oder Flarum, wechselst nur die Maschine. Das ist die leichtere Übung: Datenbank-Dump, Dateien, Konfiguration übertragen, DNS umstellen.
• Engine-Wechsel. Du migrierst von phpBB nach Discourse oder Flarum. Hier werden Datenmodelle übersetzt, BBCode wird zu Markdown, Benutzerkonten und Rechte werden neu abgebildet. Das ist ein Datenmigrations-Projekt, kein Kopiervorgang.

Kläre zuerst, in welchem Szenario du bist — davon hängt alles Weitere ab.

Die goldene Regel: erst auf einem Staging-System

Migriere niemals direkt auf der Produktivseite. Setze eine Kopie auf einer separaten Umgebung auf und spiele den kompletten Ablauf dort durch. So findest du BBCode-Reste, kaputte Anhänge und verwaiste Verweise, bevor sie live sichtbar werden — und du kannst den Ablauf so oft wiederholen, bis er reibungslos läuft.

Ein realistischer Testlauf braucht echte Daten: importiere den vollständigen Datenbestand, nicht nur ein paar Beispiel-Threads. Randfälle — sehr lange Themen, Beiträge mit exotischen Anhängen, gelöschte oder gesperrte Nutzer — sind genau die Stellen, an denen Importer stolpern.

Backups: drei, nicht einer

Vor dem Stichtag brauchst du einen konsistenten, wiederherstellbar getesteten Backup-Stand:

1. Ein vollständiger Dump der Datenbank.
2. Alle hochgeladenen Dateien und Anhänge (bei vielen Engines in einem separaten Verzeichnis).
3. Die Konfigurationsdateien und individuellen Anpassungen.

Ein Backup, das du nie zurückgespielt hast, ist kein Backup, sondern eine Hoffnung. Teste die Wiederherstellung mindestens einmal auf dem Staging-System.

Die Datenübertragung

Beim reinen Server-Umzug überträgst du Datenbank und Dateien, passt die Konfiguration an die neuen Pfade und Zugangsdaten an und prüfst Dateirechte. Wichtig ist, dass Zeichensätze zusammenpassen — ein Dump in einem anderen Encoding produziert sonst Umlaut-Salat in tausenden Beiträgen.

Beim Engine-Wechsel nutzt du die offiziellen Importer. Discourse bringt Skripte für phpBB und weitere Quellen mit, und auch Flarum hat Migrationswerkzeuge. Rechne damit, dass sie nicht alles übernehmen: private Nachrichten, benutzerdefinierte Ränge, Signaturen oder Reaktionsdaten fallen je nach Werkzeug teilweise heraus. Liste vorher auf, was für deine Community unverzichtbar ist, und prüfe jeden dieser Punkte nach dem Testimport gezielt.

Der teuerste Fehler: URLs wegwerfen

Deine bestehenden Themen-URLs sind über Jahre in Suchmaschinen, Lesezeichen und externen Verlinkungen verankert. Ändert der Umzug die URL-Struktur, brechen diese Links — und mit ihnen ein großer Teil des organischen Traffics.

Die Lösung sind 301-Weiterleitungen von den alten auf die neuen Adressen. Erstelle eine Zuordnungstabelle (alte Thema-ID → neue URL) und richte serverseitige Redirects ein. Genau dieser Schritt wird beim Engine-Wechsel am häufigsten vergessen und ist am teuersten nachzuholen. Plane ihn von Anfang an ein.

Der Stichtag

Wenn Staging sauber läuft, planst du das eigentliche Umschalten:

• Kündige eine Wartungspause an und aktiviere sie rechtzeitig, damit während der Migration keine neuen Beiträge im alten System entstehen, die verloren gingen.
• Zieh einen finalen, frischen Datenstand — nicht den vom Vortag.
• Führe den geprobten Ablauf aus.
• Stelle DNS beziehungsweise den Webserver auf die neue Instanz um.
• Kontrolliere Redirects, Login, Suche, Bilder und Benachrichtigungs-Mails, bevor du die Wartungspause aufhebst.

Nach dem Umzug

Die ersten Tage sind Beobachtungszeit. Behalte die Server-Last, die Fehler-Logs und die Rückmeldungen der Mitglieder im Auge. Prüfe in der Suchmaschinen-Konsole, ob die alten URLs sauber weiterleiten und ob Crawling-Fehler auftauchen. Halte das alte System noch einige Wochen als Referenz vorrätig, bevor du es endgültig abschaltest.

Ein gut vorbereiteter Umzug ist für die Mitglieder fast unsichtbar. Genau das ist das Ziel: Am Ende soll niemand merken, dass unter der Haube alles neu ist — außer, dass es schneller läuft.