PHP 8.5 in Shopware: Migration from an Agency View 2026

With the PHP 8.5 release on 2025-11-20 (php.net), the final 8.x version before PHP 9.0 has shipped - and for Shopware agencies the clean migration becomes a mandatory task. Shopware supports PHP 8.5 from version 6.7.7 onwards (Shopware release notes / FriendsOfShopware static-data), released in February 2026. The performance promises are real: Tideways measures around +9 % on CPU-intensive workloads versus 8.3, Kinsta documents +33 % requests/second under WooCommerce compared to PHP 8.4. These numbers, however, only materialise when the migration is orchestrated cleanly: plugin compatibility audited, deprecations addressed, OPcache sized correctly and the rollout staged from staging to production. This article deliberately focuses on the agency and hosting perspective: concrete audit workflows, automated test patterns, a rollout plan for multi-shop hosting and monitoring requirements after go-live. A more general performance overview is provided by the article Migrating Shopware 6 to PHP 8.5 - here we focus on operational execution.

PHP 8.5 at a glance: what is new?

PHP 8.5 is, as the last 8.x version before PHP 9.0 (php.net), a significant milestone. On the language side, the release brings the long-discussed pipe operator|> (Stitcher / Laravel News), two new array functions (array_first() and array_last()), a clone-with syntax, the #[\Override] attribute, a new URI extension as well as improved error reporting with backtraces even on fatal errors (Phoronix / Zend). PHP continues to dominate the web stack with 73.3 % of all websites with a known server-side language (W3Techs May 2026); according to the JetBrains State of PHP 2025 (n=1720), PHP 8.x is the clearly dominant major. Anyone running Shopware stores will not avoid PHP 8.5 in the medium term - especially because PHP 7.4 has been end-of-life since 2022-11-28 (Zend / TuxCare) and all deprecations introduced in 8.5 will become fatal errors in PHP 9.0 (Zend).

Performance benchmarks: 8.3 vs 8.4 vs 8.5

The benchmark picture is nuanced. Tideways measures PHP 8.5 around 9 % faster on CPU-intensive workloads than PHP 8.3. Kinsta publishes about 33 % more requests/second for WooCommerce on PHP 8.5 compared to PHP 8.4 - the largest jump in years. Sevalla, on the other hand, finds only marginal differences between 8.2 and 8.5 on Laravel workloads with heavy database load (430 to 445 req/s) - the bottleneck there sits in the database, not the PHP interpreter. Similarly, Kinsta shows almost identical numbers for WordPress on 8.3, 8.4 and 8.5 (5.42 to 5.43 req/s). Historically, PHP 8.1 already delivered around +18.4 % requests/second over 7.4 according to Zend, and the JIT introduction in 8.0 brought 20 to 30 % speedups in synthetic benchmarks per Mobidev. In practice this means: those still on 7.4 or 8.1 will see the largest effect from upgrading. Those coming from 8.3 or 8.4 mostly see noticeable wins on CPU-heavy operations (template rendering, image processing, search indexing).

Pipe operator and new array functions

The pipe operator is the most visible new feature. In a Shopware context it is particularly useful in data transformation pipelines within custom services - for example when preparing product data for external interfaces, feed generation or import routines. The example below shows typical before/after patterns from real development projects.

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

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

// array_first() / array_last() instead of reset()/end()
// Before: modifies internal array pointer
$first = reset($products);
$last = end($products);

// After: side-effect free
$first = array_first($products);
$last = array_last($products);

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

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

Breaking changes and deprecations

PHP 8.5 is essentially backwards compatible, but it deprecates a range of constructs that will become fatal errors in PHP 9.0 (Zend). For agencies that means: clean up now, not when 9.0 hits. The following list shows the points most relevant for Shopware codebases.

