presseportale/dev/archive/migration-2026

Migration 2026 – Pressekonto Backend

Migration des Backends der beiden Legacy-Portale presseecho und businessportal24 (Symfony 1.4, PHP 5.6) in ein gemeinsames, modernes Laravel 12 Backend unter der Domain pressekonto.test / pressekonto.de.

Start: 23.04.2026 Lead-Technologie: Laravel 12 · PHP 8.4 · Livewire 4 · Volt · Flux UI 2 · Tailwind CSS 4 · MySQL 8 Quell-Projekt: /_businessportal24.com/ (Symfony 1.4 / Doctrine 1 / PHP 5.6) Ziel-Projekt: / (dieses Repository)

---

Kontext in einem Absatz

Historisch existieren zwei technisch identische Symfony-1.4-Installationen (presseecho und businessportal24), die auf zwei verschiedenen Servern mit zwei getrennten Datenbanken laufen. Im neuen Setup werden beide Front-Seiten über ein gemeinsames Laravel-Backend gesteuert. Das Backend verantwortet User-, Firmen-, Kontakt-, Pressemitteilungs-, Kategorie-, Rechnungs-, Zahlungs- und Newsletter-Verwaltung sowie die REST-API, an der die beiden Front-Seiten und Dritt-Clients hängen.

---

Dokumentstruktur

#	Dokument	Zweck
00	OVERVIEW	Kontext, Scope, Ziele, Erfolgskriterien
01	LEGACY-ANALYSIS	Inventar des Symfony-1.4-Backends (Module, Models, Routes, Plugins)
02	TARGET-ARCHITECTURE	Laravel 12 Zielarchitektur (Struktur, Schichten, Konventionen)
03	MIGRATION-PLAN	Phasenplan mit priorisierten Aufgaben
04	DATA-MODEL	Mapping Doctrine-Schema → Eloquent-Models
05	DATABASE-MERGE	Zusammenführung der zwei Legacy-Datenbanken
06	FEATURES-SCOPE	Feature-Matrix: IN / OUT / ANGEPASST
07	API-MIGRATION	API-Endpoints, API-Keys → Sanctum
08	PROGRESS	Laufendes Fortschrittslog
09	REVIEW-QUALITAET	Qualitätsreview vom 2026-04-27; später teilweise behoben
10	LEGACY-API-KUNDEN	API-Kundenreport, Freigabelogik und Kommunikationsrisiko

---

Schnellüberblick: Zahlen & Fakten (aus der Legacy-Analyse)

• 40 Symfony-Module (Admin + Frontend + API + Cron)
• ~30 Doctrine-Entitäten (plus i18n-Tabellen, Ref-Tables, sfGuard-*)
• 12 Plugins, davon fachlich relevant: PressePortalPlugin, sfDoctrineGuardPlugin, sfDoctrineGuardPaymentPlugin
• 2 Cron-Jobs: Rechnungserstellung, Mahnwesen, Recurring-Payments
• REST-API auf Basis eines statischen api_key-Feldes im User-Profil
• DB-Dumps (2026-04-23): businessportal24 42 Tabellen / 578 MB, presseecho 43 Tabellen / 369 MB – 41 Tabellen sind strukturell identisch, 3 abweichend (press_release_image_old nur BP24, category_pe_data + press_release_pe_data nur PE)

Aktueller Implementierungsstand (Code-Abgleich 2026-04-29):

• ✅ Domain-basiertes Theme-System (pressekonto / presseecho / businessportal24)
• ✅ Admin-UI mit echten Daten für Dashboard, Users/Roles, Companies, Contacts, Categories-Index und PressRelease-CRUD/-Workflow
• ✅ Auth-Stack: Fortify, Sanctum, Spatie/Permission
• ✅ Admin-Schutz und Portal-Scoping: EnsureUserIsAdmin, SetCurrentPortal, PortalScope, Sidebar-Portal-Switcher
• ✅ Customer-Portal-Grundumfang: eigene Pressemitteilungen, Legacy-Rechnungsarchiv, API-Token Self-Service, Profilansicht
• ✅ Eloquent-Modelle, Migrations, Factories und Seeder für den Kernbestand
• ✅ Daten-Migration P6-Kern: wiederholbarer legacy:import, Rechnungsarchiv, Timestamps-Fix, legacy:verify
• ✅ API v1 P7: Sanctum, Kernendpoints, Legacy-Key-410, OpenAPI, Usage-Logging, Rate-Limit, API-Kundenreport
• ✅ Dual-Vite-Setup (Portal + Web)

