Have you had a large site migration discussion where someone said something like this?
We'll just start with the easy stuff first
I would argue that, perhaps after a very initial laugh test of an easy use case, in general you should jump straight to testing/piloting/migrating the compelling vision (see description) of your web site (and of course also in your CMS selection as well). Chances are, this means iterating on some tough details rather than plowing through lots of easy work .
Why Easy first?
So what are some of the reasons that project teams give for migrating in easy sites first?
- Need to show results (project's already over budget, late, etc)
- Need to get momentum (if we don't get people bought into this soon, this project's never going to happen)
- Learn from easy cases (let's take baby steps)
Also, another reason is probably that everyone is just a bit overwhelmed by the volume of a large site migration, although integration, functionality, automatic pulls, multi-site management, or multilingual issues may actually be bigger issues.
Issues with Easy First
Efficiency
Ideally, you only want to touch content once during the migration. If you concentrate on just getting in the simple pages / content / sites, then you may overlook some transformation of the pages necessary for more sophisticated functionality. This might include tagging needs, or structuring pages and content in a way that enables your desired functionality. In general it would be less efficient to come back to the content to correct those issues after already touching each piece of content once.
Buy-In
If you start by implementing easy but low-impact sites or content, then stakeholders may become frustrated that they're hearing trumpeting about progress but no changes that matter to them. If you have got everyone bought into a compelling vision, then to facilitate buy-in you should be trying to show this vision rather than hand-waving.
Wrong Focus, Missing the Vision
If you are concentrating on moving pages, then you'll move in pages. If you are tracking progress with metrics based on number of pages, then the focus will be even stronger. So you may not be looking at functionality, metadata, consistency, etc, that might be key to your vision. Although it may be possible to "undo" mistakes made, it may be politically extremely difficult to go back to retrofit the original vision in the site if everyone's focus has been on getting content into the system.
Metadata Quality
You are probably expecting the CMS to do some automated pulls of content, that will require accurate and complete metadata. If you do not implement the functionality that will expose the tagging (either directly by displaying it on the site or implicitly by pushing it to particular pages), then it will be very easy to not worry about whether the metadata is good when it is being migrated (by hand or automatically). Even more troublesome, you may discover that your metadata model was not sufficient, which would be better to discover earlier rather than later.
Train Wrecks at "End" of Project
By doing the difficult functionality earlier in the process, you're less likely to have the project come to a halt toward the projected end of the project. Running into issues earlier gives you more time to react to them, and also you have invested more effort already. An iterative approach, toward your vision for the site, would be more effective than putting off the more difficult items until later.
Tracking Error
If you're starting with simple stuff first, it's easy to make unrealistic extrapolations. For example, let's say you have 500,000 pages to migrate, and you have migrated 300,000 pages already. You may be tempted to extrapolate with something like the graph at the right. Since it took 3 months to get 300,000 done, it will only take 2 more months to get the last 200,000, right? As discussed above, you may actually be obscuring major issues, which may grind the process to a halt and actually require going back and touching the content that was already migrated.
How to Phase with the Compelling Vision in Mind
Let's say your web site vision is to be the "Authoritative source of mental illness information available via a variety of channels (web, RSS, API), different types (raw data, analysis), and selectable by topic pulling from a variety of back-end systems."
If you are going from the authoritative source you envision, you might start by: a) designing the metadata carefully, b) define how automatic pulls will work, and c) defining standards around the content so that it can be used effectively by multiple channels. Then you might migrate in content that is re-used a lot (or first just pull from one of the back-end systems that's already in place). You might also start by negotiating with the owners of the various back-end systems to determine when they can all meet the same standards for metadata, content-reuse, etc. For the functionality of the site, it probably would make sense to implement a little bit of support for all the functionality you were after, so you might: ensure your system drives a bit of web, RSS, API etc for a single content type first. In addition, it would make sense to start with strong content types first rather than allowing a generic content type for most content.
The near-term result may be a small amount of content, but the highest-value (as the authoritative source) information available on some key pages and via RSS. This would be in contrast to a rush to implement "easy" / high volume, with lots of pages/content but little value.
