PHP 8.5 in Shopware: Migration aus Agentursicht 2026

Mit dem Release von PHP 8.5 am 20.11.2025 (php.net) ist die letzte 8.x-Version vor PHP 9.0 erschienen - und für Shopware-Agenturen wird die saubere Migration zur Pflichtaufgabe. Shopware ist ab Version 6.7.6 vollständig mit PHP 8.5 kompatibel (Shopware Release-Notes), das Release erschien im Januar 2026. Wie viel eine neue PHP-Version überhaupt bewegen kann, hängt davon ab, wie viel Antwortzeit im Interpreter entsteht: Tideways misst über 1240 Produktivprojekte im Mittel 40,3 % PHP-Rechenzeit, bei Shopware-6-Projekten liegt der Anteil bei rund 50 %. Der Rest ist I/O - Datenbank, Cache, externe Schnittstellen. Der Gewinn einer Migration entsteht also nur dann, wenn sie sauber orchestriert wird: Plugin-Kompatibilität geprüft, Deprecations adressiert, OPcache richtig dimensioniert und der Rollout über Staging in Production geführt. Dieser Beitrag fokussiert bewusst die Agentur- und Hosting-Perspektive: konkrete Audit-Workflows, automatisierte Test-Patterns, ein Rollout-Plan für Multi-Shop-Hosting und Monitoring-Vorgaben nach dem Go-Live. Eine generische Performance-Übersicht liefert ergänzend der Beitrag zu Shopware 6 auf PHP 8.5 migrieren - hier geht es um die operative Umsetzung.

PHP 8.5 im Überblick: Was ist neu?

PHP 8.5 ist als letzte 8.x-Version vor PHP 9.0 (php.net) ein wichtiger Meilenstein. Sprachlich bringt das Release den lange diskutierten Pipe-Operator |>, zwei neue Array-Funktionen (array_first() und array_last()), eine Clone-with-Syntax, das #[\Override]-Attribut, eine neue URI-Extension sowie verbesserte Fehlerbilder mit Backtraces auch bei Fatal Errors (php.net Release-Notes). PHP dominiert weiterhin den Web-Stack mit 69,9 % aller Websites mit bekannter Server-Sprache (W3Techs); 64,0 % dieser PHP-Websites laufen auf PHP 8 (W3Techs). Wer Shopware-Stores betreibt, kommt an PHP 8.5 mittelfristig nicht vorbei - insbesondere weil PHP 7.4 bereits seit 28.11.2022 End-of-Life ist (php.net) und alle in 8.5 ausgesprochenen Deprecations in PHP 9.0 zu Fatal Errors werden.

Wo die Antwortzeit entsteht: PHP-Anteil messen

Die entscheidende Frage vor jeder PHP-Migration lautet: Wie viel Antwortzeit entsteht überhaupt im Interpreter? Tideways hat dafür 1240 Produktivprojekte ausgewertet und kommt auf einen Mittelwert von 40,3 % PHP-Rechenzeit; bei 34 % der Projekte liegt mehr als die Hälfte der Antwortzeit in PHP und nicht im I/O. Der Anteil hängt stark vom Anwendungstyp ab: Shopware 6, Magento 2 und WordPress liegen im Mittel bei rund 50 % PHP-Rechenzeit, Frameworks wie Symfony und Laravel bei rund 35 % - dort entfallen rund 65 % auf I/O. Für die Praxis heißt das: In einem typischen Shopware-Store wirkt eine schnellere PHP-Version auf etwa die Hälfte der Antwortzeit, die andere Hälfte bewegt sich nur über Datenbank-, Cache- und Schnittstellen-Optimierung. Wer den Effekt einer Migration seriös beziffern will, misst deshalb zuerst das eigene Profil - Hersteller-Benchmarks aus standardisierten Umgebungen sind dafür kein Ersatz.

Pipe-Operator und neue Array-Funktionen

Der Pipe-Operator ist die sichtbarste Neuerung. Im Shopware-Kontext eignet er sich besonders für Daten-Transformations-Pipelines in eigenen Services - etwa bei der Aufbereitung von Produktdaten für externe Schnittstellen, Feed-Generierung oder Import-Routinen. Das nachfolgende Beispiel zeigt typische Vorher-/Nachher-Patterns aus echten Programmier-Projekten.

<?php
// Vorher (PHP 8.3): verschachtelte Funktionen
$slug = strtolower(trim(preg_replace('/[^a-z0-9]+/i', '-', $name)));

// Nachher (PHP 8.5): Pipe-Operator
$slug = $name
    |> trim(...)
    |> fn(string $s) => preg_replace('/[^a-z0-9]+/i', '-', $s)
    |> strtolower(...);

// array_first() / array_last() statt reset()/end()
// Vorher: modifiziert internen Array-Pointer
$first = reset($products);
$last = end($products);

