Posts Tagged ‘migration’

This weekend I was at the Pinkpop Festival enjoying bands such as Metallica and Rage Against the Machine, when I received a tweet from Marco Tabini announcing that the book I have been working on, "php|architect's Guide to Enterprise PHP Development", is about to be published and can now be pre-ordered! I've been working on the book for quite a while and it's nice that it's finally being released now.

In the book I talk about the entire development lifecycle of PHP projects, from preparations such as building a team, gathering requirements, creating an architecture, all the way through implementation to delivery, operations and maintenance. It is intended to help improve every step of a PHP development project.

Release dates for the book are June 12 for the PDF version and June 26 for the print version.

Along with my book, php|architect is also publishing 2 other books: the PHP Job Hunter's Handbook by Michael Kimsal and the Guide to PHP5 Migration by Stefan Priebsch.

All three can be pre-ordered, and if you do, you'll receive a 15% discount.

PHP4 to 5 migration webinar

October 23rd, 2007 by Ivo

Tomorrow I'm doing a webinar for Zend: I will be talking about migrating from PHP4 to PHP5. I won't go into the technical details so much, but I will talk about why to migrate and how to migrate. I will talk about both the benefits and the risks.

It's at 9.00 am PDT (18:00 CET), and you can enroll through the Zend site. (It's free :-) )

Oh and it's live, so you have the opportunity to ask questions.

PHP5 adoption – a summary

December 19th, 2006 by Ivo

Last week, Ilia started an interesting discussion about PHP5 adoption. While speed and stability are good reasons to upgrade, many people still use PHP4. His post attracted a lot of attention, and the topic was discussed on several other blogs.

The reasons mentioned for sticking to PHP4 are plenty, and it is interesting to note that each particular group of PHP users has its own reasons why to upgrade and why not to upgrade. I've analysed the comments on Ilia's and several other blogs, did some additional research and summarized the reasons per user group.

Maybe we can derive some lessons from this for the future, how to handle the release of PHP6 for example; which parties we should target, and how we should approach the release. In any case, here is the result of my analysis. If I left something out, feel free to provide additional comments.

Developer (distributable software)

Who are they?
These are the individuals and companies that develop open source or closed source PHP applications, toolkits, frameworks and/or libraries, which they distribute in one way or another.

Why should they move to PHP5?
An important reason for the developers to move to PHP5 is the improved OO support and new features such as exception handling; this makes their software easier to maintain and more robust.

What is holding them back?
The most common reason why these developers are not moving their code to PHP5 is the lack of PHP5 adoption (notice the Chicken-Egg pattern here). Writing the applications in PHP5 would require their users to use PHP5 too. Since PHP5 is still less common than PHP4, this would mean that a PHP5 application by default has a lower potential userbase.

A related problem is compatibility; if the application already existed in PHP4, the developers are unlikely to move their codebase to PHP5, as this could be problematic for existing users.

I've seen two solutions for this group. One is to maintain two versions of the product; one which is compatible with PHP4, one which is based on PHP5. The advantage is that you can have a smoother migration from one version to another; the disadvantage is maintenance costs. For a long period, you would have to develop both versions of the software.
The other solution is to have new features use PHP5. This would give PHP5 users a 'bonus'; they would get additional functionality that the PHP4 users do not. This is a viable solution, but is not applicable to all kinds of products.

Developer (tailor made software)

Who are they?
This type of developer (usually a system integrator) develops websites and/or applications for customers. They use existing products as a basis, or develop from scratch. Typically, these applications are deployed only once.

Why should they move to PHP5?
Using PHP5 would improve the maintainability and reliability of the software. While maintainability is less important than the previous group, it is still important, as the customer may want to have new features and maintenance on the software for years.

What is holding them back?
For new applications, this group is pretty much ok with developing in PHP5. It is easy to require/convince the customer to run PHP5 for this type of application.
For older applications, a problem might be backward compatibility. If the cost of of solving bc issues by migrating the app is higher than the perceived advantage, this group will not upgrade their legacy apps.

For this group, adoption of PHP5 can be stimulated by focussing on backward compatibilty. If PHP5 was 100% backward compatible, existing apps could be moved to PHP5 with virtually no migration cost.

Hosting Provider

Who are they?
These are the companies that host applications and websites. In general, the stuff they host is developed by their customers, or by their customers suppliers. The hoster is generally in charge of maintaining the hardware, operating system and system software, to ensure that the applications of their customers run smoothly.

