Kevin Adametz
1cd4d8e33a
Kriterien vom Auftraggeber (12.06.2026): Quelle der Aktiv-Erkennung ist
ausschliesslich das read-only Rechnungsarchiv legacy_invoices (D-12).
Legacy-Rechnungen bleiben Archiv; neue manuelle Rechnungen entstehen im
MAN-Rechnungskreis.
- Aktiv-Regel: juengste Rechnung pro (Portal, Legacy-Vereinbarung) mit
payment_option.type=recurring und user_payment_option.status=active;
next_due_date max. --grace-months (Default 12) ueberfaellig, sonst
stale -> bleibt reines Archiv. Einmal-Kaeufe werden nie uebernommen.
- Uebernahme als grandfathered in user_payment_options:
current_period_end = next_due_date, Betraege/Intervall der letzten
Legacy-Rechnung in legacy_conditions -> der taegliche MAN-Lauf
(billing:generate-manual-invoices) fakturiert zum gewohnten
jaehrlichen Rhythmus weiter. Versteckte Katalog-Platzhalter
LEGACY-{PE|BP}-{Artikel} in payment_options.
- Replay-faehig (D-18): Re-Runs aktualisieren anhand der Legacy-IDs in
legacy_conditions statt zu duplizieren — die Kern-Migration laeuft
kurz vor dem Relaunch erneut.
- Optionen: --dry-run, --as-of, --grace-months, --no-report; JSON-Report
nach storage/app/migration/. Dry-Run gegen Test-Snapshot: 22 aktive
jaehrliche Vereinbarungen, davon 4 sofort faellig, 0 stale.
- Doku: MIGRATION-STEPS.md (Runbook-Reihenfolge nach archive-invoices),
05-DATABASE-MERGE §5.6, 12-NAECHSTE-SCHRITTE 6.6, 08-PROGRESS,
PHASE-9-Plan + Checkliste.
Tests: GrandfatherLegacySubscriptionsTest (7, inkl. End-to-End
Migration -> MAN-Rechnung mit Legacy-Betraegen). Suite: 475 passed,
4 skipped. Pint clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| sql | ||
| 00-OVERVIEW.md | ||
| 01-LEGACY-ANALYSIS.md | ||
| 02-TARGET-ARCHITECTURE.md | ||
| 03-MIGRATION-PLAN.md | ||
| 04-DATA-MODEL.md | ||
| 05-DATABASE-MERGE.md | ||
| 06-FEATURES-SCOPE.md | ||
| 07-API-MIGRATION.md | ||
| 08-PROGRESS.md | ||
| 09-REVIEW-QUALITAET.md | ||
| 10-LEGACY-API-KUNDEN.md | ||
| 11-NOCH-ZU-TUN-OPTIMIERUNGEN.md | ||
| 12-NAECHSTE-SCHRITTE.md | ||
| MIGRATION-STEPS.md | ||
| README.md | ||
Migration 2026 – Pressekonto Backend
Migration des Backends der beiden Legacy-Portale
presseechoundbusinessportal24(Symfony 1.4, PHP 5.6) in ein gemeinsames, modernes Laravel 12 Backend unter der Domainpressekonto.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):
businessportal2442 Tabellen / 578 MB,presseecho43 Tabellen / 369 MB – 41 Tabellen sind strukturell identisch, 3 abweichend (press_release_image_oldnur BP24,category_pe_data+press_release_pe_datanur 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
- Vor jeder Phase → das passende Dokument in diesem Ordner lesen
- Nach jedem Teilschritt →
08-PROGRESS.mdaktualisieren - Änderungen am Plan (Scope, Technik, Entscheidungen) → direkt im betreffenden MD-Dokument + Hinweis im PROGRESS-Log
- 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.