Magento 1 zu Magento 2 Migration: Leitfaden, Vorgehen & Best Practices

Warum Magento 1→2 kein Upgrade ist: Risiko, Architektur-Bruch und Entscheidungsrahmen

Erwartung: Code deployen, Datenbank migrieren, fertig.

Realität: Der erste Build bricht, weil dein M1-Stack an PHP 7.4+ scheitert und ein altes Payment-Modul nur für PHP 5.x gebaut wurde. Das ist kein „Upgrade“. Das ist Rebuild statt Upgrade.

Warum fühlt sich das wie ein Relaunch an?

Weil Magento 1 (M1) seit EOL (End of Life) faktisch im Risiko-Modus läuft. Security ist nicht „nice to have“. Ohne Patches wächst die Angriffsfläche, und bei PCI-Scopes ist „wir haben’s im Griff“ ohne Vendor-Support und saubere Hardening-/Monitoring-Kette schnell nur noch eine Behauptung. Alte PHP-Versionen. Verwaiste Extensions. Fragiles Betriebskonzept.

Und wenn dein SIEM/Monitoring nur auf Host-Metriken schaut, merkst du den Angriff erst, wenn Orders fehlen.

Technisch erzwingt M2 den Bruch. Hart.

• DI/Service Contracts: Du hängst dich nicht mehr „irgendwo“ rein, du arbeitest gegen definierte Schnittstellen. Gut für Skalierbarkeit. Schlecht für Copy-Paste-Portierungen.
• Indexer & Datenmodelle: EAV bleibt, aber Materialisierung und Invalidierung sind anders. Falsche Indexer-Strategie killt Throughput.
• Checkout/Theme/API: Neues Theme-Stack, andere UI-Patterns, andere API-Erwartungen. Deine Legacy-JS-Hacks sind tot.

# M1 läuft oft nur mit Legacy-PHP – M2 zwingt dich in neue Runtimes
php -v
composer -V

Ein Kollege hat letztens genau diesen Fehler gemacht: „Wir migrieren das Theme 1:1.“ Ergebnis: Wochen im Frontend-Sumpf, weil Templates, Layout-XML und JS-Integration nicht mehr in denselben Bounded Context passen.

// M2: DI statt globaler Singletons/Helpers
class PriceService {
  public function __construct(\Magento\Catalog\Api\ProductRepositoryInterface $products) {}
}

Antwort auf die Upgrade-Frage: Nein, du kannst M1 nicht „direkt“ auf M2 upgraden. Du migrierst Daten.

Du implementierst Funktionalität neu. Relaunch, kontrolliert.

Entscheidungsrahmen: „M2-Migration“ vs. „Replatforming“.

Trigger	M2-Migration (Rebuild)	Replatforming
Extreme Customizations	Nur wenn fachlich stabil und testbar	Wenn Domäne neu geschnitten werden muss (Event-Driven, Entkopplung)
Legacy-Integrationen	Wenn Schnittstellen modernisierbar (idempotent, versioniert)	Wenn Integrationslandschaft proprietär/unkontrollierbar ist
Multi-Store/Internationalisierung	Wenn SEO-Logik (Canonical/hreflang) sauber modelliert ist	Wenn Governance/Content/ERP-Prozesse den Shop dominieren

Leitplanken, bevor du auch nur ein Ticket schreibst: SEO (Traffic/Index stabil, URL-Rewrite/Redirect-Mapping testbar), Performance (Core Web Vitals als KPI), Conversion (Checkout-Funnel messbar), Order-Flow-Stabilität (Payments, Versand, Refunds). Ohne diese Metriken ist „fertig“ nur ein Gefühl.

Und in der Praxis?

Wenn du die Architektur-Differenzen im Detail einordnen willst: Architektur-Überblick zu Magento 2 (Module, Themes, Schnittstellen).