Weiterhin offen / releasekritisch:

• ⬜ P8 Stripe/Billing/Invoicing: Checkout, Webhooks, neue Rechnungen, Invoice-PDF, Grandfathering
• ⬜ Medienübernahme: Legacy-Bilddateien, Thumbnail-/Redirect-Strategie, Logo-Varianten
• ⬜ Go-Live-Ops P9–P11: Queue-/Worker-Betrieb, Staging-Rehearsal, DNS-/Read-only-Cutover, finale Kommunikation
• ⬜ API-Kundenfreigabe: viele Legacy-API-User benötigen manuelle fachliche Prüfung, siehe 10-LEGACY-API-KUNDEN.md

---

Arbeitsweise

1. Vor jeder Phase → das passende Dokument in diesem Ordner lesen
2. Nach jedem Teilschritt → 08-PROGRESS.md aktualisieren
3. Änderungen am Plan (Scope, Technik, Entscheidungen) → direkt im betreffenden MD-Dokument + Hinweis im PROGRESS-Log
4. Keine neuen Dateien in den Legacy-Ordnern (_businessportal24.com/, dev/_old/, dev/migration/) mehr anlegen – diese dienen nur noch als Referenz.

---

Entscheidungen, die bereits feststehen

#	Entscheidung	Begründung
D-01	Neues Schema, keine 1:1-Übernahme der Legacy-Tabellen	Moderne Laravel-Konventionen (snake_case, id/uuid, created_at/updated_at, Soft Deletes wo sinnvoll)
D-02	Zwei Legacy-DBs → eine Ziel-DB	Quelle portal_type (presseecho | businessportal24) als Spalte auf relevanten Entitäten (User, Company, PressRelease …)
D-03	Nur Stripe als Payment-Gateway – keine Rechnungs-Zahlungsweise mehr	PayPal Express / SPK-Berlin / Cortal Consors / Rechnung entfallen komplett.
D-04	Country und Salutation werden Config-Dateien (config/countries.php, config/salutations.php)	Statisches Stammdatum; keine DB-Tabelle nötig
D-05	API-Keys: Cut-over auf Sanctum PATs (keine Legacy-Kompatibilität)	Kundenkommunikation + Self-Service Token-Verwaltung im Backend
D-06	Admin-Backend = Livewire Volt + Flux UI, keine Inertia/Vue	Konsistenz mit bereits erstellter Struktur
D-07	Sprache: Deutsch + Englisch werden direkt initialisiert	UI DE, Content zweisprachig
D-08	Altes Symfony-Frontend wird nicht übernommen	Neue Frontends sind bereits separat in diesem Repo (resources/views/web/*)
D-09	Passwörter werden NICHT übernommen	Bei Go-Live gehen Reset-Mails an alle User mit Sicherheitshinweis
D-10	Magic-Link Login (E-Mail-Link / Einmal-Passwort) wird eingebaut	Insbesondere für Companies ohne bisherigen Login; Self-Service-Zugriff auf Pressemitteilungen, Rechnungen, Tokens
D-11	Backend ist Admin + Customer-Portal	Drei Bereiche: Admin (intern), Customer (Company-Self-Service), API-Only
D-12	Legacy-Rechnungen → Archiv, neuer Billing-Lauf komplett neu gebaut	Separate legacy_invoices-Tabelle, vollständiger DB-Import inkl. Status/User-Zuordnung, PDFs read-only on demand
D-13	Neue PaymentOptions / Stripe-Produkte; Grandfathering für Alt-User	Alt-User behalten Konditionen bis Laufzeit-Ende
D-14	Promotion Links entfallen; Footer Code bleibt	Scope-Reduktion
D-15	Newsletter wird neu aufgebaut, nur Subscriber-Daten migriert	Legacy-Workflow-Code wird nicht portiert
D-16	Coupons: vertagt (erstmal kein Model)	Wird später separat evaluiert
D-17	portal-Spalte + deleted_at auf allen mandantenfähigen Entitäten verpflichtend	Multi-Tenant-Trennung + Soft-Deletes
D-18	DB-Dumps liegen vor (dev/migration 2026/sql/), Import muss wiederholbar sein	Go-Live benötigt Replay gegen produktiven DB-Stand

Entscheidungsdetails mit Begründungen: siehe 00-OVERVIEW.md §5.

---

Kontakt / Zuständigkeiten

Alle Planungsdokumente in diesem Ordner sind die Single Source of Truth. Bei Änderungen am Plan bitte Commit-Message mit migration-2026: prefixen.