PHP 8.4 has been out for several months now, and early adopters have had time to battle-test it in real workloads. If you’re still on 8.2 or 8.3 and wondering whether the upgrade is worth the effort, the short answer is yes — but the path matters more than the destination. Here’s what you actually need to know before flipping the switch in production.

What Makes PHP 8.4 Worth the Upgrade

PHP 8.4 isn’t a revolution — it’s a collection of practical improvements that reduce boilerplate and make everyday code cleaner. The headline features are property hooks and asymmetric visibility, but the smaller additions like array_find() and multibyte trim functions are the ones you’ll reach for daily.

The new JIT implementation based on the IR Framework also delivers more consistent performance, especially in long-running processes like queue workers and daemon scripts. If you’re running containerized PHP workloads, the reduced cold-start overhead alone justifies the upgrade.

Property Hooks: Goodbye Getter/Setter Boilerplate

Property hooks let you define get and set behavior directly on class properties. This eliminates the pattern of writing a private property plus two public methods just to validate or transform a value.

class UserProfile
{
    public string $displayName {
        set(string $value) {
            $this->displayName = trim($value);
        }
    }

    public string $slug {
        get => strtolower(str_replace(' ', '-', $this->displayName));
    }
}

In production codebases, this cleans up DTOs, value objects, and configuration classes significantly. One team we’ve seen reported removing over 200 lines of getter/setter code from their domain layer after adopting hooks.

Migration tip: Start with value objects and DTOs that have simple validation logic. Avoid refactoring complex service classes until your team is comfortable with the syntax.

Asymmetric Visibility: Read Public, Write Private

Asymmetric visibility solves the common pattern where a property should be readable from outside but only writable internally. Before 8.4, you needed a public getter and a private property.

class OrderStatus
{
    public private(set) string $status = 'pending';

    public function markShipped(): void
    {
        $this->status = 'shipped';
    }
}

$order = new OrderStatus();
echo $order->status;      // Works: 'pending'
$order->status = 'fraud';  // Error: cannot modify

This is particularly useful in domain models where you want immutability guarantees without the overhead of readonly properties (which can’t be set after initialization, even internally).

New Array Functions You’ll Actually Use

PHP 8.4 adds four array functions that replace common patterns:

$users = [
    ['name' => 'Alice', 'active' => true],
    ['name' => 'Bob', 'active' => false],
    ['name' => 'Carol', 'active' => true],
];

// Find first active user
$first = array_find($users, fn($u) => $u['active']);
// ['name' => 'Alice', 'active' => true]

// Check if any user is inactive
$hasInactive = array_any($users, fn($u) => !$u['active']);
// true

// Check if all users are active
$allActive = array_all($users, fn($u) => $u['active']);
// false

These replace array_filter + array_values + index-access patterns and make intent explicit. In codebases with heavy collection logic, these small wins add up.

HTML5 DOM Parsing That Actually Works

If your application does any HTML scraping, email template processing, or content sanitization, the new Dom\HTMLDocument class is a game changer. It replaces the old DOMDocument with standards-compliant HTML5 parsing and CSS selector support.

$doc = Dom\HTMLDocument::createFromString($html);
$articles = $doc->querySelectorAll('main > article.featured');

foreach ($articles as $article) {
    echo $article->textContent;
}

No more regex hacks or third-party libraries for basic DOM queries.

Deprecations to Fix Before You Upgrade

This is where most migration effort goes. PHP 8.4 deprecates several patterns that were previously just bad practice:

Implicitly nullable parameters. If you have function foo(string $name = null), you now need function foo(?string $name = null). Run a static analysis tool like PHPStan to find these automatically.

Unbundled extensions. IMAP, OCI8, PDO_OCI, and pspell have moved to PECL. If your application depends on IMAP for email processing, you’ll need to install it separately via pecl install imap and update your Docker images.

Deprecated mysqli functions. mysqli_ping(), mysqli_kill(), and mysqli_refresh() are deprecated. If you’re using these in health checks or connection management, switch to PDO or rewrite the logic.

Using _ as a class name is now deprecated, preparing for its future use as a placeholder in destructuring.

Step-by-Step Production Migration Checklist

1. Run your test suite on PHP 8.4 first. Use a CI matrix or a Docker image with php:8.4 to surface failures early.

2. Upgrade static analysis tools. PHPStan 2.x and Psalm 6.x have full PHP 8.4 support. Run them with --level=max to catch deprecation warnings.

3. Fix deprecations in a separate branch. Most deprecation fixes (like adding ? to nullable params) are backward-compatible with PHP 8.2+. Ship them before the runtime upgrade.

4. Update Composer dependencies. Run composer why-not php 8.4 to see which packages block the upgrade. Update them or find alternatives.

5. Test extensions. Verify that all PECL extensions you use have 8.4-compatible releases. Check phpinfo() output in a staging environment.

6. Deploy to a canary environment. Route 5-10% of traffic to PHP 8.4 instances and monitor error rates, memory usage, and response times for 24-48 hours.

7. Roll out incrementally. Promote to 50%, then 100% over a few days. Keep the old PHP 8.3 image available for instant rollback.

Performance: What to Expect

Don’t expect a dramatic speed boost from the runtime upgrade alone. Based on community benchmarks and real-world reports:

• API response times drop 3-8% on average, mainly from JIT improvements and faster serialization.
• Memory per worker decreases by roughly 5-10%, which lets you run more FPM workers or queue processes per container.
• Cold starts improve noticeably in containerized environments thanks to better opcache preloading.

The bigger gains come from adopting PHP 8.4 features in your code — property hooks reduce object instantiation overhead, and the new array functions avoid unnecessary intermediate arrays.

If you’re running Laravel, check out our benchmarks and upgrade guide for Laravel 12 on PHP 8.4 for framework-specific numbers.

Frequently Asked Questions

Is PHP 8.4 stable enough for production?

Yes. PHP 8.4.0 was released in November 2024 and has had several patch releases since. As of early 2026, it’s the recommended version for new projects and production workloads.

Can I use property hooks with existing ORMs like Doctrine or Eloquent?

Doctrine ORM has added support for property hooks in its latest releases. Eloquent models work with asymmetric visibility out of the box since they use magic methods internally. Test your specific ORM version before adopting hooks in entity classes.

What’s the minimum PHP version I should be on right now?

PHP 8.1 reached end-of-life in December 2025. If you’re still on 8.1 or below, upgrading is a security priority, not just a feature decision. PHP 8.2 remains in active support, but targeting 8.4 directly saves you from doing two upgrades.

Do I need to change my Docker base images?

Yes. Switch from php:8.3-fpm to php:8.4-fpm (or the equivalent Alpine variant). Rebuild your images and verify that all extensions compile cleanly. Pay special attention to IMAP and OCI8 if you use them — they require separate PECL installation now.

How do I handle third-party packages that don’t support 8.4 yet?

Run composer why-not php 8.4 to identify blockers. For critical packages, check their GitHub issues for 8.4 compatibility PRs. In most cases, you can temporarily pin a forked version or contribute the fix upstream.

Wrapping Up

PHP 8.4 is a solid, practical release that makes production PHP code cleaner and slightly faster. The migration effort is moderate — mostly fixing deprecations and updating Docker images — and the payoff is immediate once you start using property hooks and the new array functions.

Start with your test suite, fix deprecations on a branch, and roll out incrementally. If you’re planning a broader infrastructure refresh, pair the PHP upgrade with a framework migration for maximum impact.

The PHP ecosystem in 2026 is in a strong place. Take advantage of it.