phpBB 3.3 (Proteus) wird auch 2026 noch supported — Sicherheitsupdates laufen, die Codebasis ist stabil, und für viele kleinere Communities reicht das. Aber das Entwicklungs-Tempo hat sich sichtbar verlangsamt: das letzte Feature-Release 3.3.11 erschien Anfang 2024, größere Architektur-Sprünge in Richtung Long-Read-Threads, Trust-Levels und mobile-first sind nicht in Sicht. Discourse 3.4 (Anfang 2025) liefert genau diese Architektur out of the box. Wer den Wechsel plant, steht vor einer Migration, die technisch lösbar, aber an mehreren Stellen schmerzhaft ist. Dieser Artikel ist die Schritt-für-Schritt-Anleitung.

Schritt 1: phpBB-Daten-Export

Die phpBB-Datenbank ist die Quelle. Vor allem brauchst du:

• phpbb_users — User-Konten mit user_password (md5-/bcrypt-Hash)
• phpbb_forums — Kategorie-Struktur
• phpbb_topics — Thread-Köpfe
• phpbb_posts — Einzelposts mit BBCode-Text
• phpbb_attachments und phpbb_attachments_desc — Anhänge
• phpbb_user_group und phpbb_groups — Gruppen und Permissions
• phpbb_acl_* — Access Control Lists

Ein vollständiger SQL-Dump auf dem Live-System:

mysqldump --single-transaction --routines --triggers \
  -u root -p phpbb_prod > phpbb_dump_2026-06-01.sql

Auf einer Staging-Maschine eine identische Kopie importieren — alle weiteren Schritte laufen gegen die Kopie, nicht gegen die Produktion. Discourse erwartet später eine JSON-Repräsentation; den Konvertierungs-Layer schreibt das offizielle Discourse-Import-Script.

Schritt 2: Discourse-Import-Script

Discourse pflegt im Hauptrepo unter script/import_scripts/ ein Verzeichnis von Importern. Für phpBB existiert seit Jahren der Importer phpbb3.rb. Er ist in Ruby geschrieben und läuft direkt in der Discourse-Rails-Umgebung. Konfiguration über eine YAML:

# phpbb_settings.yml
database:
  host: localhost
  username: root
  password: ***
  database: phpbb_staging
  table_prefix: phpbb_
import:
  site_name: "Mein Forum"
  trust_level_for_users_with_posts: 2

Lauf:

cd /var/www/discourse
RAILS_ENV=production bundle exec ruby \
  script/import_scripts/phpbb3.rb phpbb_settings.yml

Auf einer 50.000-Post-Datenbank dauert der Import realistisch zwischen vier und zwölf Stunden, abhängig von Anhang-Volumen und Disk-IO. Plan eine ungestörte Nacht ein.

Schritt 3: User-Account-Migration und Passwort-Reset-Welle

Hier kommt der erste echte Schmerzpunkt. phpBB hat historisch md5-Hashes verwendet, ab 3.1 dann eine eigene bcrypt-Variante ($2a$). Discourse nutzt ausschließlich bcrypt mit eigenem Cost-Faktor. Das heißt:

• md5-Hashes lassen sich nicht in Discourse importieren. Die User müssen ihr Passwort neu setzen.
• phpBB-bcrypt-Hashes ($2a$10$…) sind theoretisch kompatibel mit Discourse-bcrypt, das Discourse-Import-Script importiert sie als „temporäre Passwörter” und markiert die Konten für einen empfohlenen Reset.

In der Praxis fährt jede phpBB-zu-Discourse-Migration eine Passwort-Reset-Mail-Welle. Sauberster Weg:

1. Alle User mit requires_password_reset = true markieren.
2. Beim ersten Login wird der „Passwort zurücksetzen”-Flow erzwungen.
3. Parallel eine Ankündigungs-Mail vorab senden („Wir wechseln am Datum X auf eine neue Plattform, du bekommst dann eine Reset-Mail”).

