At work, we’re migrating a 10,000+ page site with 300+ editors to a single Drupal installation. At first, the task is extremely daunting, but if you learn to embrace the confusion, stick with it, and plan accordingly, a task as massive as this is absolutely doable and even rewarding!
I started a “Drupal Migration” category on my blog to document our journey to the promise land in hopes that it will help others in the same situation. I’m going to be talking in ideals here, but know that it’s basically impossible to stick to these absolutely. If you make an honest effort, gains will be had, even if you don’t execute perfectly. I’m going to go over where we’re currently at in this journey.
Work hard. Don’t be an asshole. Share what you know.
– Brad Frost
Define the problem
Moving to a new CMS for no reason is a great recipe for pain. You need to have clear goals if the project is going to be a success. Some people on your team will be behind the goals more than others, and that’s absolutely fine — that’s life. As long as you know what you’re working towards, you can control the parts of the project that’s within your grasp.
In our case, our main goals for migrating are to have:
- Reusable, structured content
- A better editing experience (we’re migrating from Ingeniux)
- Improved content quality
- An updated look and feel
I’ve read articles on how people + process + technology is the magical equation for a successful IT related project. It’s naive to try to solve all three on your own. Establishing who is in charge of each of these areas will make the project go much smoother. Plenty of teams complete projects without balancing these three criteria, but I bet they have a few more grey hairs afterwards. The focus of most of these posts will be on technology and process, although I’d be willing to bet I touch on people as well.
Plan it out
Let’s clear something up right away. Drupal is not like WordPress. It’s not a CMS that you can slap a theme on and instantly have a site. It’s not like Webydoo, Wix, Weebly, or any other drag and drop website builder. It’s so much more than that. It can handle anything you throw at it, but you have to have a plan and understand how it works. This takes time. If you’re 2 weeks away from a deadline and you want to jump into Drupal and whip up a complex site, you’re going to have a bad time.
Since that’s out of the way, let’s talk about planning. When you’re migrating to Drupal, you’re not just shoveling content over from your previous CMS. If that’s your plan, you’re doing it wrong! I’d assume you want to move to Drupal in order to take advantage of how Drupal handles structured content. What you’re really doing is building a data layer for your entire organization. It’s so much more than a CMS.
Drupal and content strategy go hand in hand. Being able to think abstractly about your content will ensure you get the most out of Drupal. For example, in the context of a University website, what is a department page? What does that piece of content consist of? If you want to pull information in from other areas of your site, mapping out the structure of your content is absolutely vital. Nail it down, have meetings, have arguments, just figure it out. In our base case, we decided departments consist of:
- A featured image
- Positioning statement
- List of degree programs
- List of faculty
- Student opportunities
- List of events
- List of announcements
- Contact information
Items listed in bold refer to separate pieces of content which all consist of their own pieces. For example, abstractly, a faculty member might consist of:
- Photo head shot
- Full name
- Research interests
- Office hours
I could go on, but I hope you see my point. If you can think abstractly about the different pieces of content on your site, Drupal can help you weave this information together into something useful. I’d highly recommend reading Palantir’s Plan or Perish blog post. They do a fantastic job of explaining the importance of planning.
Dare to fail
Unless you are a Drupal expert, it is very likely that your first try will be less than ideal. Drupal is a powerful, yet complex system. Give yourself time to learn the platform. Make mistakes. Break shit. Learn what doesn’t work. Acquia has a free development tool that allows you to mess around with Drupal on your local machine before committing to a live site. It’s much better to break stuff in a development environment than in production. The more times you fail, if you learn from it, the closer you are to succeeding.
Reach out for help
Drupal has a robust community of professionals that, in my experience, have been super helpful. To avoid a RTFM response, I’d recommend playing around locally and learning the ropes before reaching out to the community. Not because they won’t try to help you, but because there’s certain concepts that you learn about Drupal only after experiencing it first hand. Drupal.org is kind of a mess, but there’s lots of very useful information there. Take the time to learn.
Once you have a decent understanding of how some popular modules work, reach out to the community for clarification of how to reach your goals. I’d recommend having a good grasp of how the following modules function before you can really benefit from the community’s help:
- Organic Groups
- Page manager
- Am I missing any?
As I said earlier, Drupal is complex, but learning basics about the system will reap major benefits when you go to implement your site. Also become familiar with the following Drupal concepts:
- Contextual arguments (within Views)
- Relationships (within Views)
- View modes
- Theme layer basics
I’ve recently re-discovered the treasure trove that is IRC. IRC is where a lot of community members hang out, talk about Drupal, and help people with questions. I’ve had some great success in asking questions in #drupal, #panopoly, and #drupal-support channels. I’d highly recommend downloading an IRC client for your computer — or use KiwiIRC if you want to try it out — and logging into Freenode.
That’s currently where we are in the process. We’ve hammered out most of the project requirements, got our hands dirty in a Drupal development environment, thought abstractly about our content, and gotten involved in the community. You may be thinking that’s a lot of work for still not having a live production site.
I’d agree that it’s a lot of work, but I’d rather measure twice and cut once.