One of the underlying themes of content migration is that it's boring, or just a necessary evil. Worse, many just look at it as something that doesn't really need to be worried about, since at worst you could just hire a bunch of interns to cut and paste.
Perhaps you won't find content migration fun, but by looking at it through the lens might make it interesting enough for you to increase your chances of website implementation success. Here are some of the reasons you might think content migration is boring, and another way to look at it to make it more interesting:
Cutting and pasting 1) Searching for patterns and 2)Improving your content
Sure, if you are the one that's stuck with cutting and pasting into a new CMS then you've got a boring task ahead of you. But hopefully the migration can be flipped a bit so that it's not structured as a cutting and pasting exercise.
First, consider looking at your content for patterns in the content. For instance, perhaps all press releases entered between 2002 and 2006 were entered in a consistent manner and can also be dealt with (hopefully automatically) similarly. At any rate, by looking for patterns you can consider the migration at large rather than immediately devolving into looking at one piece of content after another. See more reasons for using rules.
Second, consider your broader content strategy, or, perhaps more likely, use your content migration has an opportunity to define your content strategy. Your overall content strategy can help you determine to do with your content, including what content is most important and requires careful editing rather than blind cutting and pasting.
By looking for patterns and considering your overall content strategy you can: a) look for automation opportunities and b) turn the exercise into one of Editing rather than simply copying and pasting (see a comparison between editing and QAing).
One-time exercise Setting up long term program
Migration is necessarily an event. You will probably iterate on the migration LINK, but there is a definitive beginning and end. That contributes to the boredom factor, but, similar to using the migration as an opportunity for content strategy, you can also use this as an opportunity to set up a longer-term program. You will need to set up a team, training, processes, product management, and other factors in your migration. By trying to look at as setting up your overall program than just what is needed for a single migration, the task takes on a more interesting color.
Unending Develop tracking metrics
Especially for large migrations, the entire undertaking can seem almost unending. By looking at it monolithically, this encourages the "well, we better just get started" approach. But I would encourage you to look at developing useful tracking metrics that will help make it feel a bit less insurmountable. Also, looking for patterns is related since you may track against those patterns, and patterns can also help you determine what level of quality is needed for different content.
Unimportant Critical to success
Most of the macho talk around a web site might be about things that lots of people have opinions on like design or technical buzzwords. Many of us can hold our own in these discussions, and much of the time these are important and interesting discussions. But the migration task is often viewed as something that can be dealt with later, or, as mentioned above, dealt with by interns at the last moment. Why migration planning is important? Here are three quick issues:
Migration can take much longer than expected, which means that from the project perspective there's a sudden slip at the end. Careful planning including a pilot can help reduce this risk.
Related to the above point, if you don't plan your migration carefully, you may realize systemic problems with your implementation. For instance, you may discover functionality problems with your site, and by dealing with them as a surprise at the end is more problematic.
Not planning effectively can mean problems persisting in your site that are difficult to correct later.
I'd like to make sure that as an industry we're planning and executing migrations better (one of the reasons for writing the Web Site Migration Handbook). Did this post help convince you that migrations are a bit more interesting? I'd love your comments, either on this blog or on Twitter at @jdavidhobbs.
Content migration isn't just a technical undertaking. For example, you will have staffing impacts. In particular, people will need to touch at least some of the content being migrated. Regardless of the quality of any content migration automation, someone will need to QA the most critical pages of your site to ensure unintended issues arose during the migration. Furthermore, you may want to editorially change some of your content to hone the messaging of your site if you are also restructuring the site.
Broadly speaking, these are the steps that involve someone to touch content during a migration: Sort -> Place -> Edit -> QA. Sorting content is the task at the beginning of content migration planning where the disposition of the content is determined, which hopefully is done by defining rules/patterns rather than looking individually at content. So at this point team members need to decide what gets dropped, archived, moved over without change, or edited (see the website migration handbook for ideas on making that determination). Hopefully in the same pass as sorting, you can determine where content will be placed on the new site. Again, ideally this is done with rules rather than a one-off basis.
Actual changes to the content occur at the Edit and QA stages. Since different resources need to do each, the distinction is important.
Editing is where you are substantively changing the content. In other words, regardless of any technical issues, how does the content need to change? Is the focus of the site changing, requiring a different angle or style? Editing requires either someone with a writing / editorial background or a subject matter expert. For instance, if your site is about photography, then you will need a photography subject matter expert to write the introduction to an entirely new section on the latest technology. Note also that editing could occur either in the existing system or the system you are moving to.
If editing is what the subject matter expert or writer needs to do, actually QAing the content is what someone with more traditional webmaster skills does. The purpose of the QA process is to ensure that the technical migration was successful. In other words, this is more of an HTML/CSS flavor of issues that require web knowledge to both catch and fix. QAing can only occur on the new system. The types of issues here are:
Special characters appearing unexpectedly
Aspects of the new template "blown out" (where content, images, or tables extend beyond the area they are meant to be within)
Strange wrapping of text (for instance in titles)
Graphical elements from the old site that do not appear correctly in the new site
Elements that have disappeared (it's useful to look at both side-by-side)
Elements that were prominent in the old content that have lost their prominence (for instance headers)
Moving content into a new CMS comes with many caveats (for example, is it even a good idea, and migrating to a CMS is far more than just moving content). However you slice it, moving to a new system is an important time to think about your content. Specifically, what content should move? Kristina Halvorson's Content Strategy for the Web lists two reasons to have content: a) it supports a key business objective and/or b) supports a user (or customer) in completing a task. So the Compelling Vision is important here (as always!). It's not just about what can be moved in, but filtering out the gold nuggets from the muck (see The Web Diet for more overall ideas on shedding bulk from your site).
OK, so how do you decide what to move? The most straightfoward method is to have a spreadsheet of content, basically an audit of your current content, and then line-by-line decide what moves over. This can work for smaller pools of content, but what if you have 10,000, 100,000, or more pieces of content? Even with a hundreds of pieces of content this can start being a bit unwieldy.
Having rules (like different types of sieves to leave behind the useful tidbits) for content migration are more helpful than one-off decisions for the following reasons:
Apply in the system on ongoing basis
Why go through the effort of your migration only to have the content go stale immediately? If you decide that press releases older then four years old should be dropped during the migration, then do you really want seven year old releases kicking around your system two years after launch. Similarly, if you decide that pages that are regulation-driven and over one year old should be reviewed, then don't you want that in your new system? Of course, there's a whole other area of governance around actually being able to enforce these rules on an ongoing basis, but perhaps during migration planning is a good time to discuss this.
Better justify drops
In a simple (no beauracracy) environment, justification is not really relevant. For instance, if I want to remove a page from this blog, I don't have to argue with anyone about it. But if you are operating in a large organization, you could wind up in endless discussions going nowhere by reviewing content items on a case-by-case basis (or, perhaps worse, just decide to throw everything into the new CMS again). That said, if you are dropping a piece of content because of a rule (any content of any type that has not been viewed more than ten times in the last year will be archived), it's much harder to argue with (of course, you would probably also need to come up with some sort of very tight exception policy).
More easily to agree first and then everyone do work separately
Related to the above comment, if you agree on the rules first, then you apply those rules and everyone can get cracking on whatever they have to do on the content. For example, if a rule states that a page needs to be updated because it mentions a particular highly negative incident, then the someone can start updating it rather than spending time talking about whether it needs to be updated. Related to this, having some rules in place would better fit into a web operations management framework so that existing teams could make high-impact decisions rather than the impossible task of getting mired in infinite details.
More easily identify disposition
Let's say you have a spreadsheet of 50,000 pieces of content. How do you start? You could just start at the top and work your way down, but how efficient will that be? If you have a rule like any content not updated in the last 8 years gets put into an archive site regardless of any other factors, then you can (assuming you have reliable dates) apply that rule and start working through the content in chunks like that. Note that the process of defining the rules probably means that you need to deep dive into your audit, but the point is that with rules in mind you will quickly see patterns that you can apply to quickly identify the disposition for different content.
Better move content
By looking for patterns, some commonalities may be relevant to deciding how to move content. For example, you may notice that content over a certain age used an old HTML template you forgot about, but that could be scraped easily. Or you may realize that your old working papers can just be moved in as-is rather than needing any manipulation.
Explain to end users if appropriate
If you have these rules in place, then it may in some cases be relevant to your end users. For example, if certain types of content go into an archive after a certain period, you can indicate this to your users. This also gives you a means for public feedback on your decisions.
Reapply rules once you realize you don't have the resources
While going through this process, hopefully you can also take some wild guesses at the effort it will take to deal with different types of content. If working in your content audit spreadsheet, you could always have a running table of the total editing effort. If the effort is high, then you can re-evaluate assumptions, change quality levels, and many other options. One option is to migrate in less. If you have applied rules, then you can tweak the rules and then see the impact on the projected effort. If you went in and did your analysis in a piecemeal manner, then you would now need to go through and have all those negotiations again about what's moving and not.
Hopefully this has convinced you to at least consider defining meaningful rules for defining your content migration. Please share your thoughts or experiences in the comments below.
Submitted by David Hobbs on 15 March 2010 - 5:37pm
Good scenarios are difficult to develop (see Shock and Awe or Tightly Focused Requirements and Where's the juice in your requirements?). For a CMS selection they are essential since they will be the backbone for your comparisons between systems. By starting with your target vision and then stepping back to CMS priorities, the list of use cases you will develop, and then finally develop use cases, you will have a better chance of selecting a good CMS for you than starting with the details.
Why Use Cases are Easier for CMS Selections...
Requirements for CMS selections are easier than, for example, full system requirements since no system will be developed based on them. Specifically:
Only those use cases necessary to differentiate between CMSes is needed.
For each use case, only the level of detail necessary to differentiate between CMSes is needed.
Also, you have an opportunity during the selection process to better understand what your needs are (based on concrete demonstrations based on the scenarios, etc.)
Aside from general clarity to help guarantee high quality responses, you also do not want to overwhelm potential bidders (or make them think you don't know what you want or don't know what you are doing).
... And Why They're Harder
But the scenarios for CMS selections more difficult since:
They require discretion / prioritization (to decide what not to include).
A lot of long-standing issues (often/usually having nothing to do with the technology) will come to the fore. The temptation will be to gloss over these issues but the start of a CMS selection process is a good time to confront them.
Ideally you want broad buy-in to the requirements, but at the CMS selection phase things are probably a bit more abstract than stakeholders can easily comprehend.
There may be a rush to purchase a CMS, so one team is tempted to develop the requirements based on their perspective (perhaps only marketing, or only technical).
They are often developed without an overall vision for the new site.
How to Develop Use Cases
Given these issues, how should you proceed productively? The answer: starting at the top (the vision) and then drilling down until you have use cases targeted to the selection process:
From the vision, define the CMS priorities
List just the titles of the scenarios that support the priorities
Write the use cases
Before diving into these steps, one key element is to get buy-in from stakeholders at each steps. By progressively getting more detailed you have the opportunity to get feedback as you proceed -- this way, you do not wind up spending a lot of effort on details before you really know what you're trying to accomplish.
Before getting into details, why are you even doing the migration? Even if it's mostly for back-end reasons (for example, you're current infrastructure can't scale to your imminent load), defining a compelling vision that everyone understands can ensure success of your migration. For large sites in particular, you may want to write an implementation strategy to ensure the vision is possible (along with pros/cons) so that you're not over-hyping the possibilities (for instance, it may be necessary to phase in your vision).
Define CMS Priorities
This particular article is dealing very specifically with the technology, but there's a good chance that success of your implementation will have more to do with non-technical issues than technical ones. That said, the point here is to develop good scenarios for a CMS selection, so the next step toward that goal is to define the CMS priorities (ideally these priorities can also be rank ordered) that support your vision.
List of Scenarios
Next, write out the list of scenarios that support the CMS. By defining your vision and priorities (and, for large sites, developed your implementation strategy), you will now be able to narrow down on what scenarios support those priorities.
Write the use cases
Finally, write out the use cases based on the list that supports the scenarios. Given your priorities, you will have a better idea of what details are important to include within the use cases.
In summary, start with the vision
By getting progressively more detailed, but starting with the question of why you are even attempting to migrate to a new CMS (which will be difficult regardless), you will hopefully get to focused requirements based on your actual needs.
Some related resources on other blogs (from 2006 to the present):
Submitted by David Hobbs on 26 February 2010 - 10:33am
The road to metadata quality hell is paved with good intentions. Spellbound by the possibilities a complex taxonomy (or just seeming like an interesting mental exercise in its own right), the team gets to work on a detailed taxonomy that could cover all the future needs of sophisticated searching / browsing. You have a problem when the complexity of your taxonomy outpaces functionality the site visitor sees. So if you have a five level deep taxonomy but your site visitors only ever see the first level, then chances are that only the top level is accurately tagged. Since the content contributors won't see any difference / gain, then why would they spend the extra time required?
Match automated functionality to taxonomy complexity
The metadata sweet spot is where the taxonomy complexity matches the automated functionality on your site. So for example the hobbsontech.com site is all tagged to the five stages of CMS migration, and this tagging is used throughout the site (on the home page, as tags with every blog post, etc). So the complexity matches the functionality, and I am compelled to tag correctly. In addition to the functionality, the match must also be in the pain level of bad tagging. So for example I originally structured this site differently so old posts do not have very useful metatadata. Since the pain level is relatively low, I haven't yet cleaned that old metadata (note also that this is a problem with free metadata tags without a large number of contributors). So if you bury some metadata-driven functionality that none of the content contributors care about, then the quality will also be low.
So what to do about this? Carefully consider any additional metadata complexity before adding it to your system. If at all possible, consider a way of increasing the visibility of the metadata through automated functionality on your site. The most direct way would be prominent functionality that the site visitor would see/use (and both the site visitor and content owners / site editors care about). Relying on administrative functionality (for example, ranking groups based on how much content is tagged to their detailed topic without showing this to site visitors) only would be more dangerous since it might encourage people to game the system.