Key Points
- Implement key elements required for your compelling vision first. Not what's easy.
- First concentrate on getting the "bones" right rather than what it looks like.
A strong vision will mean significant improvements. Usually this means some core, difficult things need to be implemented. Instead of starting off by implementing what's easy you are probably better off implementing the things that are essential to your vision.
An example: proving integration rather than publishing simple pages
As an example, perhaps a portion of your vision involves a more consistent experience for your site visitor. The may mean that you need to integrate systems that have never been integrated. Publishing simple pages with no integration would be easy. But starting with what's essential might involve initial integration.
This may require different teams. Or having more difficult conversations earlier. Or not having as easy things to demonstrate for a large audience (it's easier to show people content rendered to a page rather than some seemingly-obscure integration). But if your goal is a more coherent experience for site visitors, and a keep component of that is integrating with backend systems, then testing and working on that early is important.
Why start by implementing things important for the vision?
Fundamentally you want to make the vision happen. Deferring any moves toward that increase your risk. Specific reasons to implement toward the vision:
You confirm whether the vision is implementable.
You increase the quality of the implementation toward the vision.
You refine the vision based on the realities of implementation (for instance, tweaking expectations around the overall user experience).
If any technical assumptions prove invalid, you can course correct earlier (for instance, using a different toolset).
When is it important to move toward the vision?
During initial implementation partner or CMS vendor pitches. You want to see how natural it is for the potential partner to pull off what's most important.
During proof of concept.
During pilot.
In the first phase of the implementation (rather than deferring to future phases)
How do you pick what elements to implement first?
Just because you have a strong vision doesn't mean that it's obvious what elements you should implement first. In general you want to implement the elements that most get at the crux of your vision. For instance, if you want items from your locations database to appear automatically on your related pages, then your first reaction might be that you need to see a page that shows this. But it would be easy to implement pages that look like they are doing the backend integration. It's far more useful to prove that it's going to be easy to have the systems talk with each other, get the information in a useful format, and stay in sync.
Why you might be tempted to start with what's easy
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.
Not convinced? Here are problems with moving toward 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.