-- Beispiel: Order-Flow-Stabilität messbar machen (vor/nach Cutover)
SELECT status, COUNT(*) 
FROM sales_order 
WHERE created_at > NOW() - INTERVAL 7 DAY
GROUP BY status;

# Performance-Kriterium nicht „gefühlt“, sondern gemessen (CWV/Lighthouse)
lighthouse https://shop.example --only-categories=performance

Roadmap 6–10 Wochen: Phasen, Deliverables, RACI und realistische Zeitpläne

[ERROR] DMT: Integrity check failed: Foreign key constraint violated for sales_order_entity

Solche Logs entscheiden den Zeitplan. Nicht PowerPoints.

Wie lange dauert eine Migration von Magento 1 (M1) auf Magento 2 (M2)? Für einen kontrollierten Rebuild statt Upgrade liegt ein belastbarer Rahmen bei 6–10 Wochen bis Go-Live, plus 1–2 Wochen Hypercare. Unter 6 Wochen klappt nur bei sehr kleinem Scope (Single-Store, wenig Custom Code, wenige Integrationen). Über 10 Wochen ist meist Scope-Drift oder Daten-/Integrationslast.

Phase	Zeitfenster	Deliverables (Artefakte)	Exit-Kriterien
Discovery/Audit	Woche 1	Audit-Report, Solution Blueprint, initiales Backlog, Redirect-Mapping Sheet	Scope eingefroren; kritische Integrationen klassifiziert; SEO-URL-Rewrite-Inventar vollständig
Build	Woche 2–5	Implementierte M2-Architektur (Theme/Module), CI/CD, Konfig-Management, Basis-Monitoring	Checkout-End-to-End (Sandbox) grün; Throughput-Tests reproduzierbar; Indexer stabil
Data Migration Runs	Woche 4–6	DMT-Konfiguration, Mapping/Transformations, wiederholbare Runs (Settings/Data), Delta-Migration-Plan	Idempotenz: erneuter Lauf liefert identische Counts; Fehlerbudget für DMT-Exceptions definiert
UAT (User Acceptance Testing)	Woche 6–8	Testplan, Testfälle, Defect-Triage, Abnahmeprotokoll	0 Blocker; definierte Akzeptanzkriterien erfüllt; Fachbereich sign-off
Cutover/Go-Live	Woche 8–10	Cutover-Runbook, Rollback-Plan, finaler Delta, Smoke-Tests, DNS/Traffic-Switch	Bestellfluss live; PSP/ERP bestätigt; SEO-Redirects mit Stichprobe verifiziert
Hypercare	+1–2 Wochen	Monitoring-Dashboard, On-Call/SLA, Performance-Tuning, SEO-Checks (Canonical/hreflang)	Fehlertrend fallend; keine Dateninkonsistenzen; Incident-Rate im Normalbereich

Aufwandstreiber. Hart.

• Multi-Store: +0,5–1,5 Wochen (Konfig, hreflang, Redirect-Mapping pro Store View).
• #SKUs: 50k–500k beeinflusst Indexer-Laufzeiten, Reindex-Strategie, Such-Backend (Elasticsearch/OpenSearch) und Cache-Warmup.
• Bestellhistorie: >2 Mio Orders macht DMT-Läufe lang; Delta-Migration braucht enges Fenster und Retry-Strategie.
• Custom Modules: >20 Module heißt meist Re-Architektur (Service Contracts, DI), plus Regression.
• Integrationen (ERP/PIM/PSP): je System typischerweise +3–8 PT inkl. Circuit Breaker, Queueing, Reconciliation.

RACI, minimal, aber scharf. Entscheiden ist nicht ausführen.

Entscheidung/Artefakt	Agentur	DevOps	SEO	Client-IT	Fachbereich
Solution Blueprint	A/R	C	C	A	C
Redirect-Mapping Sheet	R	I	A/R	C	I
Cutover-Runbook & Rollback-Plan	R	A/R	C	A	I
UAT-Abnahme	C	I	C	I	A/R

