How to Migrate From Zend Server to the Zend Web Platform

Zend Server has been around for a long time, and for many teams it still runs business-critical PHP applications. But the way we build, package, deploy, and scale PHP has changed dramatically, and the landscape has shifted out from underneath it. 

Now the clock is ticking: Zend Server 2021 reaches end of maintenance on December 31, 2026, after which your applications will be exposed to new CVEs with no fixes coming. On December 31, 2027, it reaches end of life (EOL), after which you will not be able to receive support for production downtime issues, or for non-patch security mitigations.

In this blog, I'll explain why we evolved beyond Zend Server with ZendPHP and ZendHQ, what the two editions of the Zend Web Platform — the Core Web Platform and the Enterprise Web Platform — offer, and how to assess, plan, and cut over to the platform.

Make Your Zend Server Migration Plan

The History of Zend Server

First, I want to give Zend Server its due.

Zend Server was born when PHP was fighting for enterprise credibility against Java application servers. At the time, enterprises were investing in vertical scaling, addressing problems by increasing memory and CPU usage. Zend Server took it's shape to address those needs.

What Zend Server Delivered

Zend Server delivered all of a PHP application's moving parts out of the box — web server, PHP, logging, monitoring, and caching — plus features that were groundbreaking in the late 2000s:

• Job Queue — Deferring and scheduling jobs without cobbling together a "poor man's queue" and cron jobs.
• Z-Ray — A debug bar with database query introspection and code tracing, at a time when few good options existed.
• Cluster edition — Session clustering and deployment to every node for teams that needed high availability.
• A single pane of glass — Logs and events across every node, years before tools like OpenTelemetry, Elasticsearch, and Kibana.

But then the landscape moved on.

How PHP Outgrew Zend Server

As PHP advanced, so did the demands on PHP technologies, and Zend Server no longer served the needs of the community.

APIs took center stage, but Z-Ray required a browser. Composer changed how we package applications, and ZPKs weren't built around it. You were locked to one PHP version at a time, new PHP releases took time to support within the Zend Server infrastructure, and security patches for the bundled web server arrived later than the demands of more modern PHP applications began to require.

But the biggest factor was PHP itself. PHP uses a shared-nothing architecture: state is torn down at the end of each request. That means instead of throwing more RAM and CPU at your application, you throw more servers at it. Cloud providers made that easy, and a cluster edition with everything on every server became less desirable.

Splitting the PHP Monolith

The Zend team stepped back and rethought the approach. We landed on splitting the Zend Server PHP monolith into two more flexible products:

• ZendPHP is for people who want to use PHP the PHP way. It's just the runtime, with LTS support, same-day new versions, fast security patches, and hardened containers.
• ZendHQ preserves the features people loved — Job Queue, monitoring, code tracing, and Z-Ray — but runs as a distributed service, more like your database. PHP nodes stay slim, and admin features sit behind a firewall.

It's a cleaner separation of concerns, and it matches how PHP actually wants to scale. But when we took steps toward retiring Zend Server, customers told us what they missed: their dashboards, easy deployment, session clustering they didn't have to think about, and data and page caching.

Good news: We found a way to bring them back.

What Is the Zend Web Platform?

The Zend Web Platform is how we reconcile what customers valued about Zend Server with the flexibility, scalability, security, and portability of ZendPHP and ZendHQ. It integrates proven open source solutions like Redis, OpenTelemetry, and OpenSearch around that leaner runtime.

The platform comes in two container-based editions: the Core Web Platform, which deploys using Docker Compose, and the Enterprise Web Platform, which deploys on Kubernetes. 

Regardless of the edition you choose, the platform is built on four main pillars:

• Security — Every service runs in containers hardened to meet CIS benchmarks, and the only way into the system is a web request.
• Portability — Deploy anywhere containers run and send telemetry data to your existing APM.
• Observability — Access aggregated logs, metrics, and telemetry in OpenSearch dashboards and via customized visualizations.
• Scalability —  Web workers are separate from job workers, meaning public traffic doesn’t compete with background jobs. The Enterprise edition adds horizontal scaling and high availability for every service.

