Migration; More Than Monarchs

Hi. Please read the next paragraph in your best David Attenborough voice.

When the majestic monarch takes flight on its marathon migration to Mexico, it’s easy to be moved by its mission. Each year hundreds of thousands of small, winged creatures take to the sky with a common goal: survival and prosperity. No single butterfly completes the trip by itself, but as a group, they complete one of the most remarkable journeys in the world.

Okay, back to your normal voice now.

Migrating your website doesn’t usually have the same visual impact, but behind the scenes, it can be just as impressive as the monarch’s multigenerational marathon migrations. Ask any experienced Drupal developer, and they’ll tell you that the amount of work that goes into a website migration can be just as much work as the monarch migration. They’re transferring an entire website from an older version of Drupal to a new one (Drupal 7 to Drupal 9, for instance), making sure everything stays the same and still works.

There are a plethora of different reasons to migrate your website to a new platform, and we’ll talk about some of the common situations a little later. Specifically, we’re going to be focusing on migrating a Drupal 6 or 7 site to Drupal 8. This information will get you ready for Drupal 9, the latest release of Drupal coming later in 2020. However, a lot of this general information also applies to site migrations using other Content Management Systems (CMSs), so if you aren’t on Drupal, don’t worry! This article isn’t useless!

So what’s migration, and what does it mean for your site? In straightforward terms, website migration is the process of copying data and configurations from Site A (built on Platform X) to Site B (built on Platform Y) and using that data to create users, nodes, configs, and components automatically. Essentially, you’re transferring every piece of content and data from one system to another. These systems can be anything, from an old WordPress installation to a new Drupal installation, for example, a Joomla site to a Concrete5 site, or even an old Drupal 6 to a fresh Drupal 8 installation. It’s important to remember that your beautiful monarch, built out of content and configurations, isn’t what’s changing. It’s migrating to a newly built home that’s already familiar to it.

Uhh… That sounds like too much work. Why would you ever want to migrate your site? Fear not true believers! I’m going to walk you through an example! Let’s play make-believe for a minute and say that you’re the owner of WidgCo, makers of the most excellent widgets in the whole world. Still on the same page as me? Okay, cool.

You originally built your website back in 2008 using Drupal 6 so that WidgCo had an online catalog for the 347 widgets you offer. Users would find the part numbers on your website, and then call your ordering phone line to make the purchase. The types of products you provide, the price point of those products, and most importantly, the buying habits of your typical customer meant that online purchasing wasn’t a feasible way to go right off the bat. Your clients are used to picking up the phone, reading off the part numbers they want to one of your sales reps, and then they get mailed their invoice at the end of the month.

It’s 2020 now, though, and your customers want to be able to finish all their widget ordering and invoice payments online. You’ll need to install a module enabling e-commerce on your site to meet their modern expectations. Since you’re dealing with sensitive financial information, you’re going to want to make sure that it’s as stable and secure as possible. Bad news, however. You’re still on Drupal 6, and the module developers have stopped supporting the Drupal 6 and 7 versions and are only updating the Drupal 8 version. To get the new features, you’ll have to migrate your site from your current older version of Drupal to a more modern version.

Now that we know why we need to migrate, the next question, of course, is, “How do I migrate?” As usual with these sorts of things, there are different options around how to migrate your website. No matter the method, though, the first step is backing everything up! If something goes wrong and your site breaks, you’re going to be left high and dry if you don’t have a proper backup ready to rock. Once you’ve got everything safely backed up, we can move on to the next step, where we finally start the migration.

Here’s where we hit a fork in the road. You can choose one of two main methods to perform your migration: automatically using the Migrate Upgrade module, or writing some good old-fashioned code by hand and doing it manually. To pick which method is best for you, you need to ask, “is my content model going to change?” Is your website content going to be staying mostly the same? Is it going to be organized in the same way on the new site?

If your content is going to stay pretty much the same, then automated migration using the Migrate Upgrade module is the way to go. You’ll save your time, money, and sanity. When you go the automatic route, the module automatically analyzes your Drupal 6 or 7 website’s content model. The module will detect content types and configurations on your site, all by itself. Once it’s done, it will automatically generate the proper content types and configuration for your new Drupal 8 site. If there are some little changes you need to make, the Migrate Upgrade module has an API available to developers so that they can make alterations or customizations to the process.

I don’t know about you, but that’s all a bit confusing to me, and I’m the monkey writing it. I’ll use another one of those handy-dandy, fancy-schmancy metaphors to explain it a bit differently. Imagine that your website is the building where our fictional WidgCo is headquartered. The building is no longer suitable for your company and to keep growing and progressing, so you’ve got to migrate to a new office. See what I did there?

When your workers built your office, they used the best, most advanced materials they had available, but over time they’ve deteriorated, decayed, or shown to be unsafe. The ceilings are filled with asbestos, the horrid fluorescent lights won’t stop flickering, and nobody is totally sure what the original color of the carpet was (wait, is this even a carpet?). Having said all that, the layout of the building has been great for WidgCo. The locations of team leaders relative to their team members have been carefully optimized. The processes of the quality assurance folks on the assembly line are perfect, with every widget leaving WidgCo meeting your exact tolerances. Even the way that employees clock in and out every day is just how everyone likes it.  You need a new building that can be updated, upgraded, or renovated moving ahead. At the same time, you need to keep your optimized office layout, your excellent employee roster, and your perfected processes precisely the same. Otherwise, WidgCo will lose productivity, fall behind, and miss out on money. You need to plan your move so that your workers and clients can come to your building and keep going about business as usual as if nothing changed.

That’s what migration can do for you. Automated migration will look at the old building (your old website), identify the different teams, where they sit, and what their processes are, and it will automatically categorize all of that information into a plan. By having this plan in hand before you move into the new building, you’re able to replicate the old office floor plan exactly. Even the thermostat was set to the same setting. In web terms, that means all your content, pages, blog articles, galleries, users, and everything else are functioning correctly in the correct places.

Performing a migration by hand is a similar process. Instead of having your plan automatically generated, you and your development team go through with custom scripts and code to manually categorize and sort your site data. Instead of a program automatically sorting and classifying your data, your team can identify specific elements of your website and dictate precisely how they should move them to the new site.

Okay, that’s enough for now, I think. I don’t want to overload my brain, let alone yours! This article is just to serve as a high-level overview of what migrations are, how they work, and why you’d need to perform one. It’s been a lot of info, but we’re only scratching the surface of migrations. There are tons of tiny technical tidbits we could touch on, but unless you’re a web developer, it’ll mostly be gibberish. For now, though, I hope this has been a good primer on the topic.

Our expert team at Cheeky Monkey Media kicks ass at this stuff. In fact, we’ve put together a full Drupal whitepaper, just for you. If you need a hand, have any questions, or are interested in learning more about working together, don’t be afraid to reach out! We’re always happy to help and share some of our nerdy knowledge.