// Nachher: ohne Seiteneffekt
$first = array_first($products);
$last = array_last($products);

// #[\Override] in Shopware-Subscribern
use Shopware\Core\Framework\Event\NestedEventCollection;

class ProductSubscriber implements EventSubscriberInterface
{
    #[\Override]
    public static function getSubscribedEvents(): array
    {
        return ['product.loaded' => 'onProductLoaded'];
    }
}

Breaking Changes und Deprecations

PHP 8.5 ist im Wesentlichen abwärtskompatibel, deprecated aber eine Reihe von Konstrukten, die in PHP 9.0 zu Fatal Errors werden (php.net). Für Agenturen heißt das: Jetzt bereinigen, nicht erst beim Sprung auf 9.0. Die folgende Liste zeigt die für Shopware-Codebasen relevantesten Punkte.

• MHASH_*-Konstanten deprecated (php.net). Selten genutzt, aber in Legacy-Plugins für Hash-Operationen vereinzelt zu finden.
• Non-canonical Casts deprecated (RFC wiki.php.net): (integer) und (double) sollen durch (int) und (float) ersetzt werden.
• Inkrement von nicht-numerischen Strings deprecated (php.net). Empfohlen: str_increment() für alphabetische Inkremente.
• Alternative Case-Syntax mit Semikolon entfernt (PHP RFC 8.5): case Foo; ist jetzt ungültig, nur noch case Foo: funktioniert.
• filter_*() $filter-Parameter zwingend (php.net): Die bisherige Default-Variante wird entfernt.
• Implicit nullable Parameter deprecated (PHP 8.4 fortgesetzt): function foo(string $s = null) muss als ?string $s = null deklariert werden.
• get_class() und get_parent_class() ohne Parameter deprecated: Statt impliziter Selbst-Referenz static::class oder parent::class verwenden.
• Verschiedene *_unserialize()-Varianten deprecated: Sicherheitsbedingt - explizit den allowed_classes-Parameter setzen.
• getInternalMetadata() (Date/Time) deprecated: Interne API, in einigen Date-Plugins verwendet.
• Diverse Typ-Coercion-Warnungen verschärft: null an string-Parameter ohne ?string-Deklaration wird strenger geprüft.

Shopware-Kompatibilität: 6.7.6 als Mindestversion

PHP 8.5 wird offiziell ab Shopware 6.7.6 unterstützt - das Release vom Januar 2026 nennt die volle PHP-8.5-Kompatibilität ausdrücklich (Shopware Release-Notes). In der Pflegelinie 6.6 ist PHP 8.5 ab 6.6.10.11 freigegeben, ältere 6.6-Stände bleiben auf PHP 8.2 bis 8.4 limitiert, 6.4.x sogar auf 7.4 bis 8.2. Für Stores, die noch auf 6.5 stehen, sind also zwei Sprünge nötig: zuerst das Major-Update, dann der PHP-Wechsel. Eine Shopware-Migrations-Beratung ist hier oft sinnvoller als der reine Versions-Sprung. Wichtig zu wissen: Plugin-Kompatibilität hinkt Major-Releases erfahrungsgemäß hinterher. Für jedes Plugin ohne angekündigtes Update gilt es früh zu prüfen, ob ein Fork betreut werden muss oder eine Eigenentwicklung sinnvoller ist.

Plugin-Audit vor der Migration

Der Plugin-Audit ist die zentrale Hebel-Station jeder PHP-Migration. Aus Agentursicht hat sich ein vierstufiges Vorgehen bewährt: erst inventarisieren, dann statisch analysieren, dann dynamisch testen, dann Update- bzw. Refactor-Plan ableiten. Ohne diese Reihenfolge läuft jede Migration ins Risiko, dass auf Staging Fehler nicht reproduziert werden, weil bestimmte Plugins unter Last andere Code-Pfade nehmen als unter Test-Last.