Why should they move to PHP5?
Moving to PHP5 could be a competitive advantage for hosting companies; people from the previous group might be specifically looking for PHP5 hosting environments. A reason to move existing servers to PHP5 might be the improved performance. This could mean that the same amount of servers can handle a larger amount of visitors.

What is holding them back?
For hosting providers, the most important reason why not to move existing servers to PHP5 is, like with the previous group, backward compatibility. A hosting provider can run from a single, to several thousands of websites on a single server. The cost involved with testing all these applications is tremendous; this would only be viable if the customers would either pay for this, or test their own applications. The larger the amount of customers running on a server, the harder it will be to get all of them to migrate their applications. Many customers will simply not care, but more about the customer later on in this post.

New, installed from scratch servers are generally equiped with PHP5. This is usually a separate environment from the PHP4 hosting. (only new customers are running on the newer PHP4, existing apps are untouched).

One solution for hosting providers is to run 2 environments; one on 4, one on 5. This way, customers can choose, and migration will be smooth. It will take a long time though before the php4 environment can be phases out, if that is at all possible.

Another solution is to run php4 and php5 on the same server. There's a neat mime type hack that some hosting providers are using. This way, the customer can choose whether to use php4 or php5, and migrate if he wants to, or leave it if he doesn't.

OS Distributions

Who are they?
OS distributions, such as Red Hat Linux (but also FreeBSD) often dictate what PHP version is being used, particularly for users that are not comfortable with compiling and/or installing their own PHP. With 'enterprise grade' distributions, such as Red Hat Enterprise Linux, you only get a particular version of PHP that has been tested and proven stable. Many of these distributions are still equiped with PHP4.

Why should they move to PHP5?
Eventually, their customers will want to have the freedom to use PHP5. Also, new features will no longer be added to the PHP4 branch. When customers require newer features, the OS should provide a PHP version that can deliver them.

What is holding them back?
Backward Compatibility mostly. A distribution like Red Hat Enterprise Linux cannot switch from PHP4 to PHP5 between minor versions of their distribution, as they cannot ensure compatibilty.

In their next major version, most distributors will probably include both PHP4 and PHP5. So this group will in the near future be moving to PHP5 one way or another, or at least they will support it. One thing that would speed this up for next releases of PHP is to have even better backward compatibility. This will lower the risk for OS distributors to include a newer version.

For users of a PHP4 based OS that want to run PHP5 but are not comfortable with compiling their own, or that do not want to run something unsupported, I suggest to have a look at Zend Core, which contains an installer and comes with an optional support package.

End user

Who are they?
The 'end users' are not the users of an application or the visitors of a website; these do generally not care what software (or version thereof) a site is running. With end-users I mean the people who download applications and install them for their own personal site or application. For example someone installing Gallery for their photo albums, or a company installing Joomla for their site.

Why should they move to PHP5?
For the end user, using PHP5 might mean they will eventually be able to run more applications. They will be able to run PHP4 based applications that are proven to be compatible with PHP5 (most open source projects are), and applications that are written in PHP5. Also, they will benefit from the performance improvements in PHP5.

What is holding them back?
Often, the end user is not the one who decides what PHP version he uses. A large group depends on hosting providers. There's a chicken-egg problem again, as hosting providers are not moving to 5 because of incompatibilities for their users, which in turn prevents their users ti move.

For the end user, an obvious solution is to find a hosting provider that supports PHP5, or even better, a provider that runs both. Another solution is to maintain his own server, which gives him total freedom on what PHP version he can use.

For the PHP community, a solution to get more end users to run PHP5, is to have more applications available that take advantage of the new PHP5 features, and to make sure that more hosting providers run PHP5.


In this post, I hope to have correctly identified most of the parties involved with PHP, and for each, have summarized the benefits of PHP5 for them, and to have analysed (mostly from the discussion on Ilia's blog) the reasons why these particular groups may be hesitant to use PHP5.

There are two recurring items: backward compatibility and chicken/egg problems. I think in general, if we want the world to adopt PHP6 more easily, ensuring backward compatibility will be a key factor (which is not in line with the current goal of getting rid of 'old concepts' such as register_globals in PHP6, although I agree that security is an important factor here). Also, providing a smooth upgrade path will definitely help. A solution such as the Apache mimetype hack, should maybe be built in into the software stack by default somehow.