• MHASH_* constants deprecated (Zend). Rarely used, but occasionally found in legacy plugins for hash operations.
• Non-canonical casts deprecated (RFC wiki.php.net): (integer) and (double) should be replaced with (int) and (float).
• Increment of non-numeric strings deprecated (Zend). Recommended: str_increment() for alphabetical increments.
• Alternative case syntax with semicolon removed (PHP RFC 8.5): case Foo; is now invalid, only case Foo: works.
• filter_*()$filter parameter mandatory (Zend): the previous default behaviour is removed.
• Implicitly nullable parameters deprecated (continued from PHP 8.4): function foo(string $s = null) must be declared as ?string $s = null.
• get_class() and get_parent_class() without parameter deprecated: use static::class or parent::class instead of implicit self-reference.
• Various *_unserialize() variants deprecated: for security reasons - explicitly set the allowed_classes parameter.
• getInternalMetadata() (Date/Time) deprecated: internal API used by some date plugins.
• Various type-coercion warnings tightened: passing null to a string parameter without ?string declaration is checked more strictly.

Shopware compatibility: 6.7.7 as minimum version

PHP 8.5 is officially supported from Shopware 6.7.7 onwards (Shopware release notes / FriendsOfShopware static-data). The 6.6.x line is limited to PHP 8.2 to 8.3, older 6.4.x branches even to PHP 7.4 / 8.0. For stores still on 6.5 or 6.6, two jumps are required: first the major update to 6.7, then the PHP switch. Shopware itself communicates significant storefront improvements for 6.7 - according to Shopware twice as many orders per second compared to 6.6 and around 25 % smaller JS/CSS bundles. A dedicated migration consulting engagement is often more sensible here than a pure version jump. Important to know: plugin compatibility traditionally lags 2 to 3 months behind major releases; industry experience shows that around 75 to 80 % of common plugins become compatible within 3 months after a major PHP switch. For the remaining 20 to 25 %, you have to clarify early whether an update is planned, a fork needs to be maintained or in-house development is the better path.

Plugin audit before the migration

The plugin audit is the central lever of every PHP migration. From an agency perspective, a four-step approach has proven itself: inventory first, then static analysis, then dynamic testing, then derive an update or refactor plan. Without this sequence, every migration runs the risk that errors are not reproduced on staging, because some plugins take different code paths under load than under test load.

1. Inventory: list all active plugins (Composer lockfile + Shopware admin plugin manager). Separate into first-party (in-house), third-party commercial (vendor support) and third-party community (often without active maintainer).
2. Static analysis with PHPStan / Psalm: at least level 5, ideally level 7. Add custom rules for PHP 8.5 deprecations and segment errors per plugin.
3. Composer constraint check: composer why-not php 8.5 lists all packages that explicitly exclude PHP 8.5. This list is the short roadmap for vendor updates.
4. Manual code review for hot paths: checkout plugins, payment providers, ERP connectors, search plugins. These are the critical points with high damage potential on bugs.
5. Dynamic test with real data slices: import an anonymised production dump into staging, walk through plugin functionality along typical customer journeys.
6. Risk matrix: per plugin, score (criticality x update status x refactor effort). Drives prioritisation in sprint planning.
7. License and contract review: for commercial plugins, check whether an update contract exists and a PHP 8.5-capable release has been announced.
8. Fallback plan: for plugins without a PHP 8.5 update, decide whether fork, in-house development or feature retirement is the right path.

Test strategy for the migration

A PHP migration without automated tests is Russian roulette. The following four test layers have proven themselves for Shopware stores: unit tests at service and helper level, integration tests against the Shopware kernel and database, end-to-end tests with Playwright or Cypress for storefront flows, and smoke tests for the most important cron and queue jobs. Specifically for the migration we recommend setting up a dedicated PHP 8.5 matrix run in CI/CD that executes the entire test stack in parallel with PHP 8.3 and 8.4. That catches regressions early - long before code reaches the master branch. We typically support setups of this kind in development projects - including GitHub Actions or GitLab CI configuration.