Here's how each edition addresses features from Zend Server (with a downloadable comparison available here):

Is the Core or Enterprise Web Platform a Better Destination from Zend Server?

The answer, as with so many things, is that your best edition of the Zend Web Platform will vary depending on the particulars of your PHP environment and organizational needs.

Zend released the Enterprise Web Platform first. Using Kubernetes, it allows you to control deployment by modifying Helm chart values. It delivers autoscaling and high availability built for production and scale. But Kubernetes is complex, needs experts to run it correctly, and is a non-starter for many teams.

That’s when we introduced the Core Web Platform, which deploys using Docker Compose and offers a simpler alternative. The Core Web Platform suits development and internal applications, and if you’ve been deploying to a single server without worrying about scalability, it is likely your best option.

What’s great is that the Core Web Platform can work both as a destination and as a bridge to the more powerful Enterprise edition. When you develop a container on Core, you can easily move to Enterprise later. Once the Kubernetes environment has been established, you simply launch your existing containers there with next to no changes.

How to Migrate from Zend Server to the Zend Web Platform

For most Zend Server users, the first destination will be the Core Web Platform. There are three phases to getting there: assess your environment, plan the move, and lean on our migration tooling.

Step 1: Assess Your Environment

As with any migration, you have to know what you're running. That means more than a list of software, but a complete understanding of what's running, how it's configured, and why. Zend Server bundled so much together that it's easy to lose track of which pieces your applications actually depend on. 

Take inventory of:

• Deployment — Are you uploading files directly to the server via SCP or FTP, or are you using ZPKs?
• PHP version — If you're on Zend Server, you're likely on PHP 7.2, 7.3, or 7.4. With PHP 8.6 arriving next week, you have to plan for long-term support (LTS) no matter what. Zend offers PHP LTS beyond the Zend Server lifetime, so you can defer a PHP upgrade until you're stable on the new platform.
• Extensions and configuration — Which extensions and INI directives do you rely on? If you handle uploads, check maximum upload sizes and memory limits.
• Database — How do you connect, and which extensions are you actually using? ZendPHP ships everything Zend Server did and then some, but watch details like TLS requirements between client and server.

Some of these answers won't be obvious. You may need to do a small amount research and development to understand what will work in your new environment and what won't, and that's part of the assessment, too. 

Take this inventory and do your planning before you move. The better you understand your current environment, the fewer surprises you'll hit during cutover.

Step 2: Plan Your Move

With your inventory in hand, make a plan designed to reduce risk as you mae the transition from Zend Server to the Zend Web Platform.

First, decide where to run the platform. A new server is safest: it leaves your known-good Zend Server setup untouched and only needs Docker and Docker Compose, reducing your attack surface. If that isn't possible, run the platform alongside Zend Server and configure its ports to avoid conflicts.

Next, choose a cutover strategy:

• Run both side by side behind a load balancer, then cut over.
• Run an A/B test with alternating back ends to see what breaks and why.
• Cut over cold turkey, with the old site behind the firewall.

Whichever you choose, make sure you have a plan for rolling back to Zend Server if anything goes wrong. And, if at any point you have questions, need support, or would like expert help as you plan your migration, the Zend team is in your corner. Fill out this form or contact your account representative for next steps.

Step 3: Use the Migration Tooling Provided by Zend

Remember, migrating from Zend Server to the Zend Web Platform doesn’t mean starting from scratch. Navigate to the Zend Server plugin gallery. There, you’ll find a ZendHQ migration plugin that can:

• Export your Job Queue queues and jobs for import into ZendHQ.
• Export your monitoring rules, including any tweaks you made to avoid false positives.
• Export your PHP INI — anything you changed from the production defaults — so you can bring it into ZendPHP.

That last one is the most important, since it tells you which extensions and configuration you need.

Our team is also building a new Zend Core command that adds a service from a ZPK. If you have pipelines that produce ZPKs, you probably don't want to replace them yet. This tool creates a custom Dockerfile that unpacks your ZPK, reads the PHP version, extensions, and configuration directives, builds the image, and defines the service in your Core Web Platform Compose file. You get the advantages of containers without changing your existing build process.

