To read the introduction to this blog series, click... Content Migration for Enterprise Portals: Almost as much fun as moving

"How much stuff do we have? How should we estimate that?"

"Should we just get a U-Haul and move ourselves, or do we need a professional carrier?"

"How long will it be between boxing up our belongings and being able to unpack them? What do we need access to during that period?"

These are just a few of the many questions that must be answered as you decide how to execute a move. Each has a parallel encountered during the initial stages of content migration planning.

"How much content do we need to move to the new site? How should we determine what needs to go and what can be archived or left where it is?"

"Can we move our content manually, or do we need an automated migration tool?"

"What if the content changes during migration? How will the business get their work done during that period?"

More often than not, significant discovery and analysis is necessary to answer these questions with sufficient detail and confidence to develop a reliable content migration plan. That said, establishing guiding principles early on will go a long way toward facilitating the planning process and preempting unwanted surprises. As with nearly all end-user facing initiatives, the business needs to fuel the decision making process, with SMEs who understand technical alternatives and limitations guiding the way. I recommend that high-level planning for content migration center on the following objectives:

  1. Define an approach for creating a content inventory: Leverage capabilities of the source repository wherever possible. If the source repository is a reasonably robust content management system, exporting a list of content items with their metadata should be pretty easy. On the other hand, if the source repository is a set of file folders, a combination of automated scripts and manual effort will likely be needed to create a content inventory. As discussed in my next post, content inventory is a critical step in migration planning, so figuring out how that can be accomplished must be a priority objective.
  2. Define the business requirements for accessing and modifying the content in question during the duration of the portal implementation: A simple rule: the degree to which the content to be moved is volatile (i.e., frequently modified or replaced) will drive the complexity of content migration execution. Understanding the viability of a "content freeze" approach, as opposed to an "always available" approach, is essential to crafting a migration plan that will keep business users happy.
  3. Examine the implementation plan for the target system: Understanding when the target system will be ready to receive/house content is a lynch pin in forming the content migration plan. Consider the moving analogy: the truck can't show up at your new house until you own it and the previous owner has moved out. Similarly, the target repository must be evolved enough to house your content before you can start migrating to it. While the history of IT shows us that those dates might not be set in stone, you've got to start somewhere, and clarifying the point in the implementation plan at which the new system will be ready to receive content – and keep it for the long haul – is an important step during High-Level planning.
  4. Define the resources – financial and personnel –available to support content migration: Depending on the capabilities of the source and target systems, a handful of interns may be all that's required to execute content migration. Alternatively, long term needs, available budget, and technical expertise may warrant the consideration of buying, building, or configuring an automated tool. Guiding principles that shed light on the people, tools, and funding that will be at the ready can prevent hours of wasted time developing an approach that will never see the light of day.
  5. Define the strategy for metadata and content structure: If content in the source system is already tagged with all the metadata you'll need and organized exactly how you want it in the target system: fantastic. More likely, you'll either be starting from scratch and applying new custom metadata to complement a new content architecture, using some but not all metadata housed in the source system and merely evolving your content structure, or some combination of the two. During High-Level Planning, it's not necessary to know every single metadata field and value that will be used to categorize your content in the target system; arriving at a collective general understanding of the current state of your content's metadata and structure and how it compares to the desired state should be the goals.

A few closing thoughts:

  • Don't be disappointed if your team comes out of High-Level Planning with more questions than answers. As with the rest of the portal, that's to be expected, and there's a ton of value in raising those questions early in the project so that you have time to figure out who can answer them and how they'll do that.
  • There is a very real chance that guiding principles identified during High-Level Planning will evolve as the issues are better understood by all stakeholders. That does not diminish the value of defining those guiding principles up front, as they will expedite the decision making process and surface the biggest potential trouble spots.
  • To reiterate, one more time… content owners and users must have a significant voice in the High-Level Planning process. The smartest technical solution for migration may come up well short if it fails to account for a revenue-driving reality.

Next up: building the Content Inventory.