Content Migration Isn't Like Moving Day

In the real world, many of us have rented a truck, got some friends together, moved our stuff from one apartment to another, and then ordered pizza for everyone after declaring our move complete. Not only relatively painless but it was fun! That said, in the digital world a simplistic model of content migration being like moving day does not serve us well, for two reasons: 

1. Just like moving house, migration is much more than a single day.
   

2. Website migration is just plain different than moving house. 
   

The moving day metaphor is incorrect for the above reasons which I'll explore more below, but it is dangerous for several reasons:

• As an industry we are still way, way too focused on dealing with websites as a series of PROJECTS (rather than a product), encouraging the redesign-forget-redesign cycle. The concept of one day just pushing a button to migrate keeps us in this project and one-off stance.
  

• It is much more biased toward not thinking deeply about your content (or the knee-jerk counter-response of saying to just delete all the content and start from scratch).
  

• It increases the chance of train wrecks late in the project.
  

Before continuing, I want to emphasize that I am not talking about doing unnecessary or extra work, just that we should plan so that we understand what we’re getting into to reduce surprises (and perhaps even increase impact!). Also, I think the migration planning is actually quite interesting (and dare I say fun?), but not if you’re just ramming content from one system to another. 

The migration does not happen in one day

We all want to reduce the complexity of migration as much as possible, but, aside from the simplest of situations, a migration does not happen in one day.

Much of migration is in the planning and preparation, which happens before the actual moving day

Even if we stick with the house moving analogy, a lot happens before moving day. If nothing else, things need to be boxed up, and usually we need to first throw out things. There may even be more needed, like fixing the leg of the couch in the image above before moving it since we are concerned that otherwise the rickety couch will get broken during the move. In other words, much of the real work actually happened BEFORE moving day.

Much of the migration is in the cleanup after moving day

Just because all the boxes and furniture is moved into a house does not mean you're ready to throw a formal dinner party there. The same is the case for websites.

Content migration is just plain different than moving house

We just looked at the ways that migration might still be like moving house, but it's not moving DAY. Now let's look at why it's not really like moving house at all.

Content isn't furniture

Of course there are the issues of whether all your stuff will fit in the new house, or if your house will look too bare, but content is very different from furniture:

• Content is more amorphous. With furniture, it either fits or it doesn't. Maybe you try different orientations in your new house, but mostly you will know what fits before you move if you take some measurements. But content MUST fit into different orientations, if for no other reason but to be usable on different screen sizes. So content perhaps needs to be made less concrete than it currently is (for instance, as a PDF) — so the content may need to change.
  

• Content is more structured. A room may be ten feet by ten feet with some other constraints like where the windows and doors are, but basically you can put in each piece of furniture in whatever orientation fits. But content is different. For instance, you may want to have articles display the title, authors, topics, summary, and the article itself in specific ways, which means that these should be in different fields. So instead of a 10x10 room, it needs to fit into a template that is a patchwork of fields (and that's just for one piece of content — furniture just needs to fit in aggregate usually). That said, frequently the content is not already structured or it may be structured in a way that is not conducive to current goals — so the content itself may need to be restructured.
  

All of the above changes are significantly different than anything that furniture goes through in a move.

Content isn't boxes

In a house move, it is often ok for some things to stay in boxes. For instance, winter clothes if you move in the summer. Or perhaps you have some camping equipment that you know you won't use until later. But content can't just stay in aggregated boxes of content, except in some rare cases where you need to store archive information. So in most cases you can't leave stacks of content in containers:

• Content can flow. Furniture is only in one place at one time. Content can be in multiple places. To make content appear in useful ways it needs to be structured and also have metadata that allows the flow. That said, before a migration this metadata is often not present — so the content itself may need to be tagged.
  

• Content needs to be findable, and not just by you. In your new house, you could just unload all your books and dump them on shelves. They don't necessarily need to be especially findable, partially since you know what you have so know when to persist in your search later (which site visitors for example do not have the luxury of knowing). But there's little sense in having content on a website, intranet, or extranet if it's not findable. So it may need to be arranged, and in a different way than it is now. Yet again, we may need to manipulate the content itself rather than just dump it someplace, to make it actually become usable.
  

So similar to content not being furniture and therefore needing to be changed, the fact that content usually can't stay grouped the way it comes over (like staying in a box) also means that it needs to change.

There should be a dance between development and migration

Perhaps in some high end, custom designed and custom built houses there are some isolated cases of where a room is designed around a particular piece of furniture, but in general the placement of walls and other features is independent of individual pieces of furniture placed in it. But in many ways a website is the content. So the order of things needs to be flipped: the website needs to be built to best showcase and accommodate the content. This means:

• The needs of content should be considered when designing the website structure. Perhaps in all fields this is true, but I find that some of the most powerful questions can be the most simple. One that I frequently ask when looking at wireframes for example is "how is that going to happen?" (like when the wireframe assumes a radically different content structure than currently exists). It's not that big change can't happen, it's just that teams need to understand the impact of what is being proposed. Furthermore, it may be that a template should be designed differently to maximize the value of existing client while also accommodating richer content in the future. Or perhaps the content sharing mechanism could be improved to take into account the fact that the content is not already tagged ideally. But the point is that, unlike in a house, where the furniture and boxes just need to fit in the rooms, with a website ideally the content needs are being considered in designing the website structure in the first place
  

• Migration should start as early as possible. Whereas in general there's no need for the big moving day to happen all at once after the building is complete, that's not the case with migration. Ideally key templates are developed (or at least roughed in) early so that you can start at least trial migrations to see how the template and existing content interact.
  

• Migration should be iterative. Ideally the migration does not happen all at once, but you have the opportunity to iterate and improve the migration processes and surrounding templates and functionality.