A compelling vision is a simple statement, in terms that all stakeholders can understand, of how the migration will result in a substantially improved site. This vision must be concrete enough to prioritize tasks / functionality / content during the migration, and also motivating enough to mobilize everyone (and tolerate the inevitable hiccups).
Without a compelling vision, your migration can get caught in a quagmire or indecision or you may end up with a muddled (and potentially overcomplex) implementation.
Please see Compelling Vision for a Large CMS Migration for more.
The content migration process is a bit more subtle than is obvious on the surface. Notably, it isn't just a decision of whether to automate or not, but how much burden the different teams will face. Sure, maybe a fifty page site should be migrated entirely manually, but for anything much larger there will be a blend of automation and manual intervention. Often the technical and non-technical teams don't really understand each other (or the migration process), so the technical team just says it will automate what it can and then hand it to the less technical teams to clean up. The technical team might do what amounts to an automated copy and paste with a twist of trivial cleanup using a tool like HTMLtidy. That's a bit like just kicking a bunch of rocks down the mountain for the people living below to deal with.
Problems with the simple two-step automation approach
Some problems with this technical-team-hands-off-to-other-teams approach:
Unplanned cost for nontechnical teams. By shifting the burden to the nontechnical teams (also typically known as The Client), these teams then have more work than they were probably anticipating. This approach gives no chance for effective estimation (see Why estimate? I'm not getting more resources for this site migration..
Lower quality. If all of this manual burden happens at the end of the process, then quality will probably start being tossed out the window.
Project slips. Obviously another outcome of this approach is project slips.
Dangerous Phrases
Here are some dangerous phrases to listen out for:
"We'll automate what we can". This is a signal that the technical team isn't engaging in a discussion about the migration but will bang out whatever they can quickly to ram the content into the new system.
"We looked at the content and it isn't regular enough to automate". If there are only ten content items that are in question, then move on and migration manually. If you have a large batch of content, you might want to dig in further. I once had a system integrator say that just because the phrase "Description" was used on some pages and "Overview" on others that it couldn't scrape out the content components. Wrong: regular doesn't mean identical and it is trivial to deal with these types of issues once identified.
"We'll turn it into XHTML and then you take it from there". Run. Fast. Turning into XHTML is trivial, and you probably need transformation as well. This is a sign that the technical team is not thinking creatively about migration.
"Since you'll have to edit the content anyway, you might as well clean up the HTML as well". Remember that editing and QA are different.
Anything ending in "and you clean up after that". The process should be iterative, not resulting in the editorial teams cleaning up unnecessarily.
A Better Planned Migration Approach
Instead of just stumbling into the migration process, I would recommend a more planned approach. Some ways of doing this (also see Web Site Migration Handbook):
Iterate on the migration (so it isn't just two steps of "automating what we can" and then leaving it to the the content owners to clean up all sorts of problems)
Keep estimating the cost of the migration, including both technical and non-technical resources, to keep the dialog going about where the burden will fall
Ensure that all of these types of issues are talked about when initially working with your development shop, system integrator, or internal technical team to help determine an approach to migration instead of just hoping for the best later
define what acceptable quality is
-----------------
Need help defining your migration process so it will be a reasonable level of effort for everyone involved? Contact David Hobbs Consulting
We all gasp at the treasures we see when they are already on shore. Sure, sometimes someone gets lucky, but usually the big web site successes we gawk at take a lot of hard work.
A story of two fisherman
Joe "the dreamer"
After watching a documentary about an explorer finding a hundred million dollar undersea bounty, Joe the weekend fisherman decides he wants to find an undersea treasure. The only equipment he has is a fishing rod, reel, and tackle. He starts by trying to snorkel to find a treasure, but after several weekends he finds nothing but seaweed. Then Joe goes out and buys a row boat, oars, and a long rope with a huge hook on it. Rowing out for several weekends in a row, he drops his rope down until it hits the bottom, rows to trawl the bottom, and then hauls the rope up. He finds nothing, and then decides to go back to the shore to fish from the beach like he used to.
Jake "the realist
Jake's friend the weekend fisherman is inspired by the same documentary, and thinks hard about how he can do something bigger. Although he's a motivated guy, he quickly realizes that his day job and other interests are going to get in the way of him getting funding for millions of dollars to find treasure like in the documentary, that might not pay off anyway. He considers getting a metal detector, but wants to be in the water. So he decides to fish for bigger fish, and buys a row boat, oars, and bigger fishing gear. The next weekend he goes out in his rowboat, and catches bigger fish.
The professional treasure hunters
On the same weekend, both Joe and Jake see a ship far from shore drop a little submarine into the water. Later that night, they hear on the evening news about that ship hauling a big treasure from the depths.
Fisherman
Before
After
Cost
Payoff
Joe "the dreamer"
little fish
nothing (didn't even catch any fish when trawling for treasure)
boat + gear + a lot of time
wasted time and no fish
Jake "the realist"
little fish
big fish
boat + gear + same time fishing as before
bigger fish
Commercial venture
big fish
treasure
huge resources
huge payoff
Don't be like Joe
So, are you like Joe? Fancy vision but no realistic way to achieve it? Then blaming your equipment when it doesn't work (and not seeing the big fish right below you)? Or like Jake, being inspired by something but riffing off it to achieve something bigger than you had before? Of course, if you are searching untold treasures, then by all means go for it, but make sure you think through a means of achieving it. Make sure you have the governance, technology, product management, sponsorship, content strategy, UI, IA, taxonomy, culture, money, staff, time, focus, and will to make your goal a reality. To stretch the analogy further, here are the elements needed to make a big project happen:
Hunting for undersea treasures
Web success
Defining your bounty
Defining your audience
Type of boat
Technology
Type of rod and tackle
Marketing and sales
Crew
Web team
Logistics
Project Management
Defining success
Defining success
Planning
Planning
Sponsor
Sponsor
Legal
Legal
Financial Management
Financial Management
Culture
Culture
For a small site, only the issues at the top matter. But for a large undertaking, the items toward the bottom are important for any large goals. Just like you probably will not find big treasure in the murky depths of the ocean without very specialized expertise, a large crew, specialized equipment, lots of planning and ongoing logistics, and managing sponsors, the same is true if trying to accomplish something big on the web.
--------------------------
Don't want to be like Joe? Need help creatively setting goals and the means of achieving them? Contact David Hobbs Consulting.
Understandably, teams often focus on what tools can provide for migration. On the flip side, many teams are too knee-jerk about getting a legion of people to migrate content by hand. The decision of automation or not is probably a bit more subtle than immediately obvious (it's not an either/or, and there are degrees of involvement needed by people), but one that should be considered carefully. That said, let's assume you have a team and the tools to do a lot of automation in your migration. In order to make sure that you have a successful migration, make sure to consider the things that cannot be automated. Here's a quick table listing some items that could be automated and those that cannot:
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:
Define vision
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.
Define Vision
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):
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.
Good scenarios are difficult to develop (see 
