Thanks for the useful post, and especially the list of questions that it would be great for a tool to answer. I agree that finding the patterns is the essential aspect, and I like how you are bringing the list view and pattern view together here.

Thanks for the useful analysis, especially around the decision of moving it, leaving it, or consolidating existing content. In particular for enterprise sites, this is a very important distinction to make since the impact of these decisions will be large. Also, if doing a formal pilot / beta, then the decision of whether to move it, leave it, or consolidate become relevant at that stage, even if later on more extensive work will be done (for instance, for a pilot there may a bit more "leaving it" than the full rollout).

A quick thought on large sites. If we consider the "old" and "new" system in a migration, if the old system is *already* pulling from a third system then this data in the third system is probably a good candidate to leave where it is (a picture would probably illustrate this better!). Then the decision becomes whether to match the same level of integration that the old system had with this repository or to do a deeper integration.

For large organizations, the Consolidate approach is probably the most common, since there are usually so many systems being integrated already that only some (which still might be a large amount) would be migrated. One nuance on one point you made about not moving in redundant information: depending on the objectives of the new site, it may be important to manually *rewrite* content from an editorial perspective as well.

Thanks again.

Thank you for your comment, and for pointing out the importance of training which I agree with. I think there's always a tension between making things easy for the site visitor and the site/content owner, so training can help fill that gap. Also, by intelligently implementing a system perhaps the right level of ease/flexibility for the site/content owner vs. consistency and generally good UI for the site visitor can be improved as well. As a huge fan of product managing a web site, I think that's a good way of trying to keep the right balance in the implementation.

Yes! A couple other factors: a) integration points with backend systems, and b) number of subsites that have to be managed by different teams (a twist on your first scaling point).

Thanks Apporv. This is a useful way to look at a migration. I especially like your table breaking down the software development steps and what that means for a migration project. Also, when a migration is also part of a site implementation, the migration aspects can be inserted directly into the site development process as well rather than isolated as its own task. For example, architecture decisions may affect the ease of migration, so migration should be considered as a factor during the various implementation steps.

Good points. I would say though that a lot of time can be spent arguing over details on the display side (how "new" do the claims need to be to show, how many to display, what fields from the feed get displayed, etc). So there's still value in allowing those display-only parameters to be set by business users (even if it's not a No Code solution).

For large organizations, I wouldn't forget about automatic tagging based on semantic analysis of the content, with an experienced librarian tweaking the rules. This can lead to more accurate tagging, regardless of the UI (although I would agree that UI is important).

Also, as to the dream of fully-automated pages, I would argue that:
- Some aspects could never be fully automated, especially for major pages (such as your Elephant Flu example). I would argue that, if you can get some editorial resources to control major topics-driven pages, that this would also be preferable (to selectively override particular content items being pulled for example)
- The logic of the automated pulls also has to be carefully considered, since the details are truly important (I explored some of these issues in a blog post a couple days ago <a href="http://hobbsontech.com/content/automatic-pull-con..." target="_blank">http://hobbsontech.com/content/automatic-pull-con...

Agreed that correct tagging (to a common taxonomy) is becoming more and more important.

I think one approach often overlooked for very large sites is automated concept extraction. In that scenario, there aren't people responsible for actually tagging correctly, but people making sure that the rules of automated concept extraction are high quality. I know this probably only makes sense for really big sites, but if a lot of content is being entered, then is it really scalable for categorization experts to be tagging/editing metadata for all the content?