presseportale/dev/migration 2026/03-MIGRATION-PLAN.md

03 – Migrations-Plan (Phasenweise)

Jede Phase hat einen Satz klar abgegrenzter Aufgaben, ein greifbares Deliverable und Exit-Kriterien. Prioritäten: 🔴 hoch · 🟡 mittel · 🟢 niedrig.

Legende Status: ⬜ offen · 🔄 in Arbeit · ✅ fertig · ⏸️ blockiert · ❌ verworfen

Status-Abgleich 2026-04-29: Diese Datei wurde gegen den realen Code-Stand abgeglichen. 08-PROGRESS.md bleibt das chronologische Log; die Tabellen hier bilden den operativen Phasenstatus ab.

Scope-Anpassung 2026-04-23: Nach den Entscheidungen des Auftraggebers (siehe 00-OVERVIEW.md §5) wurde der Plan deutlich geschärft:

• P2 enthält jetzt Magic-Link-Auth, keine Legacy-Passwort-Übernahme.
• P4 (Customer-Portal) ist neu eingezogen worden.
• P7 (API) macht einen sauberen Cut-over, keine Legacy-Key-Kompatibilität.
• P8 (Billing) wird komplett neu gebaut – keine Übernahme alter Rechnungen in den neuen Rechnungskreis; Legacy-Rechnungen werden vollständig als DB-basiertes Archiv importiert, Grandfathering bleibt separat.
• Promotion Links und Coupons entfallen in Phase 1.

---

Phase 0 – Vorbereitung ✅ (weitgehend erledigt)

#	Aufgabe	Status
0.1	Entscheidungen in 00-OVERVIEW.md §5 mit Auftraggeber klären	✅ 2026-04-23
0.2	Legacy-DB-Dumps beschaffen → dev/migration 2026/sql/	✅
0.3	.env anpassen: DB-Connections für mysql, legacy_presseecho, legacy_businessportal	✅ lokal/testfähig, da P6-Import gelaufen; Staging/Prod-Credentials bleiben P11-Thema
0.4	Lokale MySQL-Schemas legacy_pe_snapshot / legacy_bp_snapshot aus Dumps erstellen	✅ für bisherigen Vollimport erledigt
0.5	Stripe-Test-Account + API-Keys vom Auftraggeber	⬜
0.6	Liste der neuen Stripe-Produkte (Preisliste) vom Auftraggeber	⬜
0.7	Liste der aktiven Alt-Abos für Grandfathering (oder Kriterien) vom Auftraggeber	⬜

Exit: DB-Dumps lokal importierbar, .env konfiguriert, Stripe-Zugang vorhanden.

---

Phase 1 – Fundament (1–2 d) 🔴

Ziel: Alle Eloquent-Models + Migrations + Factories + Seeders existieren und php artisan migrate:fresh --seed läuft durch.

