Time to Upgrade!

This week our team got together and started to focus on a new project: upgrading our site to Drupal 7. Drupalize.Me was originally built on Drupal 6 back in 2010 and the site is running very well, but we’d love to move up to Drupal 7. Aside from just playing with the great new features in Drupal 7, we also want to take a fresh look at the site and clean up a few things.

When we started building the site, we had a vision for creating a distribution around it as well, which has taken form as Videola. In the process of experimenting though, we ended up with some oddities in how we built the site, and legacy code and configuration which isn’t really efficient. We’ve also been expanding the site beyond our initial vision, and so the site has outgrown its original design britches, which ends up causing some pain points for both our members and our site team. Doing an upgrade lets us step back and clean up a number of things that bug us, as well as gives us the opportunity to implement things using new tools and techniques.

The upgrade process can be a very tricky beast, and we know this is a large project and learning experience for us. We are fortunate to be part of a great Drupal company like Lullabot, and we have not only our own experience to lean on, but also that of the rest of the Lullabot team. We’d like to share some of that combined knowledge. We plan to blog regularly throughout the next months about our planning and progress, so you can walk the upgrade road with us, without having to do any of the hard work. We always like to let people know what we’re up to but we also really hope that sharing our experience can help shed light on what it means to upgrade a real, running Drupal site from 6 to 7, and that you will be able to walk away with a few helpful nuggets for when you face a similar task.

We’ve recently launched a number of cool new features, like captions, guides, and our suggestion box, because members have been asking for these and we really felt that they are important. Now that we have those in place, we’re going to switch the existing Drupal 6 site to a “maintenance” status, which means we will mostly only be providing bug fixes and minor tweaks to the site, while we focus a lot of our energy on the new site and continuing to crank out new videos every week.

In the coming weeks we’ll be sharing more details about how we’re going about this, but this is a quick overview of our plan. This is all very loose and flexible, but we wanted to have a rough guide for what needs to happen to help us nail down some estimated timelines. We are currently planning for this to take five to six months, given the major pieces of work to tackle, the small size of our team, and job responsibilities we all have outside of working on the upgrade. We are going to be building a new Drupal 7 site and then migrating our content into it, instead of just running the Drupal update script on the existing site. In addition to upgrading the site to Drupal 7, we also want to do a design refresh (not a redesign) to address our main pain points. We have four major phases:

Phase 1: Getting started

• Design refresh: We want to keep the basic design of the site, but we have several pain points we want to address, so we need to define those, prioritize what we can get done during this upgrade, and let our designer loose on it.
• Basic Drupal 7 prototype: We are going to do a normal Drupal upgrade on a copy of the site. This will result in a base prototype with our current users, content types, and fields. We won’t worry about upgrading everything, we’ll be using only a few contrib modules and a core theme. This will let us play with a Drupal 7 site that contains our old data. It won’t be fully functional, but we can tinker with the users and nodes, and use it for research and testing of new solutions.
• Code audit/research: We need to see what the status of our contributed modules is, and determine if our custom code needs to be upgraded, or if there are other, better solutions out there in Drupal 7 now. We need to know what code we need to upgrade, both contrib and custom. Hopefully we can toss a bunch of it away.

Phase 2: Data architecture and Migration plan

• Architecture: We’ll come to an agreement about the data architecture for the new site and start to store it in code using Features and Profiler. Storing it in code will make it easy to replicate the prototype’s architecture on the new site.
• Data migration: As we agree on the data architecture, we can start mapping out our data migration plan. It is very important to start as early as we can, and come up with a way to make sure our migration keeps up with the new site we are building.
• Design refresh iterations: We’ll do iterations on the new designs as we see it take form, and get user feedback. We want to make sure the changes we are making will really fix the problems we see. (Keep an eye out for more info on how you might be able to help us with this.)

Phase 3: Build!

• Build and upgrade code: We’ll actually build out the new site, implementing our new architecture and designs, and upgrading our code as needed.
• Refine migration: We will keep our migration in sync with the work that we do so that we can catch problems as we go instead of getting nasty surprises on launch day.

Phase 4: Testing

• Test and launch prep: We are leaving a good amount of time for testing the new site, fixing remaining bugs, and running through our launch process so everyone is comfortable with the process and things run smoothly on launch day.

So that’s our starting plan. We’ll let you know how it’s going, and how we end up changing things, in addition to more details on each of the phases as we work through them. We’re pretty excited about the cool new stuff we get to do, and we’d love to have you along for the ride!