Die Reset-Mail-Welle ist ein heikler Moment — bei großen Foren (>10.000 User) erwartet dich eine 20-40 Prozent Bounce-Rate aus alten ungenutzten Accounts. Plan SMTP-Throttling ein (max 100 Mails/Minute), sonst landen die Mails als Spam markiert.

Schritt 4: URL-Struktur-Mapping und 301-Redirects

phpBB-URLs sehen aus wie viewtopic.php?t=123&start=15. Discourse-URLs sind /t/<slug>/<id>/<post-number>. Jeder bestehende Backlink von außen muss umgeleitet werden, sonst verlierst du den SEO-Trust deines Forums.

Der Discourse-Importer schreibt eine Mapping-Tabelle migration_mapping in die Discourse-Datenbank:

SELECT
  original_id  AS phpbb_topic_id,
  discourse_id AS discourse_topic_id,
  slug
FROM migration_mapping
WHERE type = 'topic';

Aus dieser Tabelle generierst du eine nginx-Map-Datei:

map $arg_t $discourse_topic_path {
  default              "/";
  123                  "/t/willkommen-im-neuen-forum/4567";
  124                  "/t/regeln-und-faq/4568";
  ...
}

server {
  listen 80;
  server_name altes-forum.example.com;

  location = /viewtopic.php {
    return 301 https://forum.example.com$discourse_topic_path;
  }
}

