Content migration is one of those things most people don’t want to think about. Because we don't want to think about it, we do two detrimental things: 1. we label it as “bad” and 2. we push off migration decisions. Here are my suggestions for how to avoid falling into these two mistakes.
Problem One: Calling Content Migration 'Bad'
Content migration is so widely disliked that one surefire way to ensure an article's popularity is to write one deriding content migration. I sympathize with much of the sentiment behind these articles, but they are mostly in response to bad content migrations.
In a bad content migration, the entire website is indiscriminately forklifted over. That kind of migration should be avoided. The most obvious problem with this is junk content gets carried over in the migration.
But just because there are bad migrations (I would say most content migrations are done poorly) doesn’t mean content migration itself is bad. Yes, there are some cases where starting absolutely from scratch (and choosing not to migrate) may make sense, the most notable is when it’s a small site that is severely underperforming. But usually some amount of migration is necessary, even if we are deleting most of the content. This is because fundamentally, very few sites are entirely junk and we want to make the most of the content that’s already there (of the content we do migrate, we may need to migrate some content differently than other content).
My Suggestion: Consider a Wide Range of Dispositions
Instead of considering content migration as a binary either/or decision, content migration planning should be viewed as defining the content transformation in a more subtle manner.
A key component of this is assigning dispositions to content items. Different swaths of content will have different dispositions — we don’t want to swap out the error of forklifting everything over with another error of assigning a global disposition for all content. These dispositions can include a wide range, from simple to more involved. Here are four very basic ones:
- Raw delete
- Move as-is automatically
- Write from scratch
We could dive into any of these to be more nuanced. When deleting, some content might deserve deep redirects and some might be fine with 404s. When moving as-is automatically, does some content need to be transformed more (or differently) than others?
That said, it’s not enough to pick from any list, regardless of how nuanced the list is. What we need to do is align the priority of content with the effort spent on it. To do that, you need to look at your unique migration needs to define dispositions that appropriately match priority and effort. For example, you may want to spend more time on a few top-priority pages (and move some content to a lower priority, perhaps deleting more pages) rather than universally moving over all content using the same approach.
Related Article: Selecting a Migration Tool? Read This First
Problem Two: Push Off Migration Decisions
One side effect of avoiding thinking about migration is making migration decisions way too late. Late decision making tends to push the decision down to the person who is responsible for migrating that content. This means:
- Decisions in large migrations are less likely to be made consistently,
- It’s probably too late to course-correct (for instance, if you realize it would be much better to have the templates be more accommodating rather than expecting lots of content-by-content intervention),
- You’re more likely to prioritize what’s easy rather than what’s important, and
- A lot of time is wasted making decisions.
My Suggestion: Separate Deciding From Executing Content Changes
One of the best ways to frame things so that decisions are made in a timely manner is to separate deciding from executing content changes. More specifically, you can make early content decisions about your content without looking at every piece of content. Another way I sometimes put this is: “Decide. Don’t Inspect.”
How do you decide how to handle content without inspecting the content? Rules. You can say things like “We will delete all the press releases” or “We will rewrite all marketing material for our top three products.”
Your goal is still to have a list of all content with a disposition for each. So you apply the rules to your list of content in order to assign a disposition to each. Ideally, you automate the application of rules.
Why use rules and separate deciding from executing?
- Making decisions is much more efficient. You don't waste time looking at content that’s going to get deleted anyway.
- More universal, business-driven decisions can be made.
- The right people (for instance, senior executives) can be involved in defining the rules rather than just the people tasked with the migration.
- You are debating about rules rather than horse trading about specific content.
Although I stand by both of my suggestions above — consider a wide range of dispositions and separate decisions from execution on content changes — the main thing is to plan content migrations early. Even if you decide to delete a wide swath of content, you still need to plan to optimally leverage the strong content you almost certainly have on your site.