# DMT: wiederholbarer Run (Idempotenz prüfen)
bin/magento migrate:settings -r config.xml
bin/magento migrate:data -r config.xml
bin/magento migrate:delta -r config.xml

# Cutover: Freeze + finaler Delta + Smoke
# 1) M1: Order-Freeze aktivieren (z.B. Checkout disabled oder Wartungsseite)
curl -fsS https://shop.tld/healthz && curl -fsS https://shop.tld/checkout/

# Redirect-Mapping: schnelle Validierung (Stichprobe)
# source_url,target_url,status
/alt/kategorie-a,/neu/kategorie-a,301
/alt/produkt-123,/neu/produkt-123,301

# OpenSearch/Elasticsearch: Relevanz- und Throughput-Sanity
curl -s http://search:9200/_cluster/health?pretty
curl -s http://search:9200/_cat/indices?v

Ich habe das mal in einem Setup mit 12 Microservices debuggt — ```typescript // Basis-Konfiguration – anpassen je nach Umgebung export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, // 5s reicht für die meisten APIs retries: 3 // Exponential backoff empfohlen }; ``` nicht schön.

Der Fehler war banal: Delta-Migration lief parallel zu einem ERP-Import ohne Locking. Ergebnis: nicht-deterministische Counts. Fix: Cutover-Freeze, Queue-Drain, dann Delta.

Das funktioniert. Punkt.

Daten-, Theme- und Modul-Migration: DMT, Mapping, Integrationen und typische Stolperfallen

Warum ist der M1→M2-„Datenumzug“ so oft die Stelle, an der Projekte kippen? Weil jemand entschieden hat, das Data Migration Tool (DMT) als Kopierjob zu behandeln und nicht als kontrollierten ETL-Prozess mit Validierung, Retry-Strategie und klaren Abbruchkriterien.

DMT läuft in drei Modi: Settings, Data, Delta-Migration. Sequenziell. Settings migriert Konfigurationen, die in M2 überhaupt noch ein Äquivalent haben.

Data zieht die Baseline (Kunden, Bestellungen, Produkte, EAV). Delta-Migration zieht Änderungen nach, bis zum Cutover.

„Welche Daten können migriert werden (Kunden, Bestellungen, Produkte, Passwörter)?“ Kunden, Bestellungen, Produkte: ja, mit Einschränkungen. Passwörter: kommt drauf an. Und das ist kein Detail, sondern UX-Risiko.

Mappings/Transformations sind Pflicht, sobald M1-Datenmodell und M2-Zielmodell nicht deckungsgleich sind. EAV ist der Klassiker. Custom Attributes brechen leise, weil sie zwar migrieren, aber im Frontend/Indexer nicht mehr korrekt konsumiert werden. Multi-Store verschärft es, weil Scope (global/website/store) in M2 anders „gefühlt“ wird, obwohl es formal ähnlich aussieht.

# DMT: Settings, Data, Delta (Dry-Run zuerst)
bin/magento migrate:settings -r vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xml
bin/magento migrate:data     -r vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xml
bin/magento migrate:delta    -r vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.4.5/config.xml

Dry-Runs sind keine Kür. Sie sind die einzige realistische Methode, Throughput und Latenz der Migration zu verstehen, bevor der Cutover-Freeze läuft und jede Minute zählt.

Ich will Metriken: Laufzeit pro Step, DB-Load, Lock-Waits, Error-Rate. Wenn Delta 90 Minuten braucht, ist das ein Architekturproblem, kein „wir starten früher“-Problem.

Validierung: nicht diskutieren. Counts, Checksums, Spot-Checks. Counts pro Entität (customers, orders, order_items, catalog_product_entity, EAV-Tabellen). Checksums auf repräsentativen Tabellen oder Partitionen. Spot-Checks auf kritischen Kantenfällen: Gastbestellungen, Bundles, konfigurierbare Produkte, Store-spezifische Attribute, Preisregeln.

