Alexis Bellido migrated eighteen sites for a top publisher to Drupal 7 and lived to tell the tale. He’ll be presenting “A Tale of Migration: 18 Sites to Drupal 7” at NEWDcamp (New England Drupal Camp) on Saturday, November 1st.
Alexis answered a few questions about his upcoming talk.
Give us a quick preview.
To set the stage, I’ll tell folks about the moment I was assigned to the project. It went something like this: “So, Alexis, there’s this publishing company running 18 sites on a proprietary CMS and they want out. We need to port them all to Drupal and you’ll take care of data migration, all right?”
You don’t wake up every morning expecting to hear something like that and the first thing you think is “Damn, first they hang Brody and now this?” I’ll talk about my research process, the tools and approaches I used, my mistakes and the first launch.
It’s a very fun, and sometimes scary tale, including an appearance by the villain, The Old CMS XML. So fun, in fact, that I’m bringing my 13-year-old daughter to hear it
What are a few things you’d love your audience to walk away knowing?
A website migration is a complex endeavor that has to be carefully planned. Most times, once you flip the proverbial switch, there’s no easy way back. You have to get it right the first time or you’ll have a never-ending emergency in your hands.
After the talk, I’d like attendants to:
- be able to build a smart and customizable migration process that can easily be run as many times as needed.
- pay close attention not only to data but also behavior on the current site in order to determine how to best implement on the new one.
- devise a rollback strategy in case something goes wrong (something always goes wrong).
How did the client benefit from the migration?
A proprietary CMS can cause a lot of different headaches, but the issues basically fall into two categories. First, they require a major investment to build, test, and maintain, and there’s no open source community like the Drupal community that has your back.
Second, because it’s so challenging just to keep your CMS up and running, you probably don’t have time to focus on the details of the publishing interface. This means that your editorial staff won’t have as nice a user experience as they would on a CMS like Drupal, and that can affect their productivity.
There are very few organizations that can properly support a proprietary CMS, and even fewer that actually need one. And of course, your readers don’t care what CMS you use, so why not save money and make your staff happier by switching.
What was the most impressive technical feat you pulled off with this project?
I wouldn’t use the word impressive, but I feel very confident about the set of drush and bash commands –– yes, good old bash, ladies and gentlemen –– that I wrote in order to talk to a bazillion XML files and Drupal’s API. They allow me run, tweak and reset the migration process as many times as needed and are easily extensible using object-oriented PHP. All of this from my beloved command line.
Ok, on second thought, I might use the word impressive.