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

---

## 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.