By Christian Buckley, Axceler
The reality is that a single migration may include all three concepts. A typical migration might include a move to the latest, greatest platform while expanding your SharePoint footprint, including expansion of your intranet, build out of your extranet, the addition of new hardware, plans to use more social media tools, creation of dashboards, expansion of your search capabilities, or transforming what you did with 2003/2007 to meet your organizational vision.
With the release of SharePoint 2010, many organizations are seriously considering the move from SPS2003 or MOSS 2007 to the latest platform. But migrating your production SharePoint environment can be a daunting task. The fact is, migration can be a roadblock rather than the express lane to moving forward with your SharePoint strategy. The high degree of customization many organizations have performed, coupled with their desire to reorganize and transform content means they cannot just move things as-is to the new platform.
Unfortunately, there is no simple "drag-anddrop" migration. It is a phased, iterative, and error prone processi that needs to be properly planned.
Between the Microsoft-provided overview of how to plan for an upgrade/migration and an understanding of the content and end user requirements, administrators recognize that there's a lot of room for error. This is not a small task — not something to be tackled over a weekend. Migrations are much like an iceberg: what you see on the surface is the technical move: data bits, content, using in-place or database attach (or some hybrid method). Underneath the surface, however, is the majority of the migration effort — the planning activities that determine what is to be moved, transformed, scheduled, and eventually administered. Ignoring what is below the surface of the iceberg is dangerous, and can ultimately capsize your project.