The system still has business value.
Immediate retirement is not an option and its scope cannot be rebuilt overnight.
All services
Zend Framework
Zend Framework still runs. It has not been developed further since early 2020.
Zend Framework was absorbed into the Laminas project in early 2020. Since then nothing ships under the old name, every package is marked as abandoned and points to its Laminas counterpart. What that means for you hangs on a single number: for ZF2 and ZF3 the route to Laminas is largely mechanical. For ZF1 it does not exist, and the work there is replacement rather than migration.
ZF2 and ZF3 → LaminasReplace ZF1 step by stepNo downtimeFrom 950 €
What you get
- A verdict: mechanical migration or step-by-step replacement
- An inventory of the dependencies, abandoned packages included
- An order in steps that can each go live on their own
- The move while the system keeps running, with a way back at every step
- The right PHP version thought through, but implemented separately
- Handover to your team, in writing and in conversation
Scope & working together
The entry point is a fixed-price assessment, implementation is quoted by scope. Also for applications without documentation and without the people who built them.
Remote from Germany. Straight with me, no agency in between.
The starting point
Two situations that have nothing to do with each other.
Zend Framework 2 and 3 live on as Laminas. The move is at heart a rename: Zend namespaces become Laminas namespaces, the Composer packages become the matching Laminas packages. There is an official tool that handles most of it. That is work, but it is predictable work.
Zend Framework 1 is a different case. It reached end of life on 28 September 2016, and there is no automated route to Laminas: the migration tool explicitly covers version 2 and later only. ZF1 comes from the time before Composer, it has its own MVC, its own database layer and conventions that exist nowhere later. Anyone talking about migration here really means replacement.
On top of that comes a second problem almost every time: ZF1 applications sit on old PHP versions, often on ones that no longer receive security updates themselves. Touching both at once is the most reliable way to end up not knowing what a fault was caused by. So the two are separated: first one step, then the other.
Does any of this sound familiar?- The application runs on ZF1 and nobody dares raise the PHP version.
- Composer reports that the Zend packages are abandoned.
- There is a mixture of ZF code and later additions, with no clear boundary.
- A supplier proposed a rebuild and named a number nobody will sign off.
- Finding developers with ZF experience takes longer than the project.
- An audit asks about a framework that is officially abandoned.
Who this is for
For companies whose Zend application is still needed although the framework has stopped.
For CTOs and technical leaders with a productive Zend Framework application. It still carries business value while end of support, old PHP versions and fading knowledge increase risk.
The starting point needs evidence.
Modules, dependencies, tests and operations are mapped before choosing Laminas, Symfony or gradual replacement.
Migration must work in stages.
Each step should be usable in production, testable and reversible when necessary.
What I do
What happens along the way
01
The verdict first
Which ZF version is really in there, and how clean the boundary to your own code is. That decides between two completely different projects. The result is a clear statement: mechanical migration to Laminas, or step-by-step replacement, with the effort each one carries.
02
ZF2 and ZF3: the route to Laminas
The official migration tool replaces namespaces and package names across the whole codebase. What remains afterwards is manual work at the places where your own code relies on internals, plus the dependencies that have no Laminas counterpart. Every run its own commit, reviewable on its own.
03
ZF1: replacement instead of migration
With no automated route, ZF1 is replaced step by step rather than swapped out in one go. A router in front of the application, one area at a time moved to a maintained state, the old part shrinking. Every step goes live on its own and can be reversed on its own.
04
A safety net before the first change
ZF applications rarely have tests. So before the first change characterization tests go in, recording what the system does today. Not completely, but where the work happens and where money hangs.
05
The PHP version, but separately
Almost every ZF1 application sits on a PHP version without security updates. That needs fixing, but as a step of its own with a way back of its own. Changing framework and language at the same time makes every fault impossible to trace.
06
Afterwards: maintainable again
At the end there is a state that has releases, security updates and developers on the market. Plus checks in the pipeline, so the gap does not open up again.
Is your application still running on Zend Framework?
Send me the key facts. You find out which of the two cases you are in before you commission anything.
How it runs
How this runs
Four steps, and after the first one you know whether you are facing a migration project or a replacement project. No step assumes that you commission the next one.
STEP 01
Key facts and access
ZF version, PHP version, rough size, test coverage. Read access to the repository is enough for the assessment; production access is only needed later.
STEP 02
Assessment and verdict
An analysis of the codebase and its dependencies. The result is the verdict on which of the two cases applies, plus a list with locations, effort and an order.
STEP 03
Secure and move
A test net at the places that get touched. After that, depending on the case, the migration run or the first replaced area. Every step a commit.
STEP 04
Roll out and hand over
Into production in stages, with a way back. At the end checks in the pipeline and a handover, so your team carries on by itself from there.
Entry offer
First migration step. From 950 €
Starting price for the assessment. Implementation is quoted by scope, at a fixed price, before it begins.
The entry point is an assessment, not an implementation: you find out which of the two cases you are in and what it means before you have to decide on it.
What you get
- The verdict: mechanical migration to Laminas or step-by-step replacement
- An inventory of the dependencies, abandoned packages included
- A list of the places where your own code sits on framework internals
- An order in steps that can each go live on their own
- An assessment of test coverage, PHP version and the safety net needed
- One hour discussing the results, recorded on request
What you do not get
- No implementation of the migration, no refactoring, no new features
- No PHP upgrade, that is a project of its own with a page of its own
- No review of the infrastructure, the AWS cost analysis covers that
- No security review in the sense of a penetration test
- Read access to the repository is enough, production access is not needed
- Price excludes VAT
- From around 200,000 lines or several applications the scope is agreed beforehand
- The amount is credited if you commission the implementation afterwards
- You are under no obligation. Some clients implement the assessment themselves, and that is a valid outcome
The outcome
What is different afterwards
A state that is maintained
Laminas keeps releasing and ships security updates. The sentence "our framework is abandoned" does not come up in the next audit.
A role you can fill again
Developers with ZF1 experience are hard to find and get harder every year. A maintained state makes the position fillable again.
The route to current PHP is clear
In ZF applications the framework is almost always the reason the PHP version cannot go up. Afterwards that reason is gone.
A net that stays
The tests written for the move belong to you afterwards and protect the next change just as well.
Technologies I use
What I work with
Framework
- Zend Framework 1, 2, 3
- Laminas
- Mezzio
- laminas-migration
Language
- PHP 8.2
- PHP 8.3
- PHP 8.4
Analysis
- PHPStan
- Rector
- PHP-CS-Fixer
- Composer Audit
Tests
- PHPUnit
- Xdebug
- Characterization tests
Packages
- Composer
- Packagist
- Dependabot
Data
- MySQL
- MariaDB
- Zend_Db
- Doctrine
- PDO
Runtime
- Docker
- PHP-FPM
- Nginx
- Apache
- Valkey / Redis
Delivery
- GitHub Actions
- GitLab CI
- AWS
- Terraform
Evidence
PHP and Zend Framework certified.
Most suppliers know the destination. With an old system, what decides the outcome is whether someone also knows the starting point: why a passage is written the way it is, and what replacing it sets off. Zend Technologies no longer exists under that name, and neither do the exams of the time. For the database side there is an Oracle certification on MySQL 5, because that is where the quieter traps sit: character sets, collations and a strict mode that starts refusing what used to pass.
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development, and I worked with Zend Framework back when it was current. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Common questions
Common questions about Zend Framework and Laminas
Is Zend Framework really dead?
It is no longer developed, since the project continued as Laminas in early 2020. One figure regularly misleads here: the meta package zendframework/zendframework did end in June 2016, but only because ZF3 moved to per-component releases. The zend components kept shipping until the end of 2019. Since the move to Laminas there are simply no more fixes, security ones included.
What is Laminas, and is it a rebuild?
No. Laminas is the continuation of Zend Framework under a new name and new stewardship. For ZF2 and ZF3 the move is at heart a rename of namespaces and packages, and there is an official tool for it. Your own code stays essentially the same.
Does that apply to Zend Framework 1 as well?
No, and that is the most important distinction on this page. The migration tool explicitly covers version 2 and later only. ZF1 reached end of life on 28 September 2016 and comes architecturally from a different era. No tool carries you across here, so the work is step-by-step replacement.
What does it cost?
The first migration step costs from 950 euros excluding VAT and tells you what the implementation costs. Before that every number is a guess, because orders of magnitude separate the two cases: a ZF2 application can be moved in days, a ZF1 replacement runs over months. Implementation is quoted at a fixed price after the assessment.
Can we move to PHP 8 at the same time?
Both are needed, but not at the same time. Changing framework and language version together means that when something breaks you no longer know which one caused it. Which step comes first depends on the case: for ZF2 and ZF3 usually the migration, for ZF1 often an intermediate step onto a PHP version that still just carries the old code.
Would a rebuild not beat a migration?
For ZF2 and ZF3 almost never: the mechanical route to Laminas is cheaper by orders of magnitude. For ZF1 the question is fair, and the answer is still rarely a rebuild in one go. A rebuild has to reproduce behaviour nobody fully knows, while the old system keeps running and keeps changing. Step-by-step replacement puts parts into production from the first month.
We have no tests. Does this still work?
Yes, and with ZF applications that is the normal case. Before the first change a net of characterization tests goes in, recording what the system does today. It covers the places that get touched and the paths that money hangs on. That net stays with you afterwards.
Does the application have to be taken offline for this?
No. For ZF2 and ZF3 the move is a sequence of commits, rolled out like any other change. For ZF1 the replacement runs through a router in front of the application: one area at a time moves to the new state, each one deployable on its own and reversible on its own.
Other services
What else I help with.
Legacy modernization
Modernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn morePHP upgrade & migration
From PHP 5.6, 7 or early 8 to a supported version, while everything keeps running: compatibility assessment, a test net, automated rewriting, staged rollout.
Learn moreSymfony upgrade
From an old Symfony release onto a maintained branch: clear the deprecations, replace the bundles, version by version, while the system keeps running.
Learn more