Taking your site from Drupal 6 to Drupal 7

Editor's Notes

• #3: ----- Meeting Notes (7/21/11 22:05) ----- Here's a quick overview of what I plan to cover. The topics I plan to discuss will be from a high-level view of what's needed to take your site from Drupal 6 to Drupal 7; whether that's upgrading your site, or building something completely new in D7 and migrating your users and content to it. I won't get into great detail, but I certainly hope to push you in the right direction.
• #6: While you can keep the site’s look and feel to the average user, drastic shifts in modules and site administration will possibly require retraining (for site editors, content producers, etc)
• #8: Don’t get left behind: As module development shifts to D7, D6 support will dwindle – module maintainers only have so much time. New versions or features will be introduced in 7.x versions, as well as bug fixes – typical behavior is to fix in the latest version (HEAD) and backport to 6.x if warranted and as time allows. Site cruft: Sometimes, as a site gets on in years, cruft (either development or content) keeps a site from being maintainable in its current state. Then, a redesign or site refresh is in order.
• #9: Determine how much of your site can easily be upgraded. Drupal Core, most popular contrib modules, and themes have upgrade paths that will update site content for you.
• #10: Converting themes from Drupal 6 to Drupal 7 -- has 60+ changes to Drupal 7 theming. Template file changes (like html.tpl.php), block changes – helpful names rather than numeric IDs (CSS selector wrangling); region changes like right and left sidebar became first and second sidebar; primary and secondary links became main_menu and secondary_menu. Render arrays! Render arrays are the building blocks of content; structured content not rendered into HTML until the last possible moment. Think about Forms API arrays. When we went from 4.5 to 4.6, you no longer built your forms in HTML; this allows for hook_form_alter – preprocess and postprocess hooks in theme now.
• #11: This is kind of a non-sequeter, but it’s useful to get this out of the way now, to talk about the tools that you need in your arsenal
• #12: Show-stoppers – required functionality Next round upgrades – What’s used, but not required for immediate use (reporting, newsletters). Identifying these can make upgrading your site faster and can keep the budget down for things that can be handled later. Better ways? – Perhaps there’s now a better way to do what your site did. Context and Features are all vast improvements to development and maintenance workflow that weren’t likely available when your site was first built. Nice-to-haves – What features to users occasionally use, but perhaps aren’t worth the effort. Alternative replacements -- What can be replaced with third-party plugins? There are more widgets available now than when the site was first build (Disqus, Wibya) Cut list – identify site cruft and what things can be left on the cutting room floor.
• #13: Compare this inventory with what has 7.x versions. Modules may require fewer dependencies now that some contrib modules are in code. Dependencies may have changed if a previous dependency module was deprecated. Might have new dependencies. You may not need to keep some modules if they’re no longer required. This allows you to establish a level of effort (LOE) for upgrading your existing site vs. building a new version of your site and migrating content. Determine if you can live with beta versions. Sometimes, beta means it’s got bugs. Some developers use “beta” to signify level of maturity, *not* the level of quality. May go through 10 betas before releasing a 1.0; many times, these beta versions are fine. But sometimes beta isn’t production ready (not all functionality is complete, etc). Read the issue queues
• #14: Some modules have migration or upgrade documentation right on their project page (or they link to documentation from their main project page). Issue queues aren’t just for bugs. Look in module’s issue queues to determine upgrade issues and tips. When you get stuck, you should realize that you probably aren’t the first one, so check the issue queues. Check the forums also, for tips on upgrading particular modules. Drupal search is your friend, and Google is your BFF.
• #15: Chances are, you’re going to have to replace some outdated, deprecated, or abandoned modules. It happens. It even happens when working within the same version of Drupal. Maintainer of Nodewords is a co-maintainer of Metatags, and *is* working on a migration path.
• #16: Don’t do this in your main development environment. You want to use a new, fresh development environment (another vhost is fine, shared hosting is fine, just use a different database and code base). You’ll want to refer back to your main dev site for comparison as a control. You’ll also want to take snapshots of code and database along the way. Think of it as save points in your game.
• #17: There’s some really thorough documentation on Drupal.org to walk you through step-by-step in upgrading core. It’s very detailed and will basically hold your hand through the whole process. Distilled down, these are the main steps of upgrading Drupal core.
• #18: There’s some great documentation linked from the main CCK project page that walks you through upgrading your custom content types to Fields API. The D7 version of CCK does *not* do any custom-content, that’s what Field API is. CCK in D7 is primarily a bridge between old CCK and Fields API.
• #19: It’s important to do this one at a time. Start with dependencies, then work your way up through the highest priority modules. Views?
• #20: Module builder doesn’t help upgrade much; but in the event you need to throw together a custom module to help, Module Builder will help with a module’s skeleton quickly. Advanced Help will have information about upgrading Views from 6 to 7.
• #22: If your scripts can access your data, most likely, so can anyone else. Be particularly careful to avoid exposing your user data. Depending on your privacy policy, depending on your local or state laws, if you expose your user data, you may be in hot water. Even if no one finds it, just the *exposure itself* can cause you some headaches.
• #23: Might want to check out table wizard and Data modules; not sure the status, but they both do well to expose data that you might want to import using Feeds module in your new site.
• #24: Migrate module has a very robust API to migrate content. Uses Batch API to keep the process running without timeouts. Can save progress; can stop and restart migration. Also allows for incremental migration – you can migrate everything you have now, but while you’re working on the new site, users are adding new content. This allows you to migrate only the new stuff.
• #25: Backup and Migrate lets you backup your database and lets you cherry-pick tables. It does some automation of database table backups to potentially help with incremental migrations. Doesn’t *do* anything to your database tables; it just backs them up and you can import those into your new site. Doesn’t handle relational data integrity or anything. It’s perfect for just moving over custom tables to your new site.
• #26: Table Wizard, Data, Views RSS – all let you access data in ways that you can spit out any feed type that you want: RSS, Atom, Custom XML, CSV, whatever. You can use Views with arguments to handle different types of data that you want to port to the new site. Feeds replaced FeedsAPI module. Feeds will let you define your own parser if you need to, and define what happens with the date from your feed – how it gets inserted into the new site.
• #27: Direct database connections bypass the need to have exposed data and data parsing, and cuts right to the chase. Might be preferable for smaller jobs, and when using shared environments. Will need to do a schema load prior to switching the active database to prevent a chicken-or-egg scenario.
• #29: There are few things in this world more frustrating than watching a custom migration script run for 5 minutes, and then just timeout. Passing values by reference instead of by value helps reduce your migration script’s memory footprint.