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.
Submitted by David Hobbs on 12 February 2010 - 3:39pm
We naturally all have a bias of how we approach improving our web sites (Information Architects through an IA lens, programmers from a technical perspective, etc), but we should all occassionally be looking broadly at what is required for success of your web site. I would also advocate that someone (the product manager) should always be looking broadly at site success.
As always, I advocate starting with the vision of what you are attempting to do. This could be your vision for an upcoming site revamp/migration, or your long-term vision.
After you define your vision, you can then help to combat you and your team's biases by:
List out the various factors that will lead to meeting your vision.
Evaluating where you are, right now, against those factors.
Roughly determining how strong you need to be in each area.
Concentrate on the deltas, in particular those that have a wide gap.
So instead of diving into one particular area with a tactical view of your problems (for instance, a deep engagment improving the graphic design of a site), you can concentrate on those that will derive the most value. Also, hopefully this will focus discussions so that you are always going to just enough complexity that will meet your needs.
One way of representing this would be in a graph, highlighting a) the "ultimate" / maximum maturity / most complexity / most impressive / most Amazon-like / fantasy, b) current level, and c) the level required for your vision. See the example below, which highlights those areas where you are meeting/exceeding the capabilities toward your vision (in green) and those that require work (in red). In this example, your design level is exceeding what's required toward your goal (which would be good, but on the other hand might be an area where you could spend less). The widest gap in the example is around setting a shared vision, so perhaps should receive the most attention.