Upgrade Status: Phases 1 and 2 Complete

It has been a few months since we started our site upgrade, and I wanted to give an update on our progress. We are a small team of three, who manage the site and create most of the videos, so needless to say we've gotten a bit waylaid on our schedule. We've also had quite a bit of fun distraction with our Lullabot company retreat (which was sooo fun!) and DrupalCon Munich (which was amazing). So, while we're not as far as we wanted to be, we have gotten a good chunk of work started, and we're through Phases 1 and 2!

Site prototype, architecture, and basic migration

We were very fortunate to have some of Karen Stevenson's time at the start of the project to get our initial upgrade migration started, as she has worked on a number of large Drupal migrations. She started things off by creating a very simple Drupal 6 to 7 upgrade with only our essential modules — basically anything that had a major impact on our content types, like fields and the like. She ported the minimum needed in our custom modules, recreated the content types in Drupal 7 in Features, and used Migrate module to map our old content to the new content types. She also mapped other site essentials like users and taxonomy. She even wrote up an installation script so everyone who needs to work on the new Drupal 7 site can clone the repository, create a database, and do a fresh install of the new Drupal 7 site with all of the content types in place. Then we just need to have a local copy of the Drupal 6 site, wire it up in our settings.php file, and run the migration from the UI that Migrate provides. It is pretty amazing how much she got done for us.

Some people may ask why bother with Migrate module to just move the content from one Drupal site to another. As we work on the upgrade, we really want to make sure the migration is keeping up with us, so we are setting our development site up with Continuous Integration (CI). This means that the development site will automatically get completely rebuilt on a regular basis using a fresh copy of our live database, and run through the entire migration process. As we change things on the site, we'll be able to see if there is a failure in the migration process so we can fix it right then and there. No one likes to be surprised by a migration failure on launch day! We'll have more information on how we're setting up our dev site shortly.

Design refresh

We have quite a lot of work done with our design refresh. We aren't going to radically change the way the site looks or functions, but we do want to address a few pain points. We are through almost all of our wireframing, and the visual design mocks are over halfway there. Having the wireframes ready to go has clarified a number of architectural decisions we needed to make, and is certainly going to make it much easier for us to build out the site, without having to backtrack all the time with new ideas. Since we have our major visual elements in the design mocks, we're also in a really good place to begin theming the site as we build. Now we just need to decide whether to use a base theme or not, and if so, which one. ;-)

Module audit

In a module audit we look at all of the existing modules, contributed and custom, to assess what the upgrade plan is for each. We created a big spreadsheet with two tabs on it for our audit. One tab has the contributed modules on it, and the other is our custom code. Several of us have gone through the lists and made notes about whether we still need that module, what possible upgrade paths exist, etc. We've now winnowed the list down to the things we still need, and we've ended up with a nice, small list of modules that we will actually need to upgrade ourselves.

For contributed modules, we started with a list of 125 modules and we managed to eliminate 80 of them. Whoa! Well, part of that is because we will not be using Ubercart in the new site, and that eliminated a lot right there. There are also some modules we don't need because core handles more things for us, a bunch of modules that we really just don't use so we should get rid of them anyway, and of course, there are NEW modules we'll be adding in Drupal 7. So that number is a little misleading.

For custom code, we have 48 modules (!), but 17 of those are features, so that makes a little more sense. In our audit we managed to get rid of 23 custom modules, again due to some simply being unused, or finding features we want in contributed modules instead.

After our audit (but before we've really gotten into the nitty-gritty of building ;-)), we know the modules we'll need for almost all of our features, we don't need to upgrade any contributed modules we currently use, and we have 25 custom modules to attend to (8 of which are features). Not a bad start at all really.

Next Phase: Build! (and maintain)

Now that we're back and settled from DrupalCon, we're gearing up to dive back in and get cracking on building out the new site. We have a nice starter site with our main data in place, so now we need to recreate things like our views (which don't migrate), and construct (or re-construct) all of the other goodies we have on the site. You know, simple things, like membership payment and management....

To keep things moving along, we're going to do the upgrade work in a pseudo-agile process, where we will work (sprint) for two weeks, and then do a site demo to show each other our work and keep a check on where we are. The first of these new sprints started this week, and we are mostly focused on getting our dev site and CI set up, along with rebuilding our views and features. It should be fun to see our progress and share it with the rest of the Lullabot team every other week. Hopefully the short iterations will keep us focused and energized, even the midst of everything else we're trying to get done.

While we're having fun banging on the new site, we also need to maintain the existing site, and keep up with bugs there. We've set up a different development cycle for the Drupal 6 site, where we have four week "sprints" instead, and we will release tweaks and bug fixes only once a month.

So, we're still here, cranking away, and now that we're truly back in the saddle, you should see some more regular updates on our progress. Stay tuned!

Add new comment

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <code class> <ul type> <ol start type> <li> <dl> <dt> <dd><h3 id> <p>
  • Lines and paragraphs break automatically.

About us

Drupalize.Me is the best resource for learning Drupal online. We have an extensive library covering multiple versions of Drupal and we are the most accurate and up-to-date Drupal resource. Learn more