Migration Strategy: Using Your Inventory

Migrating your website can be a daunting task—especially when you’re in the thick of it. At CHIEF, we’ve seen it all—from 1-to-1 multilingual, proprietary CMS-to-Wordpress migrations, to Drupal 7-to-Drupal 8 migrations with complete redesign. Each migration is different, but with the right strategic thinking, none are impossible.

As a Technical Content Strategist at CHIEF, I specialize in facilitating and planning website migrations. What that really means is that I do database analysis to research a website’s legacy data and plan every detail of the migration so that when it comes time to move into the new site, things can flow smoothly.

Website migrations are an inexact science, but some things are fundamental. Thinking critically about your inventory, the different methods of migration available to you, and your resourcing can help you approach your migration with a clear head. I’ve been working with the migration team here at CHIEF to create a standard for our approach to migration and will be presenting this strategy at DrupalGovCon on August 23rd.

Over the course of the next few weeks, we’ll continue to share our approach to website migrations. Last week, Lindsay shared the importance of collaboration, communication and shared documentation. Today, I’ll dive deeper into that documentation—with what I believe is the foundation for all strategic decisions on a website migration: the inventory.

The Inventory

An inventory is comprised of anything that needs to move from one place to another. This can include:

  • Content Types
  • Taxonomy Terms
  • User Profiles and their Roles
  • Files and Assets
  • Any other data

Using the findings from a database and a site crawl, that data can be compiled into high level counts. These counts can make it easy to see where the content needs to go and how it should be migrated. As you look at your data, consider the following concepts:

Volume Vs. Complexity:

Your inventory should include basic counts of nodes within each content type. It should also include a breakdown of the field types and their complexity. Considering the size of each group of content compared to the complexity of the fields can provide insight on how best each one should be migrated. Consider the following scenario:

You have two content types: a blog with 20 complex fields and 500 nodes, and a bio with five fields, and 20 nodes.

Think about how best to move the data from one place to another. Perhaps you have a developer spend their time scripting the blog, while assigning the 20 bios to be manually migrated by your content strategist. Weighing the methods of migration, in this case, manual migration against scripted migration, allows decisions to be made one at a time and then delegated accordingly so that work can progress in tandem.

Frequency of Updates:

Your inventory should tell you how often pages are being updated and added. This piece of information is useful because it foreshadows how short the content freeze may need to be when it comes time to go live. If the site is updated frequently, you will need a short content freeze to make sure the site going live is as up to date as possible. Consider talking to your developer about scripting any part of the site that is updated often. This may save the team time tracking changes on the legacy site as you get close to launch.


Research the configuration settings within your legacy site. Things like pathauto patterns for alias’ and text format settings fall within the configuration realm. Your developer will need to know whether they will need to set up the configurations on the new site to match, or plan to add any tweaks.

The text format in particular can affect the way in which the data migrates. If the legacy site has body content with inline styling set to “Full HTML”, and that content is migrated into another body field with “Basic HTML” set, the inline styling could be stripped out.

Compile the configuration settings into a spreadsheet and go over them with your developer to make sure things line up.

Field Types:

Your inventory should include a breakdown of the fields associated to each content type. Including information about the type of fields involved is especially important for the developer to know about since certain fields in Drupal 7 sites, may be treated differently in Drupal 8 sites. Images, for example, may need to be stored in a Drupal 8 site using Media which is now part of Drupal 8 CORE.

Pointing these fields out to your developer early can help your team stay ahead of hurdles that tend to come up during the migration process.

Image of various field types

Example of a list of fields with field types

The Path Forward

Keeping these concepts in mind while you compile your inventory is the first step in putting together a comprehensive migration plan. Once you understand where the data is coming from, you can better see where it needs to go. Over the course of your project, and as new content types are approved and built in a new site, the data pulled from the inventory can be used to create a mapping document. This document can show where the legacy data should map to in the new site. For information on how to compile a comprehensive mapping document, stay tuned for the next post in our Migration Strategy Blog Series: Mapping Your Migration.

Want more? See my upcoming presentation on Drupal 8 Migrations: How to Be a Resource for Your Team at DrupalGovCon, Thursday, August 23 at 2PM.

Have your own tips for streamlining the migration process? Share your ideas with us on Twitter, or subscribeto our newsletter to stay on top of industry trends!

Get alerted to new job postings, events, and insights by registering for our monthly newsletter.