-- Beispiel: grobe Count-Checks (M2)
SELECT COUNT(*) FROM customer_entity;
SELECT COUNT(*) FROM sales_order;
SELECT COUNT(*) FROM catalog_product_entity;

-- Spot-Check: ein Produkt über alle Store Views
SELECT entity_id, sku FROM catalog_product_entity WHERE sku IN ('SKU-123','SKU-EDGE');

Passwörter und Kundenkonten. M1 nutzt je nach Version/Setup Hash-Varianten, die M2 nicht 1:1 akzeptiert. Es gibt Bridge-Ansätze: beim ersten Login M1-Hash verifizieren, dann auf M2-Hash rehashen. Das ist machbar, aber sicherheits- und compliance-sensitiv (und das ist noch die einfache Version). Wenn ihr das nicht sauber implementiert und testet, baut ihr euch eine Auth-Latenz-Spitze oder ein Account-Lockout-Festival.

// Pseudocode: Passwort-Bridge beim Login
if (user.password_hash startsWith "m1:") {
  if (verifyM1Hash(inputPassword, user.password_hash)) {
    user.password_hash = hashM2(inputPassword)  // Rehash
    save(user)
    allowLogin()
  } else deny()
} else {
  verifyM2Hash(...)
}

Wenn keine Bridge: akzeptable UX-Strategie ist ein erzwungener Re-Login mit „Passwort vergessen“-Flow. Klar kommunizieren. Keine stillen Fehler.

Optional: gestaffelter Reset für inaktive Konten. Alles andere erzeugt Support-Last und Conversion-Druck, den ihr nicht messen könnt, wenn ihr kein sauberes Event-Tracking habt.

Theme-Strategie ist eine Produktentscheidung mit technischen Kriterien. Luma ist TTM-freundlich, aber CWV sind oft Arbeit, weil das Frontend-Gewicht schnell explodiert.

Und warum ist das so?

Hyvä ist schnell und wartbar, wenn das Team Tailwind/Alpine kann und ihr nicht in UI-Component-Hölle landet. PWA ist eine eigene Architektur mit eigener Release-Frequenz; sinnvoll bei hohen UX-Anforderungen, aber teuer im Betrieb, besonders wenn Checkout/B2B-Features tief angepasst sind.

Kriterium	Luma	Hyvä	PWA
TTM	hoch	mittel	niedrig
Core Web Vitals (CWV)	risikobehaftet	stark	stark (bei Disziplin)
Team-Skills	Magento-Frontend	Lean-Frontend	App-Frontend + Magento

Extensions/Custom Modules: Audit als Keep/Replace/Rebuild. Keep ist selten.

Replace ist oft, wenn M2-Äquivalente existieren und die Vendor-Qualität stimmt. Rebuild ist Standard bei M1-Customizations, weil Service Contracts, DI und UI Components andere Schnittstellen erzwingen und ihr sonst technische Schulden importiert.

# Mini-Audit-Template (CSV/Sheet): Keep/Replace/Rebuild
module,criticality,owner,decision,reason
Vendor_ModuleA,high,checkout,REBUILD,M1 rewrite + no M2 equivalent
Vendor_ModuleB,medium,marketing,REPLACE,M2 extension available + maintained

Integrationen (ERP/PIM/PSP/Shipping) sind kritischer Pfad. Punkt. Jede Integration braucht: Contract (Payload/Schema), Idempotenz, Retry-Strategie, und bei externen Systemen einen Circuit Breaker, sonst killt euch ein Timeout die gesamte Order-Pipeline.

Besonders beim PSP: Autorisierung/Capture/Refund müssen in M2 sauber modelliert sein, sonst stimmen Status und Buchhaltung nicht mehr.

