Content migration — easy, or better?

There seems to be a constant rush to declare migrations easy (usually promoting some tool or other).

I think this is radically misleading as an industry for several reasons:

• In an effort to prove that the migration was easy, the promoter uses such a narrow definition of “migration” (and specifically the easy part) that although perhaps technically true it overlooks lots of real work that the organization still has to do to make the migration a a success (in other words, the entire migration).
• Put another way, it shifts risk /effort from the technical team (be it a team, tool, vendor, or combination) to the rest of the organization. I have seen many cases where the technical part of the migration is first approached as a best effort (but where the migration is “done” regardless) at which point the content teams need to clean up, but this is not a very effective way to operate.
• It trivializes the opportunity for a migration to improve quality.
• Migration is an opportunity to prune a site, so our goal shouldn’t necessarily be how easy it is to move all the content.

Migrations are each very different

Each migration is very different, attempting to achieve very difficult goals (take this self-evaluation). Sometimes the migration truly is a completely technical migration, for instance in an emergency move between platforms. Sometimes the site has to change so much that only a tiny fraction of the content will move relatively as-is. Sometimes the issue is more about dealing with duplication across divisions. Part of the problem in online discussions (and many articles) about migrations can be that people are attempting to apply lessons learned from one or a couple migrations they have worked on to another migration that is radically different. 

The fact that migrations are so different is important when we talk about how easy they are.

Yes, some migrations really are easy

Yes some migrations are truly easy:

• Very small migrations
• Where the content is already very high quality, standardized, already has the metadata it needs (or there is a mapping in the right direction) and doesn’t not need to change editorially
• Where the content is already high quality and NOT standardized but it doesn’t need to be standardized in the new system either (see more on target/source consistency)
• Where the resulting quality does not matter (although usually this should be avoided, sometimes having an archive of some content can be at a lower quality)
• Where a large amount of content is being deleted (resulting in it being a very small migration)

I would suggest that many times when a tool makes a migration easy end-to-end for an organization it is for the second case above.

But most are not — let’s define migration to include all the migration bits an organization needs to worry about

I look quite broadly at a website migration as the end to end handling of content, sites/sections, functionality, team, templates, information architecture, and relationships from one platform to another. That said, even if we narrow in to all the activities needed for getting the CONTENT from point A to point B we have these potential content handling steps:

CONSIDER each step when planning but SKIP steps where possible.

So we are NOT talking about the migration being just the relatively simple movement of the bits from one system to another, but the sorting, placing, editing, enhancing, and QAing. The way I define Editing is by definition not possible for a computer to do (although perhaps as AI advances some of this may be possible), but sometimes aspects of the other steps can be automated (if the content is already high quality, etc, as in the checklist above). Notably, the organization still needs to deal with these steps (as a reminder, the goal is never to go out of your way to do all these steps, but from a planning perspective to carefully consider if buckets of content require that treatment in order to not be surprised late in the game).

Put another way, I think it is misleading to say a content migration is easy when only a small part (perhaps the move/transform step) was easy.

But it’s not about EASY anyway — it’s about what’s IMPORTANT

As I’ve written before, when we plan a migration we are tweaking three control knobs: distance, quality, and weight. But in the end we are not doing the migration for fun, but for some business need. In other words, we need to do what’s IMPORTANT and not what is EASY. Of course if what is important can also be done either easily or in a difficult manner then we should do it the easy way (and this is a big goal of migration planning: optimizing our effort). That said, the first question isn’t what’s easy: the primary issue is what is important. This can result in tradeoffs such as dropping a lot of content in order to carefully clean up the content that is most important. Or it can result in deciding to improve the way the templates work in order to make the migration itself easier while also increasing quality.