Laminas MVC End of Life in 2026: A Decision Guide for Teams Who Cannot Rewrite

The Laminas MVC project entered a reduced maintenance phase that most teams did not plan for. If you are running production applications on laminas-mvc and the surrounding component ecosystem, the question you are probably asking right now is not “should we migrate?” but “what happens if we do nothing, and what are the realistic options given that a rewrite is not on the table?”

This guide walks through the actual decision. Not the ideal one where your team has eighteen months and a blank slate, but the one where you have a working application, paying customers, limited developer time, and a framework that is winding down its active support window.

What “End of Life” Actually Means for Laminas MVC

End of life for a PHP framework does not mean your application stops working on a specific date. Your code will continue to run. PHP does not check framework support calendars before executing your classes.

What it does mean is:

• Security patches stop. If a vulnerability is found in a Laminas component after support ends, there will be no official fix. You will need to patch it yourself or find a community fork that addresses it.
• Compatibility updates stop. When PHP 8.6 or 9.0 ships with deprecations or breaking changes that affect Laminas internals, there will be no official release to handle them.
• Bug fixes stop. Known issues that have not been addressed by the end-of-life date will remain unaddressed.
• Composer constraints become a ceiling. As other packages in your dependency tree move forward, you may find yourself unable to update them because they conflict with the pinned Laminas versions your application requires.

The practical timeline varies by component. Some packages in the Laminas ecosystem have been effectively unmaintained for longer than the official project status suggests. Others have active community forks. You need to check the specific packages your application depends on, not just the top-level laminas-mvc requirement.

Assessing Your Actual Exposure