#	Aufgabe	Abhängigkeiten	Status
1.1	config/countries.php + config/salutations.php aus Legacy-Daten exportieren	0.4	✅
1.2	Enums anlegen (app/Enums/*) inkl. Portal, PressReleaseStatus, UserPaymentOptionStatus (mit grandfathered), InvoiceStatus (Stripe-nah)	–	✅
1.3	Migrations schreiben (Tabellen aus 04-DATA-MODEL.md): magic_links, companies, contacts, profiles, categories, category_translations, press_releases, press_release_images, press_release_contact, newsletter_subscriptions, billing_addresses, invoice_billing_addresses, invoices, payment_options, payment_option_translations, user_payment_options, user_payments, legacy_invoices, legacy_import_map, contact_user, api_usage_logs, admin_presets, footer_codes, category_footer_code. Scope-Hinweis: blacklists und Coupons sind weiterhin nicht produktiv umgesetzt bzw. vertagt.	1.2	✅ Kernschema (inkl. Footer-Codes 2026-05-04)
1.4	users-Tabelle erweitern: portal, registration_type, gdpr_consent_at, legacy_portal, legacy_id, last_seen_at. password auf NULLABLE.	–	✅
1.5	Soft-Deletes + portal-Spalte auf allen relevanten Tabellen	1.3	✅
1.6	Models mit Relationships + Casts + Global Scopes anlegen	1.3	✅ Kernmodels
1.7	Factories für alle Models (Faker-DE-Locale)	1.6	✅ Kernfactories
1.8	Seeder: RolesAndPermissionsSeeder (admin/editor/customer/api-only), CategorySeeder (DE+EN), DefaultAdminUserSeeder, SalutationTranslationSeeder	1.6	🔄 Rollen, Kategorien, PaymentOptions, AdminPresets vorhanden; kein separater DefaultAdmin/SalutationSeeder
1.9	php artisan migrate:fresh --seed läuft grün	1.3–1.8	✅ laut 08-PROGRESS.md
1.10	Erste Pest-Tests (Smoke): alle Factories erzeugen valide Models	1.7	✅/🔄 Billing/Auth/Admin/API-Featuretests vorhanden; keine zentrale Factory-Smoke-Suite

Exit: DB-Struktur stabil, Test-Daten vorhanden, Tests grün. Keine PromotionLinks/Coupons-Tabellen (D-14/D-16).

---

Phase 2 – Auth & Tenancy (1.5 d) 🔴

#	Aufgabe	Status
2.1	Spatie-Seeder mit Rollen: admin, editor, customer, api-only + passende Permissions	✅
2.2	User-Model: canAccessAdmin() + canAccessCustomer() + Policies	✅
2.3	Magic-Link Auth ⭐ (D-10): MagicLinkGenerator + MagicLinkConsume-Controller/Livewire + MagicLoginLink-Mailable	✅
2.4	Fortify-Login-View erweitern um "Login per E-Mail-Link" Toggle	✅
2.5	Middleware SetCurrentPortal + CurrentPortalScope (Global Scope)	✅ SetCurrentPortal, PortalScope, CurrentPortalContext
2.6	Portal-Dropdown im Admin-Header (Flux UI Dropdown)	✅ admin.portal-switcher in Sidebar
2.7	GoLivePasswordReset-Mailable + Command auth:send-go-live-mails (vor Go-Live, dry-runnable)	✅ Command + Mailable vorbereitet; Versand bleibt P11
2.8	Tests: Passwort-Login, Magic-Link-Flow (happy + expired + consumed), Portal-Scope	✅ Auth-/MagicLink-/Access-Tests vorhanden

Exit: Neue Nutzer können sich per Passwort + Magic-Link einloggen. Portal-Scope filtert Datensätze.

---

Phase 3 – Admin-UI an Models binden (2–3 d) 🔴

Die Views existieren bereits als Blade/Livewire-Stubs (resources/views/admin/*, resources/views/livewire/admin/*). Aufgabe: echte Daten-Queries + Actions einbauen.

#	Bereich	Aufgaben	Status
3.1	Dashboard	Widgets: Anzahl PMs, neue Companies, neue Newsletter-Abos	✅ echte Counts + Review-Queue
3.2	Press Releases	Index, Create, Edit, Show, Publish/Reject-Actions, mehrere Bilder	✅ 2026-05-04: CRUD/Workflow + Multi-Image-Upload mit Sortierung/Preview-Flag/Löschen via livewire/components/press-release-images-manager (gleicher Component für Admin + Customer), API generiert thumb/medium/large-Varianten
3.3	Categories	Index mit DE+EN-Translations, Create/Edit (Slug-Live-Preview)	✅ 2026-05-04: Index, Create und Edit (DE+EN Slugs mit Live-Preview, Parent-Hierarchie + Loop-Schutz, Lösch-Schutz bei verknüpften PMs/Sub-Kategorien). Tests (8 Cases).
3.4	Companies	CRUD inkl. erweitertem Logo-Upload (Varianten)	✅ 2026-05-04: Admin-Logo-Upload nutzt jetzt ImageService::storeCompanyLogo(), generiert sq/wide-Varianten und schreibt logo_variants. Logo-Entfernen-Flow inklusive.
3.5	Contacts	CRUD, Verknüpfung zu Company	✅
3.6	Users & Roles	CRUD + Role-Assign + Permission-Editor + Legacy-Archivrechnungen-Tab	✅ Kern umgesetzt; Legacy-Rechnungs-Tab im Admin separat prüfen
3.7	Newsletter	Subscriber-Liste, Ex-/Import CSV	⏸️ Vertagt 2026-05-04 – wird nach dem Pressemitteilungs-Veröffentlichungs-Block angegangen. Aktuell vorhanden: Newsletter-Sync-UI für die Legacy-Maillisten.
3.8	Invoices (neu)	Liste, Detail, Stripe-Status, PDF-Download	⬜ Admin-View noch Dummy; wartet auf P8
3.9	Legacy-Invoices (Archiv) ⭐	Read-only Liste, Filter, PDF-Download	✅ 2026-05-04: Admin-Archivübersicht mit Suche, Portal-/Status-/Mapping-/PDF-Filtern, Hinweisen für unzugeordnete Legacy-User und on-demand PDF-Download
3.10	Payments	Liste (Filter), Detail	⬜ Admin-View noch Dummy; wartet auf P8
3.11	Footer-Codes	CRUD (blieb im Scope)	✅ 2026-05-04: Schema (footer_codes + category_footer_code), Model + Factory, Admin-Volt (Index mit Suche/Filter, Create, Edit, Soft-Delete, Toggle-Active), Sidebar-Link, Tests (9 Cases).

Exit: Alle CRUD-Screens funktionsfähig mit echten Daten. Promotions-Admin entfällt.

---

Phase 4 – Customer-Portal ⭐ NEU (1.5–2 d) 🔴

Ziel (D-11): Endkunden (Company-User) können sich selbst bedienen – kein Admin nötig für tägliche Aufgaben.

Architektur-Update 2026-05-04 (Panel-Konsolidierung): Customer-Bereich ist als "Mein Bereich" ins gemeinsame Admin-Panel überführt. URL-Prefix /admin/me/*, Routenamen me.*. Alte /customer/*-Pfade als 301-Redirects erhalten. Login-Redirect erfolgt rollenbasiert (Admin/Editor → /dashboard, Customer → /admin/me). Sidebar zeigt "Mein Bereich" auch Admin/Editor; Admin-Bereiche bleiben Admin/Editor vorbehalten.

#	Aufgabe	Status
4.1	Route-Gruppe me.* unter /admin/me/* mit auth:web + EnsureUserIsCustomer (admin/editor/customer)	✅ 2026-05-04: konsolidiert ins Admin-Panel; alte customer.*-Routen als 301-Redirects erhalten.
4.2	Dashboard (Livewire\Customer\Dashboard): aktive Abos, letzte eigene PMs, offene Rechnungen	🔄 Dashboard + eigene PMs fertig; aktive Abos/offene neue Rechnungen warten auf P8
4.3	Press Releases: Index, Create, Edit, Submit-for-Review (Status review)	✅
4.4	Rechnungen: neue + Legacy-Archivrechnungen einsehen, PDF-Download	🔄 Legacy-Archiv + PDF-Download vorbereitet; neue Rechnungen warten auf P8
4.5	API-Tokens: Self-Service Create/Revoke, Scope-Auswahl	✅
4.6	Company-/Contact-Profile pflegen (inkl. Logo-Upload)	✅ Customer-Profile editierbar inkl. Logo-Upload mit Varianten
4.7	Passwort / 2FA / E-Mail ändern	✅ customer.security mit Passwort-/Mail-Update + Fortify 2FA-Aktivierung/Recovery-Codes
4.8	Policies auf allen Aktionen (Customer darf nur eigenes sehen)	✅ PressReleasePolicy, CompanyPolicy, ContactPolicy, LegacyInvoicePolicy
4.9	Livewire-Feature-Tests	✅ Token + Legacy-Rechnungen + Profile/Security/Policies abgedeckt

Exit: Ein Test-Customer kann per Magic-Link einsteigen, PM erstellen, Token generieren, Legacy-Rechnung ansehen.

---

Phase 5 – Domain-Services & Geschäftslogik (2 d) 🟡

#	Aufgabe	Status
5.1	PressReleaseService + PublishPressRelease/RejectPressRelease-Actions + Mailable	✅ 2026-05-04: PressReleaseService mit Submit/Publish/Reject (mit Pflicht-Begründung)/BackToDraft/Archive/Auto-Reject bei Blacklist; Audit-Log via press_release_status_logs mit Quelle (admin/customer/blacklist) und Bearbeiter; rollenbasierte Mail-URLs (me.* für Customer, admin.* für Admin); Cache-Invalidation für Stats + Review-Counter.
5.2	BlacklistService (Wort-Prüfung im Text; Integration in Publish-Flow)	✅ 2026-05-04: App\Services\PressRelease\BlacklistService + BlacklistViolationException, in submitForReview()/publish() integriert (auto-rejected + Mail an Autor), Wortliste in config/blacklist.php
5.3	NewsletterService neu (Subscribe/Confirm/Unsubscribe mit Token)	⏸️ Vertagt 2026-05-04 – wird nach dem Pressemitteilungs-Veröffentlichungs-Block angegangen. Heute genutzt: NewsletterSyncService/Null-Client für Legacy-Listen.
5.4	CompanyService (Aktivierung, Logo-Upload, Footer-Code-Management)	⬜
5.5	ImageService (Intervention Image, Varianten, Thumbnail-Redirect)	✅ 2026-05-04: Logos + PressRelease-Bilder mit thumb/medium/large via Cover-Resize. Verwendet GD ohne neue Composer-Dep, Aufruf von Customer/Admin/API/Sync. Legacy-Thumbnail-Redirect noch offen, aber kein Blocker.
5.6	SluggableTrait für Models + Unique-per-Language-Logik	✅ 2026-05-04: App\Models\Concerns\HasUniqueSlug mit konfigurierbarem Scope; PressRelease (portal+language) und Company (portal) nutzen ihn. Category bleibt aussen vor (Slugs in Translations).
5.7	Domain-Events + Listeners (PressReleasePublished → SendPublishNotification)	🔄 Mailables vorhanden, keine dedizierten Domain-Events
5.8	Tests pro Service (Feature-Tests + Unit-Tests)	🔄 PressRelease/Admin/API-Pfade abgedeckt; keine vollständige Service-Suite

---

Phase 6 – Daten-Migration ⭐ KERN (3–4 d) 🔴

Ziel: Alle relevanten Daten aus beiden Legacy-DBs in die neue DB – als wiederholbares Skript (D-18).

Stand 2026-04-28: Kern-Import vollständig abgeschlossen ✅

#	Aufgabe	Status
6.1	Legacy-Zugriff via direkte DB-Connection (kein Legacy-Model nötig)	✅
6.2	legacy_import_map-basierte Upsert-Logik (idempotent)	✅
6.3	--source, --step, --dry-run, --force auf Master-Command	✅
6.4	Import-Commands: categories → users → companies → contacts → press_releases (inkl. Bilder + Kontakt-Pivot)	✅ beides Portale
6.5	legacy:archive-invoices: erster Archivlauf mit 864 Rechnungen in legacy_invoices	✅ in 6.5d technisch erweitert
6.5b	legacy:fix-timestamps: Historische Timestamps auf allen Entitäten korrekt	✅
6.5c	legacy:import --step=link-associations: 16.968 User↔Kontakt-Links	✅
6.5d	Legacy-Rechnungen Vollimport: alle bestehenden Rechnungen beider Portale inkl. Status, Beträgen, Datumsfeldern, Zahlart, vollständigem Raw-Snapshot, pdf_payload und User-Zuordnung importieren; PDF bleibt DB-basiert/on-demand auf Knopfdruck statt Datei-Archiv	✅ 2026-05-04
6.6	legacy:grandfather-subscriptions: aktive Alt-Abos übernehmen	⬜ warten auf Kriterien
6.7	Konflikt-Handling-Reports	✅ via Importer-Fehlerlog
6.8	Bilder-Transfer (Mediendateien)	✅ 2026-05-04: legacy:sync-company-logos + legacy:sync-press-release-images decken beide Asset-Typen ab. Generiert Varianten via ImageService, idempotent, Dry-Run + Reports vorhanden.
6.9	legacy:verify: Konsistenz-Checks	✅ 0 Fehler / 0 Warnungen
6.10	Rehearsal-Lauf gegen produktiven Snapshot auf Staging	⬜

Datenstand (2026-04-28):

• Users: 66.150 | Companies: 107.836 | Contacts: 16.964 | PMs: 174.688 | Rechnungen: 864 im bisherigen Archivlauf

Klarstellung Legacy-Rechnungen (2026-05-04): legacy:archive-invoices übernimmt jede Legacy-Rechnung idempotent, erhält den Originalstatus unverändert und löst die Zuordnung zum neuen User über legacy_import_map auf. Unzuordenbare Rechnungen bleiben im Archiv sichtbar und werden im Import-Report gezählt. pdf_payload speichert zusätzlich Billing-Adresse und User-Payment-Snapshot für die DB-basierte PDF-Erzeugung. Neue Stripe-Rechnungen werden erst in P8 separat konzipiert.

Exit: Kompletter Import beider Portale auf Staging erfolgreich. Rehearsal-Lauf dokumentiert. legacy:verify grün.

---

Phase 7 – API v1 (1.5 d) 🔴

#	Aufgabe	Status
7.1	Analyse Legacy-Access-Logs (letzte 90 Tage), Priorisierung Endpoints	✅ Tooling fertig; Legacy-App-Logs nicht vorhanden, Entscheidung über migrierte Daten/Codeprüfung getroffen
7.2	routes/api.php: Prefix v1, Middleware api,auth:sanctum	✅
7.3	Controller + Resources für: PressRelease (CRUD), PressReleaseImage (minimal), Company (read), Category (read), Newsletter (subscribe)	✅ newsletter/unsubscribe bewusst aus P7 entfernt; neuer Newsletter-Dienst folgt später
7.4	Request-Validation via FormRequests	✅
7.5	Sanctum Token-Abilities (`press-releases:read	write, companies:read`, etc.)
7.6	Legacy-Cut-Handler (410 Gone bei api_key-Param)	✅
7.7	Rate-Limiting pro Token	✅ 60/min pro Sanctum-Token bzw. Bearer-Token-Fingerprint
7.8	API-Doku (Scribe oder OpenAPI YAML)	✅ OpenAPI YAML unter docs/api/v1.yml + Route /docs/api/v1
7.9	Feature-Tests für alle Endpoints	✅ Kern-Endpunkte + Images + Token-Freigabe + API-Usage-Logging abgedeckt
7.10	Legacy-API-Kundenkommunikation vorbereiten	✅ Kundenreport fertig: api:legacy-customers-report; operative Mailtexte folgen außerhalb P7

---

Phase 8 – Payment & Invoicing (Stripe, neu gebaut) (2.5 d) 🔴

#	Aufgabe	Status
8.1	Stripe-Setup (.env Keys, Entscheidung Cashier vs. raw stripe-php)	⬜
8.2	PaymentOption-Admin mit neuen Produkten + Sync zu Stripe Products/Prices (Command stripe:sync-products)	⬜
8.3	Checkout-Flow (Livewire im Customer-Portal): Stripe Checkout Session, Rückkehr-URL	⬜
8.4	Webhook-Controller /webhooks/stripe + Event-Handler (checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.deleted)	⬜
8.5	InvoiceNumberGenerator (neuer Kreislauf {YYYY}{MM}-{seq})	⬜
8.6	PDF-Blade + InvoiceService	⬜
8.7	Mahnwesen vereinfacht (invoices:remind nur für Stripe-Fails)	⬜
8.8	Grandfathering-Handler ⭐: ExpireGrandfatheredSubscriptions-Scheduler + Customer-Benachrichtigung	⬜
8.9	Legacy-Rechnungen Archiv-UI im Customer-/Admin-Bereich anbinden	✅ Customer- und Admin-Archiv inkl. DB-basierter PDF-Erzeugung vorhanden
8.10	Tests mit Stripe-Test-Mode (Fake-Webhooks)	⬜

---

Phase 9 – Scheduler & Queues (0.5 d) 🟡

#	Aufgabe	Status
9.1	Supervisor/Queue-Worker-Setup (Dev + Prod Docs)	⬜
9.2	routes/console.php: daily invoices:remind, magic-links:purge, grandfather:expire, monthly newsletter:campaign-digest (optional)	🔄 magic-links:purge täglich und press-releases:purge-drafts wöchentlich vorhanden; P8/P5-Jobs offen
9.3	Failure-Alerting (Log-Channel + Mail bei fehlgeschlagenem Job)	⬜

---

Phase 10 – Testing & Härtung (1 d) 🔴

#	Aufgabe	Status
10.1	Coverage-Ziel 70 % auf app/Services, app/Actions	⬜
10.2	Architecture-Tests (Pest arch())	⬜
10.3	php artisan test --parallel grün	⬜
10.4	Manuelle QA-Checkliste (siehe 06-FEATURES-SCOPE.md §15) durchgehen	⬜
10.5	Security-Review: CSRF, CORS, Rate-Limits, File-Uploads, Magic-Link-TTL	⬜

---

Phase 11 – Deployment (1 d) 🔴

#	Aufgabe	Status
11.1	Produktiv-DB-Server provisionieren, Backups konfigurieren	⬜
11.2	Staging-Deployment + Smoke-Tests	⬜
11.3	Produktiv-Import-Rehearsal gegen aktuellen Legacy-Snapshot	⬜
11.4	Go-Live-Mailing: Passwort-Reset + Sicherheitshinweis an alle User	🔄 Command/Mailable fertig; Versand und finale Texte offen
11.5	API-Kunden-Kommunikation (Token-Migration)	🔄 Kundenreport fertig; Freigabeliste und operative Mailtexte offen
11.6	DNS-Cutover-Plan: pressekonto.de auf neuen Server	⬜
11.7	Read-Only-Modus auf Legacy-Systemen während Final-Import	⬜
11.8	Abschalten der alten Symfony-Server (nach Review-Periode)	⬜

---

Aufwandsschätzung (grob, nach Scope-Schärfung)

Phase	Aufwand (MT)
0	0.25 (Rest)
1	1.5
2	1.5
3	2.5
4	2.0
5	2.0
6	3.5
7	1.5
8	2.5
9	0.5
10	1.0
11	1.0
Σ	~19.75 MT (∼4 Wochen Vollzeit)

Grund für Erhöhung ggü. ursprünglich 16 MT: Customer-Portal (P4) ist neu, Billing ist komplett Neubau statt Migration, Daten-Migration aufwändiger wegen Wiederholbarkeits-Anforderung.

---

Abhängigkeitsgraph

P0 → P1 → P2 ┬→ P3 ┐
             ├→ P4 ┤
             │     ├→ P5 ┐
             │     │     ├→ P7 ┐
             │     │     │     ├→ P10 → P11
             │     │     ├→ P8 ┘
             │     │     │
             │     └→ P6 ┘
             │
             └→ P9

P6 (Daten-Migration) ist der kritische Pfad – kann parallel zu P3–P5 auf einem Staging-Branch vorbereitet werden, blockiert aber P10/P11.