Typische Bruchstellen im Datenmodell: EAV-Attribute mit falschem Scope, Attribut-Sets mit „historischen“ Leichen, URL-Rewrite-Logik, die in M2 anders greift, und Indexer-Konfiguration, die inkonsistent ist. Wenn ihr Multi-Source Inventory nutzt oder einführt: das ist kein Migration-Flag, das ist ein Domänenwechsel. Dann müssen Reservierungen, Source-Selection und ERP-Bestandsabgleich neu gedacht werden.

Und ja: Hosting beeinflusst das alles. DMT-Throughput, Indexer-Latenz, Elasticsearch/OpenSearch-Cluster, FPC-Invalidierung. Wer das ignoriert, debuggt später im Go-Live.

Hosting- und Deployment-Modelle für Magento (Cloud/On-Prem, CI/CD, Providerwahl).

SEO-Migration ohne Traffic-Drop: Redirect-Mapping, Canonicals, hreflang, Facetten & Monitoring

Wir hatten das bei einem Kunden: 30% organischer Traffic weg. Über Nacht. Der Klassiker. Ursache: URL-Rewrite-Logik in M2 anders, Redirects „pi mal Daumen“, Canonical-Set kaputt.

Was passiert mit SEO/Rankings bei der Migration? Google bewertet eure URLs neu. Jede nicht sauber weitergeleitete Seite ist ein neues Dokument. Linksignale verpuffen. Crawl-Budget wird in 404/Soft404 verbrannt (kein Scherz). Und bei Multi-Store fliegt euch das hreflang-Cluster auseinander.

Playbook. Testbar. Hart.

Redirect-Strategie: Erst eine Redirect-Mapping-Tabelle, dann Regeln. Nicht umgekehrt. 301, keine Diskussion. Priorisierung: Top-Landingpages (Analytics/GSC), stärkste Backlinks (Search Console/Ahrefs), dann Kategorien, dann Produkte. Der Rest kommt danach.

Quelle (M1)	Ziel (M2)	Status	Kommentar
/kategorie/herren/schuhe.html	/herren/schuhe	301	URL-Struktur geändert (Suffix entfernt)
/produkt/sku-123.html	/p/sku-123	301	Neues Routing /p/
/sale.html	/angebote	301	Marketing-Landingpage

Wenn sich die URL-Struktur ändert: Pattern-Redirects nur, wenn die Bijektion stimmt.

Sonst erzeugt ihr Redirect-Loops, 302-Friedhöfe, oder worst case: alles auf die Startseite. Das ist Soft404. Google merkt das.

# nginx: .html-Suffix entfernen (nur wenn Ziel existiert!)
location ~* ^/(.+)\.html$ {
  return 301 https://$host/$1;
}

# nginx: alte Kategorie-Pfade auf neue Struktur
rewrite ^/kategorie/(.+)$ /$1 permanent;

# Apache (htaccess): http->https + www Normalisierung (eine Canonical-Host-Policy)
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

Testmethodik: Crawl vor Cutover (M1) und nach Cutover (M2) mit gleicher URL-Liste.

Dann Stichproben. 200/301/404 zählen. Latenz der Redirect-Kette messen. Maximal eine Hop. Mehr ist Backpressure auf Crawling und User.

# schnelle Stichprobe: Statuscodes + Redirect-Chain
curl -I -L https://www.example.com/kategorie/herren/schuhe.html

Canonical/hreflang-Checkliste: Pro Store View exakt ein Canonical auf die bevorzugte URL. Kein Cross-Store-Canonical. Keine Canonicals auf 404.

hreflang als konsistenter Cluster: jede Sprache referenziert jede Sprache inkl. self, plus x-default, wenn ihr es nutzt.

Bei Multi-Store ist das kein „SEO-Thema“, das ist Architektur: Bounded Context pro Store View, aber gemeinsame Regeln.

Parameter-URLs: Facetten, Sortierung, Pagination.