Before making any decisions, map your real dependency surface. Run composer show laminas/* and look at every Laminas package in your lock file. For each one, check:

1. Last release date. If the last release was more than twelve months ago and the package is not considered stable-and-complete, that is a signal.
2. Open issues and pull requests. A backlog of unmerged security-related PRs is a red flag.
3. PHP version constraints. If the package’s composer.json caps PHP support at 8.3 or 8.4, you will hit a wall when your hosting provider forces a PHP upgrade.
4. Your actual usage. Many applications pull in dozens of Laminas packages but only actively use a handful of features from each. The packages you actually call into from your own code are the ones that matter.

Create a simple spreadsheet or markdown table with four columns: package name, last release, PHP constraint ceiling, and how heavily your application uses it. This exercise typically takes a few hours and saves weeks of misdirected effort later.

For teams already on the Zend-to-Laminas namespace bridge, the Zend to Laminas Migration Checklist covers the mechanical namespace work. This guide assumes you have already completed that step or are running native Laminas namespaces.

The Three Realistic Options

When a rewrite is not feasible, you are choosing between three paths. Each one has a different cost profile, a different risk profile, and a different timeline.

Option 1: Freeze and Harden

Accept that the application will stay on its current Laminas versions. Pin every dependency to exact versions. Focus all development effort on security hardening, monitoring, and reducing the attack surface.

When this makes sense:

• The application is mature and changes infrequently
• The team is small and cannot sustain migration work alongside feature delivery
• The application has a known retirement date within two to three years
• Traffic and exposure are limited enough that the security risk is manageable

What you need to do:

• Pin all Composer dependencies to exact versions and commit composer.lock
• Set up automated vulnerability scanning using composer audit in CI
• Add a web application firewall or reverse proxy rule set in front of the application
• Document every Laminas package you depend on and subscribe to security advisories for each
• Establish a process for emergency patching if a critical vulnerability drops

The trap: Freezing feels easy at first, but it compounds. Every month you stay frozen, the gap between your dependency stack and the current ecosystem grows. PHP version upgrades become harder. Developer hiring becomes harder because nobody wants to work on a frozen stack.

Option 2: Incremental Strangler Migration to Mezzio

Route new features and high-risk endpoints through a Mezzio middleware pipeline while keeping the existing Laminas MVC application intact for stable routes. Over time, migrate routes from MVC to Mezzio until the MVC layer can be removed.

When this makes sense:

• The application is actively developed with new features shipping regularly
• The team has at least one developer comfortable with PSR-15 middleware
• You can run both the MVC application and a Mezzio pipeline behind the same entry point or reverse proxy
• The business will fund gradual migration work alongside feature delivery

What you need to do:

• Stand up a Mezzio application alongside the existing MVC app
• Route specific URL prefixes to Mezzio using either a reverse proxy or a front-controller split
• Share the database, session store, and authentication layer between both applications
• Migrate routes one at a time, starting with the simplest or most security-sensitive
• Delete migrated MVC controllers once the Mezzio handlers are stable

This is the approach covered in the Modernising Zend Framework Applications guide, adapted for the specific Laminas-to-Mezzio transition. The architectural principles are the same: draw a boundary, enforce modern standards inside it, and expand the boundary over time.

Option 3: Extract and Replace Components

Instead of migrating the framework layer, replace individual Laminas components with standalone packages that do the same job. Swap laminas-db for Doctrine DBAL. Swap laminas-validator for Respect/Validation or symfony/validator. Swap laminas-mail for symfony/mailer.

When this makes sense:

• Your framework coupling is relatively shallow and most business logic lives in plain PHP classes
• The team is more comfortable with the Symfony or Laravel ecosystem
• You want to reduce your Laminas dependency count without changing the application’s routing or dispatch layer
• The application will eventually move to a different framework entirely

What you need to do:

• Audit which Laminas components you use directly versus which are transitive dependencies
• For each directly-used component, identify a replacement package that is actively maintained
• Create adapter interfaces in your own codebase so the swap is behind an abstraction
• Replace one component at a time, starting with the ones that have the most security exposure (mail, HTTP client, authentication)
• Keep the MVC dispatch layer as the last thing you replace, not the first

Making the Decision

The honest answer is that most teams end up doing a combination. They freeze what they can, migrate the highest-risk surfaces, and replace individual components as opportunities arise.

The decision matrix looks like this:

If your application has a defined end-of-life within two years, freezing is pragmatic. If it needs to run for five or more years, the strangler pattern is worth the investment. If you are somewhere in between, component replacement gives you the most flexibility with the least disruption.

Security Hardening Regardless of Path

Whichever option you choose, do these things immediately:

1. Run composer audit in CI. This catches known vulnerabilities in your dependency tree. Make it a blocking check.
2. Enable strict Content Security Policy headers. Even if your framework has a vulnerability, CSP limits what an attacker can do with it.
3. Review your authentication flow. Laminas authentication components are among the most security-sensitive. If you are using laminas-authentication, verify it handles session fixation, CSRF, and password hashing correctly for current standards.
4. Audit your input validation. Laminas input filters and validators work, but double-check that they are applied consistently across all user-facing endpoints.
5. Update PHP itself. Keeping PHP current is the single most impactful security measure, independent of framework status. The PHP Performance Playbook covers runtime configuration that also affects security.

Communicating the Decision Upward

Technical teams often struggle to explain framework end-of-life to non-technical stakeholders. Here is what works:

Frame it as a supply chain issue. The framework is a component your application depends on, and the supplier is discontinuing support. You have three options: stockpile and maintain it yourself, switch to a supported alternative, or replace the component with equivalent parts from other suppliers. Each option has a cost and a timeline.

Avoid framing it as a crisis. If the application works today, it will work tomorrow. The risk is gradual, not sudden. What you need is a budget line for ongoing migration work, not an emergency rewrite project.

FAQ

Will my Laminas MVC application stop working when support ends?
No. Your code continues to run. What stops is official security patches, bug fixes, and PHP compatibility updates.

Can I just fork the Laminas packages I need?
Technically yes, but maintaining forks of framework-level packages is a significant ongoing commitment. You inherit all the maintenance burden that the original maintainers are stepping away from.

Is Mezzio the only migration target?
No. Slim, Symfony, and Laravel are all viable targets. Mezzio is the most natural fit because it shares the Laminas component ecosystem, but the strangler pattern works with any target framework.

How long do I have before this becomes urgent?
That depends on your PHP version timeline more than the framework timeline. If your hosting provider forces a PHP upgrade that breaks Laminas compatibility, that is your real deadline.

Should I migrate to Laminas MVC 4 if it ships?
Watch the project announcements carefully. If a new major version ships with active maintainers and a clear support timeline, it may be the lowest-friction option. But do not plan around announcements. Plan around what has actually shipped.

Next Steps

Start with the dependency audit. Map your actual Laminas surface. Then use the decision matrix to choose your path.

If you are leaning toward the strangler pattern, the Modernising Zend Framework Applications guide covers the architectural approach in detail. For teams still on Zend namespaces, complete the Zend to Laminas Migration Checklist first, as it is a prerequisite for any forward migration path.

For broader context on how Zend Framework applications are structured and why certain architectural decisions constrain your options, the Application Architecture chapter covers the dispatch cycle and module system that underpin both ZF1 and Laminas MVC.