After the Move: Deployment and Scaling

On the Zend Web Platform, your version control system and your container registry become your new best friends. Like ZPKs, you build once and deploy over and over again, but container images are quicker to deploy and easier to roll back.

Here's how the new deployment workflow looks:

1. Develop — Use a build context to build and test dynamically.
2. Tag and push — Tag your image and push it to your container registry for a consistent startup state every time you deploy.
3. Track — Commit every change, including image tags and build context, to version control, whether that's Git, Perforce P4, or Subversion.
4. Roll back — Check out a previous commit and redeploy.

When you outgrow a single server, move to the Enterprise Web Platform. Any container that runs on the Core Web Platform runs there too, so you don't have to change anything. You'll deploy to Kubernetes with Helm, and autoscaling and high availability are already configured. You don't have to figure out Kubernetes alone, either: experts at Zend (along with our sister brand OpenLogic) can help you set up that environment.

Migrating from Zend Server to the Zend Web Platform: FAQ

Does the Zend Web Platform have a deployment GUI like in Zend Server?

No, the Zend Web Platform doesn't have a built-in deployment GUI like Zend Server. 

In Zend Server, you could drag and drop a ZPK package into the GUI and it handled the deployment for you. The Zend Web Platform uses open source tools instead, so you can still get a visual deployment experience by adding the tool that fits your environment:

• Enterprise Web Platform (Kubernetes): Use a Kubernetes management GUI like Rancher or Headlamp.

• Core Web Platform (Docker Compose): Use a tool like Dockge or Portainer to edit configurations, switch between versions in your Git repository, see how images are built, and start, stop or restart services.

Your team can deploy whichever way it prefers. If you're comfortable with GitOps and the command line, you can work that way. If you'd rather have a GUI, these tools give you one, and we can help you set them up. Contact us with any questions.

Does the Zend Web Platform support IBM i?

No. The Zend Web Platform is built entirely on containers, and IBM i doesn't natively support containers.

You could technically run containers by installing Linux on Power, but that means moving everything to a completely different architecture, which adds a lot of overhead. IBM i is a vertically scaling machine, so most teams will want to keep running their workloads directly on it.

That said, we're not leaving IBM i Zend Server users behind. Several initiatives are bringing platform features to IBM i:

• Already available: ZendHQ, with job queues, monitoring and Z-Ray.
• Coming soon: OpenSearch and OpenSearch Dashboards, plus log aggregation and limited OpenTelemetry aggregation. These will give you dashboards that show things like your top URLs and slowest URLs.
• Deployment: Our ZPK to Ansible tool is available now. It takes a ZPK and deploys it as a ZendPHP and ZendHQ application on IBM i or any Linux-based system. It doesn't have a GUI, but managing deployments with it should quickly feel familiar.

Once the dashboards are in place, IBM i users will get the parity they're looking for between Zend Server and the Zend Web Platform.

We host dozens of applications on one Zend Server instance. Will moving to the Core Web Platform impact performance?

You should see the same or better performance. 

With the Core Web Platform, NGINX talks to separate PHP-FPM pools, and each pool can be isolated in memory from the others in a way Apache doesn't easily support. That separation improves both security and performance. Containers built well are also slimmer, which adds to the performance gains.

You'll be able to run at least as many applications as you do on Zend Server today, and probably more, while handling more traffic.

You'll also get built-in telemetry that shows where your bottlenecks are and which applications are using the most processing power and memory. That makes it easier to see when problems happen, which applications cause them, and which ones might need their own server.

Final Thoughts

Zend Server was revolutionary for its time, but it wasn't built for the way PHP works today. The Zend Web Platform brings everything you had in Zend Server — the bells, whistles, and predictability — into an orchestratable, distributed platform that gives you more resiliency and lets you deploy confidently over and over again.

Additional Resources

• Guide - How to Develop Web Applications with PHP
• Blog - Docker Compose vs. Kubernetes: What's the Best PHP Orchestration Tool?
• Blog -  Taking A Phased Approach to 12-Factor Web Apps
• Blog -  Does PHP Still Fit in Your Modernization Roadmap?