<?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 Apple "Boskoop" ';
        $slug = $name
            |> trim(...)
            |> fn(string $s) => preg_replace('/[^a-z0-9]+/i', '-', $s)
            |> strtolower(...);

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

    public function testArrayFirstReturnsFirstElementWithoutPointerSideEffect(): void
    {
        $products = ['SKU-1', 'SKU-2', 'SKU-3'];
        // Pointer stays unchanged - advantage over 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 for maximum performance

OPcache is the most important performance lever in any Shopware setup - and on PHP 8.5 a configuration review is worthwhile. maxcluster recommends 512 MB OPcache for Shopware and Magento as well as opcache.max_accelerated_files=65407 as realistic averages. OPcache preload brings an additional 2 to 5 % performance (maxcluster), but it requires that preload scripts match the Shopware version - otherwise loading errors occur on worker start. For more complex setups we typically iterate: measure baseline, analyse OPcache stats via opcache_get_status(), tune up or down deliberately. In combination with managed hosting for online shops such tuning loops are routine work.

; OPcache config for Shopware 6.7.7+ on 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 (only when Shopware version is stable)
opcache.preload=/var/www/shopware/var/cache/opcache-preload.php
opcache.preload_user=www-data

; Realpath cache (often underestimated, large effect)
realpath_cache_size=4096K
realpath_cache_ttl=600

Rollout plan: staging to production

The rollout itself is the point where migrations can derail. The following six phases have proven themselves for Shopware migrations from agency practice - applicable to single-shop and multi-shop hosting alike.

1. Phase 1 - baseline (week 1): measure current performance (TTFB, LCP, OPcache hit rate, queue throughput). Document plugin inventory, Composer lockfile, PHP configuration. Define success criteria.
2. Phase 2 - staging setup (week 2): clone production on identical infrastructure. Anonymised data dump. PHP 8.5 + Shopware 6.7.7 as a combined update alongside the 8.3 variant.
3. Phase 3 - plugin audit and fixes (weeks 3-4): static analysis, deprecation cleanup, plugin updates. Adapt custom plugins. Get the test suite green.
4. Phase 4 - load tests (week 5): k6, Locust or JMeter with production-like scenarios. Compare CPU, memory and DB profile per PHP version. Define regression thresholds.
5. Phase 5 - canary rollout (week 6): in multi-shop hosting, switch a non-critical tenant first. In single-shop setups: traffic split via reverse proxy (e.g. 5 % on 8.5, 95 % on 8.3).
6. Phase 6 - full rollout (weeks 7-8): gradually move to 100 %, with a defined rollback path (PHP version via update-alternatives or container tag). After 48 h without issues, close the rollback window.

Monitoring after go-live

After go-live, monitoring decides whether the migration counts as a success. We recommend three observation layers, ideally consolidated on a single dashboard: application performance monitoring (APM) for PHP internals (request time, OPcache hit rate, memory per request), infrastructure monitoring for FPM pools, MariaDB/MySQL and Redis, and real user monitoring (RUM) for LCP, INP, CLS from the end-user perspective. The OPcache hit rate is a particularly important early indicator after a PHP migration: if it falls below 95 %, max_accelerated_files is usually too small or preload is not active. A look at the broader Shopware 6 performance optimisation and at edge caching reinforces the PHP 8.5 effect.

A typical observation window covers the first 14 days after go-live. In this phase, edge cases often surface that were not covered in the test setup - rarely triggered cron jobs, special mandates of a B2B customer or specific currency constellations. We recommend evaluating PHP error logs at E_DEPRECATED level during this period: even seemingly harmless warnings can point to code locations that will break in PHP 9.0. The findings flow directly into the next sprint - turning the PHP 8.5 migration into preparatory work for the 9.0 jump rather than an isolated one-off project.

PHP 8.5 as preparation for the 9.0 jump

Anyone introducing PHP 8.5 cleanly now makes the jump to PHP 9.0 significantly more predictable: constructs marked deprecated in 8.5 become fatal errors in 9.0 (Zend), and anything removed today does not need to be touched later in crisis mode. From an agency perspective, the 8.5 migration is therefore not a technical update, but a strategic anchor: it is the last opportunity to lead codebases in an orderly fashion into the next major era without time pressure. For Shopware operators this is doubly relevant, because Shopware 6.8/6.9 will foreseeably require PHP 9.0 as a minimum version - and then every month of lead time counts. The consistent use of static analysis tools, automated tests and a documented plugin roadmap is the difference between a calm migration and a crisis project.

Frequently asked questions about the PHP 8.5 migration