1. Inventarisierung: Alle aktiven Plugins listen (Composer-Lockfile + Shopware Admin Plugin-Manager). Trennung in First-Party (eigene Entwicklung), Third-Party kommerziell (Hersteller-Support) und Third-Party Community (oft ohne aktiven Maintainer).
2. Statische Analyse mit PHPStan / Psalm: Mindestens Level 5, idealerweise Level 7. Custom-Rules für PHP-8.5-Deprecations einbinden, Fehler pro Plugin segmentieren.
3. Composer-Constraint-Check: composer why-not php 8.5 listet alle Pakete, die PHP 8.5 explizit ausschließen. Diese Liste ist die Kurz-Roadmap für Hersteller-Updates.
4. Manuelle Code-Review für Hot-Paths: Checkout-Plugins, Payment-Provider, ERP-Connector, Search-Plugins. Das sind die kritischen Punkte mit hohem Schadenspotenzial bei Fehlern.
5. Dynamischer Test mit echten Daten-Schnitten: Anonymisierter Production-Dump in Staging einspielen, Plugin-Funktionalität entlang typischer Customer-Journeys durchtesten.
6. Risiko-Matrix erstellen: Pro Plugin Score aus (Kritikalität × Update-Status × Refactor-Aufwand). Steuert die Priorisierung in Sprint-Plänen.
7. Lizenz- und Vertragslage prüfen: Bei kommerziellen Plugins, ob ein Update-Vertrag besteht und ein PHP-8.5-fähiges Release angekündigt ist.
8. Fallback-Plan: Für Plugins ohne PHP-8.5-Update klären, ob Fork, Eigenentwicklung oder Funktions-Verzicht der richtige Weg ist.

Test-Strategie für die Migration

Eine PHP-Migration ohne automatisierte Tests ist russisches Roulette. Die folgenden vier Test-Ebenen haben sich für Shopware-Stores bewährt: Unit-Tests auf Service- und Helper-Ebene, Integration-Tests gegen Shopware-Kernel und Datenbank, End-to-End-Tests mit Playwright oder Cypress für Storefront-Flows, sowie Smoke-Tests für die wichtigsten Cron- und Queue-Jobs. Für die Migration speziell empfehlen wir, einen dedizierten PHP-8.5-Matrix-Lauf in der CI/CD aufzusetzen, der den gesamten Test-Stack parallel zu PHP 8.3 und 8.4 ausführt. Das deckt Regressionen früh auf - lange bevor Code in den Master-Branch gelangt. Komplett-Setups dieser Art unterstützen wir typischerweise in der Programmierung - inklusive GitHub-Actions- oder GitLab-CI-Konfiguration.

<?php
declare(strict_types=1);

namespace App\Tests\Migration;

use PHPUnit\Framework\TestCase;
use PHPUnit\Framework\Attributes\RequiresPhp;
use Shopware\Core\Framework\Test\TestCaseBase\IntegrationTestBehaviour;

#[RequiresPhp('>=8.5')]
final class Php85CompatibilityTest extends TestCase
{
    use IntegrationTestBehaviour;

    public function testPipeOperatorInProductSlugBuilder(): void
    {
        $name = ' Bio-Apfel "Boskoop" ';
        $slug = $name
            |> trim(...)
            |> fn(string $s) => preg_replace('/[^a-z0-9]+/i', '-', $s)
            |> strtolower(...);

        self::assertSame('bio-apfel-boskoop-', $slug);
    }

    public function testArrayFirstReturnsFirstElementWithoutPointerSideEffect(): void
    {
        $products = ['SKU-1', 'SKU-2', 'SKU-3'];
        // Pointer bleibt unverändert - Vorteil gegenüber reset()
        self::assertSame('SKU-1', array_first($products));
        self::assertSame('SKU-1', array_first($products));
    }

    public function testNoDeprecatedCastsRemain(): void
    {
        $output = shell_exec('php -d error_reporting=E_ALL -l src/');
        self::assertStringNotContainsString('Deprecated', (string) $output);
    }
}

OPcache-Tuning für maximale Performance

OPcache ist der wichtigste Performance-Hebel in jedem Shopware-Setup - und unter PHP 8.5 lohnt sich ein Review der Konfiguration. Zwei Stellschrauben entscheiden: der reservierte Speicher (opcache.memory_consumption) und die Zahl der cachebaren Dateien (opcache.max_accelerated_files). Beide müssen zum tatsächlichen Dateibestand des Shops passen - ist die Datei-Obergrenze zu niedrig, verdrängt der Cache sich selbst, und die Hit-Rate bricht ein. OPcache-Preload kann zusätzlich Ladezeit sparen, erfordert aber, dass Preload-Skripte zur Shopware-Version passen - sonst entstehen Ladefehler beim Worker-Start. Für komplexere Setups gehen wir typischerweise iterativ vor: Baseline messen, OPcache-Stats per opcache_get_status() analysieren, gezielt erhöhen oder reduzieren. Im Zusammenspiel mit Managed Hosting für Online-Shops sind solche Tuning-Schleifen Routine.

; OPcache Konfiguration für Shopware 6.7.6+ unter PHP 8.5
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=65407
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.huge_code_pages=1
opcache.jit=tracing
opcache.jit_buffer_size=128M

; Preload (nur wenn Shopware-Version stabil)
opcache.preload=/var/www/shopware/var/cache/opcache-preload.php
opcache.preload_user=www-data

; Realpath-Cache (häufig unterschätzt, hoher Effekt)
realpath_cache_size=4096K
realpath_cache_ttl=600

Rollout-Plan: Staging zu Production

