Switching from Classic ASP to PHP

One of the big changes at Wayfair recently was moving all of our storefront code (well, almost all…we’re still working on our sessioned code) from Classic ASP (VBScript) to PHP.  The company was started in 2002 and at that time ASP was a common technology on the web, and one that our founders were familiar with.  After 8 years of working with it, we had pushed it to the limits and decided we’d get more benefit out of moving to a new technology.

Motivation for Switching

While ASP is still in extended support, as a language it hasn’t been actively developed for a number of years (I tried to find out exactly how many years, but my Google searches were fruitless, which might tell you something).  It’s also a proprietary Microsoft language, so we were unable to make modifications ourselves, so any bugs we found were not getting fixed.  ASP’s age also means that there are very few companies using it, so the community is small and there are basically no open source projects written in it that we can use.  It was also getting harder and harder to hire developers with Classic ASP experience. While training people isn’t hard to do, we would rather hire experts who are going to help us squeeze every ounce of performance and functionality out of a language.

Once we decided to switch, we obviously had a huge number of technologies to choose from, so why did we end up with PHP?  We had a few goals in mind when selecting a language:

  • Open source language that runs on an open source stack
  • Actively developed and widely used with a strong community
  • Longevity – we wanted some indication that it would be around for a while
  • Procedural and easy to learn if you have an ASP background (we do have 50+ engineers who know Classic ASP, after all)
  • Not a framework (perhaps I’ll blog about the logic behind this at some point…)
  • Good performance and good memcached integration

Given these requirements and the experience of the people making the decision, PHP seemed like an obvious choice.  With Facebook and Yahoo! using PHP extensively, we think it will be around for a while, and the community is obviously awesome.  Writing PHP is also a fairly easy switch for people who are used to ASP (or any procedural language for that matter).

We also wanted to use this as an opportunity to revamp our entire software stack on our webservers and switch from VSS to SVN for source control.  Finally, the opportunity to refactor 8 years of ASP and clean up the codebase was a strong draw.  Our code had accumulated a fair amount of cruft over the life of the company, and a complete rewrite sounded like a fun way to fix that problem.

How We Did It

We lumped this rewrite in with a project to redesign our primary site from a UI perspective and move to a flexible, full-width layout.  Since we were overhauling a lot of the HTML anyway it seemed like a good time to rewrite all of the server side code.  The whole process took about 11 months – the first planning meeting for the project was on 9/1/2010 and the site went live to customers on 6/21/2011.  I led a team of five engineers that wrote 99% of the PHP during that time span (a couple of small projects were done by other engineers).  In general we divided up the code by site section, and as people finished their work on a specific page they just grabbed another one off the list.

We wrote some really basic translation scripts to do some of the grunt work and used online references to help in the beginning.  Overall, the translation portion didn’t take too long — added features and altered functionality took up most of the time (keep in mind the fact that we had a number of marketing goals with this project, as well).  It was a fun project to do, because every day we were making our code easier to read, more maintainable, and faster to develop.

Immediate Benefits

Aside from moving to PHP, we also moved to SVN (as I mentioned above) and our webservers went from running IIS on Windows Server to running Lighttpd on FreeBSD, with memcached between the databases and the webservers.  When you consider all of these changes, we got a huge number of immediate benefits:

  • Cleaner code
  • Much easier and faster code deployments
  • PHP syntax checking as an SVN commit hook
  • PHP standards checking as a commit hook (we use a slightly modified version of the PEAR standards).
  • Adding memcached to the stack improved performance dramatically
  • Much better documentation and a better community around our core technologies
  • Access to all of the open source PHP software that exists
  • Free web tier software
  • Better job postings
  • Improved code performance with the APC Opcode Cache
  • Ability to preload all of our constants into memory and keep them updated via a cronjob
  • Arrays (yeah, it’s silly, but go try to use arrays in ASP and you will see what I mean)
  • Better scalability – we can serve many more requests with our current stack than we could with the windows stack we were running on.

The transition has gone very smoothly so far, and everyone seems really happy with our decision to switch.  I talk to engineers at Wayfair every day who write some ASP and some PHP, and they all agree that working in our PHP environment is significantly easier and more enjoyable.

Next Steps

We still have a lot of code in ASP, anything sessioned on our sites (like your basket and checkout), as well as almost all of our admin forms.  We are already in the process of converting the rest of the storefront code to PHP, but admin will take a lot longer.  Luckily it’s less important for us to switch that code over since it isn’t customer-facing.  Still, the goal is to eventually have no Classic ASP at Wayfair.

We also have a few things we want to implement or try out on the PHP side.  If HipHop starts supporting PHP 5.3 we might try that out, and we still have a lot of checks we want to automate when engineers commit code to SVN to avoid problems.  We have even played with the idea of going the Continuous Integration route with a full blown CI server that runs automated tests before code gets deployed.  We are wary of slowing down the deployment process though, so we still have some thinking to do on that front.

Whew!  Thanks for reading, and if you have had your own experience with large codebase rewrites we’d love to hear about it in the comments!

 


If this type of thing interests you, please visit our careers page, and join the team!
This entry was posted in General by Jonathan K.. Bookmark the permalink.
Jonathan K.

About Jonathan K.

Jonathan is a Senior Software Engineer at Wayfair. He leads the Web Performance team, which focuses on performance and scalability projects. In his free time he likes to play Ultimate, travel, and read web performance blogs (yeah, really). You can find him on Twitter @jonathanklein, and if you are in the Boston area be sure to check out the Boston Web Performance Meetup group that Jonathan started!

7 thoughts on “Switching from Classic ASP to PHP

  1. I had built a system in PHP. There are so many interesting concepts with PHP n LAMP stack. But one systemic concern which is not often seen and addressed is that MAINTAINABILITY of the code is totally put to a toss when pieces of code is to be modified….

    I might be wrong. But thought of sharing this thought.

  2. Hi Shrivatsan,

    We have found that our PHP is actually easier to maintain than our Classic ASP codebase, primarily due to the checks and standards that we put into place. I think with any codebase the question of maintainability is an important one, but regardless of language you can either do a great job with it or a bad job with it, depending on your programmers and your culture.

    -Jonathan

  3. Hi Jonathan, thanks for the nice post, did you ever used a framework like ZF, symfony etc in php ? or you guys just went for a plain classic php style?

    • We have played with a few PHP frameworks, but most of the time we find that we end up fighting them and writing custom code instead of working within them and reaping the benefits. As a result the rewrite was done with no framework, just classic PHP. At this point we have developed our own framework of sorts, with utility functions/classes, but nothing like a CakePHP, Symfony, or CodeIgnitor.

      We should have a whole blog post about framework use coming up at some point as well, which will shed more light on the decision making process. Hope this helps!

      • That’s cool, I am sure then you would have spent allot of time testing your code and figuring out inaccuracies :-), or wasn’t that a big deal?

  4. Reading this article 2 years later. Is there a follow up article to this that talks anything about moving the rest of the code & also on why you did not go with any frameworks when you considered PHP

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>