Für Post-Anker (#p456) erweiterst du die Map um die Post-Nummer-Mapping aus migration_mapping mit type = 'post'. Discourse-URL-Format dann /t/<slug>/<topic-id>/<post-number-in-topic>.

viewforum.php?f=N mapst du analog auf Discourse-Categories (/c/<slug>/<id>).

Eine vollständige Map für ein 5.000-Topic-Forum hat 5.000 bis 10.000 Zeilen — das nginx-Format ist mit dieser Größe problemlos im RAM.

Schritt 5: Anhang- und Attachment-Migration

phpBB speichert Anhänge unter files/ im Forum-Root mit kryptischen Dateinamen wie 1234_abcdef1234567890. Die zugehörigen Metadaten (originaler Dateiname, MIME-Type) stehen in phpbb_attachments. Discourse erwartet Uploads unter public/uploads/default/original/<2-stelliger-hex>/.

Der phpBB-Importer kopiert die Dateien automatisch, wenn du den Pfad in der YAML-Konfiguration setzt:

files:
  base_dir: "/var/www/phpbb/files"

Achtung bei Image-Anhängen: Discourse erzeugt automatisch optimierte Varianten (thumbnail, lightbox, retina). Bei einem 8 GB phpBB-Attachment-Verzeichnis kann der Import auf 18-22 GB Discourse-Storage anwachsen, weil pro Bild bis zu vier Resize-Varianten erstellt werden.

Schritt 6: Permission- und Group-Migration

phpBB-Gruppen mit ACLs werden auf Discourse-Trust-Levels und Discourse-Gruppen abgebildet — keine 1:1-Übersetzung. Die typische Mapping-Konvention:

phpBB-Gruppe	Discourse-Mapping
Administratoren	admins-Gruppe + Trust Level 4
Globale Moderatoren	moderators-Gruppe + Trust Level 4
Moderatoren (Forum-spezifisch)	Category-Moderator + Trust Level 3
Registrierte Benutzer	Trust Level 0-2 nach Aktivität
Bots	bots-Gruppe, kein Posting-Recht

Trust-Level werden vom Importer nach Post-Anzahl initial gesetzt (trust_level_for_users_with_posts in der YAML). Feinere Anpassungen passieren manuell nach dem Import.

Schritt 7: SEO-Konservierung

Das URL-Mapping aus Schritt 4 ist die Hälfte. Dazu kommen:

• Sitemap-Submission. Discourse generiert unter /sitemap.xml automatisch eine Sitemap. Diese in der Google Search Console und Bing Webmaster Tools neu submitten — die alte phpBB-Sitemap (sitemap_index.xml) als „entfernt” markieren.
• robots.txt. phpBB-spezifische Disallows (/posting.php, /ucp.php) entfernen, Discourse-spezifische einsetzen (Discourse generiert eine eigene robots.txt).
• Canonical-Tags. Discourse setzt korrekte Canonicals automatisch. Falls du eine alte CDN-Sub-Domain hattest (cdn.altes-forum.example.com), die CNAMEs auf den neuen Discourse-CDN umstellen.
• Search Console: Adressänderung. Wenn die Domain wechselt (forum.altedomain.de → community.neuedomain.de), nutze das Tool „Adressänderung” in der Search Console.

Mit korrektem 301-Mapping und Sitemap-Submission bleiben in der Regel 85-95 Prozent des organischen Traffics innerhalb von 60 Tagen erhalten.

Typische Probleme und ihre Lösungen

Custom-BBCode-Verlust

phpBB erlaubt Custom-BBCodes via Admin-Panel — [spoiler], [quote=…], [code=php]. Der Discourse-Importer konvertiert die Standard-Codes, aber Custom-BBCodes werden als Roh-Text importiert. Lösung: vor dem Import eine Liste der Custom-BBCodes ziehen und im Importer-Script eigene Regex-Konvertierungen ergänzen — Discourse nutzt Markdown plus eigene Erweiterungen ([details=…] für Spoiler).

Avatar-Image-Resize

phpBB-Avatare sind oft 90x90 Pixel und in images/avatars/upload/ abgelegt. Discourse erwartet quadratische Avatare in 120x120 (für Retina). Der Importer macht den Resize automatisch, aber die Qualität von 90px-Hochskalierung auf 120px ist sichtbar schlechter. Plan: User per Banner-Nachricht auffordern, Avatare neu hochzuladen.

Fehlende Discourse-Plugins für phpBB-spezifische Features

phpBB-Subscriptions, phpBB-Gallery-MOD, phpBB-Garage (für Auto-Foren) und ähnliche Mods haben keine 1:1-Discourse-Entsprechung. Vor der Migration prüfen, welche Plugins eure Community aktiv nutzt — für die meisten gibt es Discourse-Plugins (Discourse Calendar, Discourse Gallery), aber nicht für alle. Was nicht migriert wird, sollte vor dem Cutover dokumentiert und mit der Community kommuniziert werden.

Test-Phase mit Staging-Instanz

Mindestens zwei vollständige Migration-Durchläufe auf einer Staging-Discourse-Instanz fahren, bevor der Live-Cutover passiert. Die zweite Migration ist der Lerngewinn aus der ersten — typischerweise findest du im ersten Lauf 5-10 Edge-Cases (kaputte UTF-8-Encodings in alten Posts, gelöschte User mit verwaisten Posts, doppelte E-Mail-Adressen).

Ein realistischer Zeitplan für ein 50.000-Post-Forum mit 3.000 aktiven Usern:

• Woche 1-2: Staging aufsetzen, erste Test-Migration
• Woche 3: URL-Mapping erstellen, Edge-Cases fixen
• Woche 4: Zweite Test-Migration, Beta-User-Test mit 10 Freiwilligen
• Woche 5: Ankündigung an die Community, Reset-Mail-Welle vorbereiten
• Wochenende X: Live-Cutover (phpBB read-only schalten, finale Migration, DNS-Switch)
• Woche 6-8: Nachjustierung, Support-Welle bearbeiten

Fazit

Eine phpBB-zu-Discourse-Migration ist machbar, aber kein Wochenend-Projekt. Die technischen Schritte sind klar definiert, die menschlichen Schritte (Passwort-Reset-Welle, Community-Kommunikation, Trust-Level-Tuning) dauern länger als der eigentliche Import. Wer 2026 mit dem Gedanken spielt, plant ein Quartal ein — und gewinnt damit eine Plattform, die für die nächsten fünf Jahre architektonisch tragfähig ist.