Der Rollout selbst ist der Punkt, an dem Migrationen kippen können. Die folgenden sechs Phasen haben sich für Shopware-Migrationen aus der Agenturpraxis bewährt - und sind sowohl für Single-Shop- als auch für Multi-Shop-Hostings anwendbar.

1. Phase 1 - Baseline (Woche 1): Aktuelle Performance messen (TTFB, LCP, OPcache-Hit-Rate, Queue-Throughput). Plugin-Inventar, Composer-Lockfile, PHP-Konfiguration dokumentieren. Erfolgskriterien definieren.
2. Phase 2 - Staging-Setup (Woche 2): Klon der Production auf identischer Infrastruktur. Anonymisierter Daten-Dump. PHP 8.5 + Shopware 6.7.6 als Doppel-Update parallel zur 8.3-Variante.
3. Phase 3 - Plugin-Audit und Fixes (Woche 3-4): Statische Analyse, Deprecation-Cleanup, Plugin-Updates. Custom-Plugins anpassen. Test-Suite grün bekommen.
4. Phase 4 - Last-Tests (Woche 5): k6, Locust oder JMeter mit produktionsnahen Szenarien. CPU-, Memory- und DB-Profil pro PHP-Version vergleichen. Regression-Schwellen definieren.
5. Phase 5 - Canary-Rollout (Woche 6): Bei Multi-Shop-Hosting zuerst auf einem unkritischen Mandanten umstellen. Bei Single-Shop: Traffic-Split via Reverse-Proxy (z.B. 5 % auf 8.5, 95 % auf 8.3).
6. Phase 6 - Vollumstellung (Woche 7-8): Stufenweise auf 100 %, mit definiertem Rollback-Pfad (PHP-Version per update-alternatives oder Container-Tag). Nach 48 h ohne Auffälligkeiten Rollback-Window schließen.

Monitoring nach dem Go-Live

Nach dem Go-Live entscheidet das Monitoring, ob die Migration als Erfolg gilt. Wir empfehlen drei Beobachtungsebenen, idealerweise auf einem zentralen Dashboard zusammengeführt: Application-Performance-Monitoring (APM) für PHP-Internals (Request-Time, OPcache-Hit-Rate, Memory pro Request), Infrastructure-Monitoring für FPM-Pools, MariaDB/MySQL und Redis sowie Real-User-Monitoring (RUM) für LCP, INP, CLS aus Sicht der Endnutzer. Insbesondere die OPcache-Hit-Rate ist nach einer PHP-Migration ein Frühindikator: Fällt sie merklich ab, ist meist max_accelerated_files zu klein oder Preload greift nicht. Ergänzend lohnt sich der Blick auf die Shopware 6 Performance-Optimierung und das Edge-Caching für globale Shopware-Performance - beides verstärkt den PHP-8.5-Effekt.

Ein typisches Beobachtungsfenster sind die ersten 14 Tage nach Go-Live. In dieser Phase laufen oft Edge-Cases auf, die im Test-Setup nicht abgebildet waren - etwa selten getriggerte Cron-Jobs, Sondermandate eines B2B-Kunden oder spezielle Currency-Konstellationen. Wir empfehlen, in dieser Phase PHP-Error-Logs auf E_DEPRECATED-Niveau auszuwerten: Selbst harmlos wirkende Warnings können Hinweise auf Code-Stellen geben, die in PHP 9.0 brechen werden. Die Erkenntnisse fließen direkt in den nächsten Sprint - so wird die PHP-8.5-Migration zur Vorarbeit für den 9.0-Sprung, nicht zum isolierten Einzelprojekt.

PHP 8.5 als Vorbereitung auf den 9.0-Sprung

Wer PHP 8.5 jetzt sauber einführt, macht den Sprung auf PHP 9.0 deutlich planbarer: Die in 8.5 deprecated markierten Konstrukte werden in 9.0 zu Fatal Errors (php.net), und alles, was heute schon entfernt ist, muss später nicht im Krisenmodus angefasst werden. Aus Agentursicht ist die 8.5-Migration damit kein technisches Update, sondern ein strategischer Ankerpunkt: Sie ist die letzte Gelegenheit, Codebasen sortiert in das nächste Major-Zeitalter zu führen, ohne unter Zeitdruck zu stehen. Für Shopware-Betreiber ist das doppelt relevant, weil Shopware 6.8/6.9 absehbar PHP 9.0 als Mindestversion verlangen werden - und dann zählt jeder Monat Vorlauf. Der konsequente Einsatz von Static-Analysis-Tools, automatisierten Tests und einer dokumentierten Plugin-Roadmap ist dabei der Unterschied zwischen einer ruhigen Migration und einem Krisenprojekt.

Häufige Fragen zur PHP-8.5-Migration