In any migration to a new Microsoft SharePoint platform, the first issue is the nature of the legacy system: Is...
it an earlier SharePoint installation or a non-Microsoft CMS platform?
From this first point, all subsequent choices and steps follow. If the migration is from a foreign CMS, it may be best to let a third-party provider handle the nuts and bolts of the migration and concentrate on the business- and user-related processes involved. Why? Because few, if any, IT personnel are likely to be experts in the technology underlying the legacy system and the new SharePoint farm.
If the migration is SharePoint to SharePoint, the next step is to choose a migration method.
Database Attach is the simplest of the migration methods. The SharePoint content database(s) are detached from the legacy SQL Server instance and attached to the SQL Server instance in the new SharePoint farm.
Pro: This is a clean, safe, fast transfer of content.
Con: All the bad content, and all the flaws in the old system, are copied into the new; the content does not go through the triage process that it should.
Scripted move is the most complex and flexible method. Batch jobs are created to transfer sites and content across from the old system to the new one, a few pieces at a time.
Pro: This method is precise and offers a high degree of control.
Con: The process is time-consuming and hogs a great deal of IT resources to do well.
Manual migration involves the rebuilding of sites in the new system and the copying of vetted content.
Pro: As with scripted moves, it offers a high degree of precision and control.
Con: It is the most labor-intensive, and because most of the work is done by non-IT personnel, the most mistake-prone and inconsistent.
This step, however, isn't necessarily complete with your choice of the best migration method. Sometimes no single migration method is the best choice for all the sites and content being migrated. A hybrid approach may be best, mixing and matching migration methods.
For instance, multiple content databases may be involved -- one of archived content maintained for compliance, another filled with active sites. Database Attach might be appropriate for the archived content, while scripted moves would be best for the active sites.
Can't say it enough: Planning is everything in migrating SharePoint. The team should include existing site owners, high-level stakeholders, a compliance officer, IT and users.
Participants should be included from across the enterprise, including every line of business. Discussions should include how content will now be shared; how metadata will be used to facilitate enterprise-wide convenience in surfacing content; and the selection of measures and metrics that will be most useful in tracking the progress of site and content transfer.
This step's importance tends to be underrated in most migrations. It's safe to say that more time spent here means less time wasted later.
While standard rollback procedures for .NET deployments and SQL Server are already in place, these methods don't cover certain issues with SharePoint. Many SharePoint migrations not only have an old and a new farm existing in parallel for some time, but functionality is transferred between the two a site collection at a time or a line of business at a time. For this reason, rollback can be complex -- and you need to think about it up front.
This step is a lot of legwork for the business participants if the legacy system has been in place for a while. A legacy SharePoint installation will have many old sites that need to be preserved for compliance. In addition, many remain useful, but their owners have moved on, and many will need to exist on the new system, but in another form.
Constructing an inventory and identifying and assigning site owners is key. You must also work through that inventory to make certain that every site that needs to migrate is on the list and somebody's responsible for it.
The next step, pre-migration, is to go through those sites and determine which of the following is appropriate:
Remove. Let the site go, it isn't useful anymore (but exercise caution not to drop a site, or any content, that may be necessary later for compliance purposes).
Migrate. Take the site and its contents across to the new platform.
Rebuild. The site needs to be in the new system, but it will have to be built again from scratch to accommodate new functionality or restructuring of data or to deal with flaws in the old site.
A crucial step in ensuring the eventual success of the migration is to execute the migration in the user acceptance testing environment. This step keeps the business participants and IT personnel in lock-step. It ensures that migration scripts are doing their job, that term stores are accurate, that use of metadata is consistent, and that the metrics being assessed to measure performance/success of the migration are accurate.
This is a hard one to get right, because it's so detail-intensive and requires so many checks and balances. But it may have the greatest impact on eventual success.
A staggered approach is often best when the CMS to be migrated is large: A scripted move of site collections through user acceptance testing and into production in serial fashion is a popular method.
Finally, it's important to plan for a possibly lengthy period of supporting both the old and new platforms.