Beyond Forklift and Nuclear Content Migrations

Key Points

Although we may fantasize about starting from scratch, a hybrid content migration approach is usually the answer.

Even if you only do nuclear and forklift options, different buckets of content probably should be treated differently.

One of the main reasons to not start from scratch is this presumes a redesign-forget-redesign mentality.

Related resource

Dispositions Cheat Sheet |
Use this sheet on your projects.

In general, organizations can achieve more from their content migrations. Starting from scratch sounds high quality. Forklifting over content sounds easy. A hybrid approach is usually best.

The forklift and nuclear approaches

Teams seem to be stuck in two main styles of migration: forklift (just move the data) and nuclear (don’t move anything and instead start from scratch).

The forklift approach

The inspiration for the forklift migration makes sense: if we already have content, then let’s move it over in as straightforward a way as possible.

Sometimes forklifting does make sense, for instance when the content is already high quality and it also meets current business needs.

But it isn’t always the best approach since:

the content already there may not be very good

we may need to change the content more than can be done in a mechanical fashion

we shouldn’t be optimizing for what’s easy but what’s important

it can mean devaluing content as an organizational asset

That said, IF the forklift approach will be taken then it should be automated if at all possible. Note that even with the forklift approach we can't consider the migration done until we see the content in context of the new templates.

The nuclear approach

The inspiration for the nuclear option also makes sense and includes: our content is so poor already, so let’s just drop our current content and start from scratch. In many ways, this is also in reaction to poor outcomes from some forklift migrations.

There are a wide variety of problems with this approach but two of the most important are:

It presumes a redesign-forget-redesign mentality rather than an ongoing management approach — put another way, what’s to stop the problem from rearing its head again in a few years?

It takes a lot of effort to write high-quality content from scratch.

I would say this option only makes sense if both your content is truly very low quality and your end site can be small. This is a pretty restricted case. Some of the reasons starting from scratch usually doesn't work:

Site visitors often do need to eventually get to details (providing context and focusing the experience is important, but at some point, the visitor may need to get those product specs).

You may have source or definitive materials (for example reference data, original research, and technical product information).

Your business may cover a lot of ground, so rewriting key information for all of your business may need to be phased in.

It takes a lot of effort to write high-quality content.

It is certainly true that if you really are going to get rid of the vast majority of your content then the nuclear option makes more sense than the forklift option.

The distance our content is traveling, writ large

If we consider the distance (there are other aspects to distance during a migration — here we are just looking at the degree of content change write large) between where we are now and our new digital presence, staying completely as-is is clearly making no change, with the forklift being some change and nuclear making a dramatic change. As mentioned above, a complete nuclear approach only makes sense in limited cases.

But in general what we really want to do is considered improvements, where we:

Make key business-driven changes...

... to key content.

So in other words we aren't just saying ALL content is going to be moved over in a relatively similar way, but that some key content will get special treatment.

Some content should be treated differently than other content

In real projects the different types of migration dispositions will probably more nuanced than forklift and nuclear, really covering that middle distance between (marked "considered improvements" above). The following is showing a sample snippet from a large migration (each row was a type of site, and each type of site had multiple sites), where you can see elements such as: whether the content has to be rewritten or restructured, how content flows (implying tagging time during migration), PDF treatment and other aspects.

Discuss what content is required to attain that vision + conceptually how the site needs to be organized.

Define rules for what existing content has to be completely rewritten, dropped, or other moved as-is (you may also look at other dispositions such as leaving the content where it is) + what brand new content is needed (to meet that vision).

Some of those rules will mean that you don't need to analyze some content in more detail — for instance, you may decide to drop entire microsites that were created over time. For the content that does need to be analyzed more, create an inventory that you can then apply the rules above to (consider multiple sources of information).

Estimate the manual effort it will take to pull that off, and repeat the above process until you get to a manageable set of rules.

Apply those rules on an ongoing basis (for instance, define a lifetime for microsites and regularly decommission them on that schedule).

In this way, we address those problems with a completely from-scratch approach, for instance by moving over the high quality information that does exist, with the added benefit of keeping the information high quality over time. Also, we don't wind up with an overly-ambitious plan that we cannot execute on. Note that as a side benefit this is a methodical way to determine that actually you do need to start from scratch from a content perspective!

With this process you still may drop a dramatic amount of content. But, although we might like to, starting purely from scratch probably doesn't make sense for any but small sites.

Put another way, content migration planning is much more subtle than a decision to either a) ram in the content from the existing site or b) don't move anything at all.