I just finished another big site update from Drupal 6 to Drupal 7. No question this one was easily the most complicated one I've done so far. The site is full of node references, theme overrides, and custom fields. These Drupal 7 migrations upgrades have so-far been fairly straightforward - just follow the step-by-step and all has worked out fairly well. Not so this one.
I'll spare you most of the gory details. Maybe when the battle fatigue wears off and the wounds scar over I'll put up a post or two about it. For now I just want to leave you with a couple of, OK looks like it's 3, things to think about (and for me to remember) when someone comes to you asking for this kind of help.
- Be aggressive with your estimate
I like to be as competitive as possible when it comes to estimating how long, and how much money, an upgrade will take. At the end of most jobs I like to feel like I put more into the work than I had originally planned. This is a choice. I don't work for people for whom I wouldn't go the extra mile. I'm learning, however, that the extra mile won't get me even half-way to Drupal 7 in some cases.
My takeaway from this latest site update: A migration from Drupal 6 to Drupal 7 can take a lot longer than you might think.
- You can't depend on modules to do exactly what you want
- Be ready to buy more server
This last migration experience taught me that there is a performance price to be paid for off-the-shelf data migration. No, I don't think Drupal 7 is a step backwards in performance. In fact I think it's a big step forward in more than a few ways.
I do think there is a risk for performance loss in Drupal 7 if we're not intelligent about how we migrate our old data forward. It might only take a few lines of code in a custom migration module to cut both the duration and number of database queries. That's well worth the effort in my book.
But if you're not ready to dig through core and contrib to understand what's going on under the hood you won't be able to shorten the path Drupal takes from that first call to index.php to the last byte of html out the door. Lucky for you, there's always a bigger server out there somewhere. More memory, storage, and bandwidth will save the day.
Drupal modules, the ones you download from contrib, can only do so much. Try as they might, Drupal's huge and well-meaning community of module contributors, cannot possibly foresee (and code for) every possible use case.
If you wanted to apply a style to an element in Drupal 6 using taxonomy you had a several choices. If you wanted that style to include an image which itself is a node your choices were drastically reduced. Node_reference and some custom templating would get the job done.
In Drupal 7 taxonomy terms are entities, so images / styling can be directly associated with terms. (BTW, if you need this kind of functionality, this in itself justifies the Drupal 7 migration)
See the problem here? In Drupal 6 we used CCK, taxonomy, a contrib module, imagecache perhaps, and a little custom template magic. In Drupal 7 you can do the whole thing in core plus a template function or two. But the good people who bring us the modules we used in Drupal 6 can't possibly know how we bent them to do our bidding and how we want that functionality to look in Drupal 7. We have to rely on ourselves for this.
I know this idea would never fly, but I do think it would be better if they didn't try so hard. I personally think that highly customized sites can't possibly benefit from all the extra work that goes into the migrate/update functions these guys write. I know it's an 80/20 thing; but I tend to think they're shading toward the 90/10 side. The Drupal world could use that 10% elsewhere. There's always another corner case; and trying to accommodate just a few more leads to bloat. Which brings me to my 3rd thing to keep in mind.