Entscheidet euch. Entweder noindex,follow für Filterkombinationen, oder Canonical auf die ungefilterte Kategorie. Beides gleichzeitig, wahllos, führt zu Indexierungsrauschen. Filterseiten, die wirklich landen sollen (z. „/herren/schuhe?farbe=schwarz“ als Kampagne), bekommen eigene, stabile URLs ohne Query-Parameter. Sonst wird’s Glücksspiel.

Interne Verlinkung: Navigationslinks dürfen nicht tausende Facetten-Kombinationen produzieren. Crawl-Budget ist endlich. Begrenze Facetten-Links, nutze rel=“nofollow“ selektiv oder rendere „Filterchips“ ohne Link, wenn sie nicht indexiert werden sollen. Indexer und FPC helfen Performance, aber SEO leidet, wenn ihr massenhaft Duplicate Content erzeugt. Mehr dazu in Core Web Vitals als SEO- und Umsatzhebel (Messung und Priorisierung).

Go-Live Monitoring: In der Google Search Console: Coverage, Sitemaps, 404/Soft404, „Alternate page with proper canonical“. Stündlich am ersten Tag. Dann täglich. Dazu Logfile-Checks: Googlebot-Hits, Antwortcodes, Top-404-URLs, Redirect-Ketten.

Guardrails: Ranking-/Traffic-Alarm bei X% Drop auf Top-Landingpages, getrennt nach Store View.

Hotfix-Pfade: Redirect-Mapping als deploybares Artefakt (CSV im Repo, generiert in nginx/apache rules).

Canonical/hreflang über Theme/Layout-Overrides versionieren. Keine Handarbeit im Admin. Wenn ein Fehler durchrutscht, braucht ihr einen kontrollierten Schalter. Circuit Breaker fürs SEO-Team: Änderungen nur über PR, aber mit Fast-Track und klarer Freigabe.

Troubleshooting & Betrieb nach Go-Live: Performance-Regressionen, Indexer/Cache, URL-Rewrites, Multi-Store-Fallen

Die teuerste Architekturentscheidung nach dem Cutover war: „Wir beobachten erst mal, dann reagieren wir.“

Klingt banal, ist es aber nicht.

Das Ergebnis war vorhersehbar.

CPU-Spikes, INP degradiert, und der Indexer hing, während das Support-Postfach mit „Produkt nicht auffindbar“ volllief. Wir hatten M2 live, aber kein belastbares Runbook, keine KPI-Schwellen, keine Rollback-Kriterien. Rebuild statt Upgrade heißt auch: Betrieb wird neu gebaut. Ohne Ausreden.

Welche typischen Probleme treten bei der Migration auf? Genau diese: URL-Rewrite-Kantenfälle, Performance-Regressionen durch falsche Cache- und Indexer-Settings, und Multi-Store-Fallen bei Scope, Base URLs sowie hreflang.

Symptom	Wahrscheinliche Ursache	Fix (priorisiert)
Dateninkonsistenzen: falsche Counts, Foreign-Key-Fehler	DMT-Mapping/Transformations, nicht-idempotente Re-Runs, Custom-Tabellen ohne Constraints	1) Staging-DB gegen M1 referenziell prüfen 2) DMT erneut mit deterministischem Mapping 3) FK/Unique-Constraints nachziehen und Reindex
Indexer stuck / „Update on Schedule“ läuft nie durch	cron/queue defekt, Deadlocks, falsche Indexer-Mode-Kombi, Backpressure durch lange Jobs	1) cron/consumers verifizieren 2) Deadlocks in DB slow log 3) Indexer-Mode gezielt umstellen, dann zurück
Cache/Varnish invalidation wirkt zufällig, FPC hit-rate fällt	Tags fehlen, falsche VCL, zu aggressive TTL, private Inhalte im FPC	1) Varnish-Logs auf BAN/PURGE prüfen 2) Tagging im Theme/Blocks fixen 3) ESI/Privat-Content trennen
Suche liefert „falsche“ Treffer, Relevanz kippt	OpenSearch Analyzer/Mapping anders, Synonyme fehlen, Reindex nicht konsistent	1) Index-Mapping diffen 2) Synonym-Set versionieren 3) Reindex + A/B relevancy checks
Checkout/Payment Edge Cases: Capture schlägt sporadisch fehl	Race Conditions in Webhooks, fehlende Retry-Strategie, Session/Quote Inkonsistenz	1) Idempotenz-Keys in Payment-Callbacks 2) Retries mit Exponential Backoff 3) Event-Driven Entkopplung via Queue
Multi-Store-Fallen: falsche Base URLs, hreflang durcheinander, Währung/Preis falsch	Scope (default/website/store) falsch, Attribute global statt store-scoped, CMS-Blöcke nicht je Store	1) Scope-Audit 2) Base URLs je Store hart prüfen 3) hreflang-Templates je Store fixen, CMS-Deploy pro Store

Das Runbook beginnt mit Messpunkten.

Nicht mit Bauchgefühl.

KPI-Schwellen für Hypercare: FPC hit-rate > 85% auf Katalogseiten, p95 TTFB < 400ms hinter CDN/Varnish, DB slow queries p95 < 200ms, Checkout-Error-Rate < 0,5%, und Core Web Vitals: LCP < 2,5s, INP < 200ms, CLS < 0,1. Reißt eine Schwelle, wird priorisiert. Punkt.

Profiling ist kein Ritual. New Relic/Blackfire nur auf den kritischen Pfaden: PDP, PLP, Cart, Checkout. Erst Flamegraph, dann Fix. Typisch: Redis Keyspace zu klein, Lock-Contention im Session-Storage, oder ein Plugin auf aroundExecute im Checkout, das jede Request-Latenz multipliziert.

# Indexer/cron Health (M2)
bin/magento indexer:status
bin/magento cron:run
bin/magento queue:consumers:list
tail -n 200 var/log/cron.log

# Varnish: BAN/PURGE Sichtbarkeit (Beispiel)
varnishlog -g request -q 'ReqMethod eq "BAN" or ReqMethod eq "PURGE"' -n varnish

# OpenSearch: Mapping prüfen (Beispiel)
curl -s http://opensearch:9200/magento2_product_1/_mapping | jq '.'

# DB: Slow Queries aktivieren (MySQL)
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.2;

Hypercare Operating Model: On-Call in Schichten. Ein Incident-Commander. Ein klarer Kanal.

Anmerkung: Die hier gezeigte Konfiguration stammt aus einem realen Setup – nicht aus der Doku kopiert.

Alerting auf SLO-Verletzung, nicht auf „CPU > 80%“. Jede Störung bekommt eine Ticket-Nummer, eine Timeline, und einen Fix-Forward-Plan. Keine Slack-Debatten ohne Owner.

Nicht vergessen: Immer erst in Staging testen. Immer.

Das reicht erstmal.

Anmerkung: Die hier gezeigte Konfiguration stammt aus einem realen Setup – nicht aus der Doku kopiert.

RACI liegt im Repo, nicht im Kopf.

Rollback-Plan ist kein Dokument für Compliance. Er ist eine Entscheidungsmatrix. Rollback-Kriterien: Payment nicht stabil (Fehler > 1% über 15 Minuten), Bestellpersistenz gefährdet, oder Datenintegrität nicht nachweisbar.

Dann Cut. Kontrolliert. Mit Bestellhandling und klarer Kommunikation.

Wenn ihr nach dem Go-Live nicht nur reagieren, sondern Performance- und Conversion-Optimierung nach dem Relaunch messbar angehen wollt, braucht ihr diese Runbooks als lebende Artefakte im Deployment-Prozess.

Wenn euch dafür intern Kapazität, On-Call-Rotation oder M2-Betriebsroutine fehlt: Eine Magento Agentur kann Hypercare, Monitoring-Schwellen, Incident-Prozess und die harten Fixes (Indexer/Cache/Search/Checkout/Multi-Store) als verbindlichen Operating Layer liefern.