Executing a migration to SharePoint requires extensive planning and careful analysis. However you do not have to be constrained by a limited migration approach; the possibilities are limitless. In fact, upgrading and migrating is an opportunity to free your SharePoint content.

The most crucial part of your migration or upgrade project is the planning. Planning for technical challenges can become quite perplexing with the sheer number of variables and the out-of-box limitations involved. That is why it is important to take into account all the variables involved in the migration process.

Auditing Content

An understanding of what content currently exists and what should be migrated into SharePoint is vital for the success of your migration. This includes content from a number of sources, such as:

  • File Shares
  • Public Folder Exchanges
  • Legacy SharePoint (Windows SharePoint Services [WSS] 2.0, WSS 3.0, SharePoint Portal Server [SPS] 2003, Microsoft Office SharePoint Server [MOSS] 2007) sites and servers
  • Legacy document management systems
  • Legacy Enterprise Content Management (ECM) systems

Any existing information and taxonomy of the systems in the organization should also be audited. This includes documenting and auditing key areas, such as:

  • Permissions
  • Users
  • Features
  • Customizations (including custom code)
  • Integration with any other systems

The goal is to find where all the critical data resides. Migrating SharePoint content that won’t be used is counterproductive. “Garbage in, garbage out” is a very useful tool in this setting. Determining where a critical document stores in an organization and auditing access to that content will allow your existing security model to be carried forward into the SharePoint farm.

Information Architecture

Information architecture encompasses key areas like features, taxonomy, permissions, customizations and integration with other systems. That is why it is crucial to document how information architecture will be handled during a project. The plan should also include who the key contacts will be for each facet of the migration.  Rather than relying on SharePoint folders for organization, it is more efficient to use SharePoint 2010, SharePoint 2013, or SharePoint online because they have the option of metadata filtering, whereas the older versions of SharePoint’s folder approach has limitations. The older versions do not scale well or categorize the content in multiple ways. Taking advantage of these new features frees your SharePoint content and maximizes the farm’s return on investment.

SharePoint taxonomy is a consideration for organizations migrating or updating to SharePoint 2010 or SharePoint 2013. Previous versions lacked a central store for taxonomy terms.  Planning how to get taxonomy information properly added to documents is only half of the battle. Properly using the information architecture and tagging the data according to the information governance policy is the other half. Long-term information architecture governance can result in content being better organized and searchable. Migrations that just dump data into a poorly planned structure or migrate into existing data structures result in failures and suffer from low adoption rates, because users won’t be able to find the data that they want.

Recognize SharePoint Customizations and Integration

Topics that require the most exertion to complete a SharePoint migration are time and effort, including customizations and integration with other systems. Even if a SharePoint environment is not using a great deal of customizations such as custom templates, add-ons, or even custom web parts, there are still significant considerations. Web parts and customizations can be utilized extensively in the existing platform, either as part of the workflow process or as a display of critical data in a specific way. This is why it is imperative to catalog and understand what customizations are in use.

Content from other ECM systems migrating to SharePoint may need a data transformation, if the elements of the source system do not map to an object within SharePoint or an addition of some sort of customization to the target system.

Integration of SharePoint with other systems is just as important as customizations. If you have an older version of a MOSS farm, the Business Data Catalog (BDC) feature within the server of newer SharePoint versions can supersede the functionality of the Business Connectivity Services (BSC). In previous versions of SharePoint the BDC was a read-only interface. In the newer versions of SharePoint the BCS provides you with a read and write functionality, which allows organizations to read and write information to and from external data sources. This gives an ability to display and manipulate data from external sources within SharePoint. There are other means to integrate SharePoint with external systems; however, these custom solutions require thorough evaluation before a migration begins. To avoid scope creep late in the project it is wise to do this step as early as possible.

Prepare a Test Plan

In order to test the migration it is best practice (from a risk management perspective) to “test early and test often” during any complicated project. Migration options that don’t perform testing in advance are more than likely to suffer from issues that are more serious. Those who do test early are able to identify where the problem lies and quickly work it out. When creating a test plan it is imperative to consider the following variables:

  • Custom code that needs to be ported
  • Custom list templates
  • Custom site templates, like “Fab 40” templates (This may be difficult to migrate)
  • Custom web parts
  • Third-party web parts
  • Feature mapping, including deprecated features like SPS portal listings

Planning for a test typically involves the creation of a designated test environment. The plan should also include a User Acceptance Testing (UAT) phase. This allows users to test the migrated data in the new environment themselves before it becomes production data.

Migrate SharePoint Content

Once the plan begins, information governance plans start, the migration test plan enacts, and the process of migration can begin. Depending on the source and target, native Microsoft migration approaches may not work. Target environments running on versions of SharePoint older than 2007 and many SharePoint cloud offerings don’t include a built in migration approach and rely on third party migration products or manual uploads. Microsoft provides two out-of-the-box migration approaches if an organization is migrating directly from SharePoint 2007 to SharePoint 2010; however this is only possible in specific circumstances as discussed below.

The In-Place Upgrade Approach

A method by which an individual server upgrades in place with all the content. This entails upgrading the version of SharePoint and all site content on the server all at the same time. There are significant limitations to the in-place upgrade approach. It is the riskiest migration strategy, because there is no fallback strategy if there are issues. Key challenges include:

  • Migration content to SharePoint Online and Office 365 is not supported
  • The process can only migrate from WSS 3.0 to SharePoint Foundation or from MOSS 2007 to SharePoint server 2010. It does not support the older version, as there is no way to migrate SharePoint 2003 content directly to SharePoint 2010 or 2013
  • The environment has to be down during the process
  • If the process is interrupted by any sort of problem the environment becomes unstable

Minimum software requirements:

  • Windows Server 2008 x64 or Windows Server 2008 R2 Operating System
  • Database running on either SQL Server 2005 x64 SP3 w/CU3 or SQL Server 2008 x64 SP1 w/CU2. (It can’t be running on a 32-bit SQL Server. SharePoint2010 only supports 64-bit hardware)
  • To run the upgrade the user account must have full local admin rights to all servers in the farm, including the SQL Server databases
  • After the upgrade, if site functionality is undesirable, there is no way to return pre-upgrade state unless a complete restore of the farm is done

 Microsoft Database Attach Upgrade Process

The vast majority of people find the In-Place-Upgrade process problematic. Luckily, Microsoft provides a second less risky approach that allows databases to attach to a freshly built SharePoint 2010 farm, as well as upgrade in a new environment. However, there are limitations that require examination before taking this approach, such as:

  • Migration of content to SharePoint (including Office 365) is not supported
  • Migration of SharePoint 2003 content (WSS 2.0 or SPS 2003) directly to SharePoint 2010 or 2013 is not supported
  • Granularity of migration confines you to individual contents databases, thus allowing you to migrate everything within that database at the same time. All content should be migrated at once given that your environment has all or the majority of content in a single or small number of databases
  • Settings in the new farm must exactly match the settings in the original farm; manual configuration is required. This includes managed paths, web application, email settings, quota templates, and alternate access mapping (AAM). Missing settings holds the potential of a failed upgrade
  • Customizations require manual transfers; including language packs custom elements, features solutions, and web services. If ported incorrectly the upgrade could fail

The data-base attach upgrade can also be used to migrate from SharePoint 2010 to SharePoint 2013. It is important to minimize downtime when migrating to SharePoint 2013. This can be done using two different methods.

  • Read-Only databases: This provides all users the ability to access databases as read-only while the upgrade is in process. If any problems occur the read-only farm may be restored as a read and write farm. Troubleshooting may then take place from there.
  • Parallel database upgrades: This makes it possible for you to attach and upgrade multiple databases at a time making upgrade times much faster. The maximum number of upgrades depends on your hardware, which is why it is imperative to monitor progress and servers. Larger databases are better off with single upgrades due to slower speeds with parallel database upgrades.

To upgrade from SharePoint 2010 to SharePoint 2013:

  • Create and configure a SharePoint 2013 farm, so that you can upgrade databases from SharePoint 2010
  • Copy SharePoint 2010 products to the SharePoint 2013 farm
  • Upgrade service applications (Business Connectivity Services, Managed Metadata, Secure Store, User Profiles, and Search) to SharePoint 2013
  • Learn how to upgrade content databases from SharePoint 2010 products to SharePoint 2013
  • Verify that the upgrade for your databases has succeeded and that you are ready to upgrade sites.
  • Migrate from classic-mode to claims-based authentication in SharePoint 2013 by converting SharePoint 2010 Products or SharePoint 2013 classic-mode web applications to claims-based authentication or create new claims-based web applications in SharePoint 2013

Migrating from SharePoint 2010/2013 to SharePoint Online

Currently there are no Microsoft tools to provide a migration to SharePoint Online. Migrations must be done manually or using third-party tools.

To help prepare for migrations consider the following:

  • Delete versions, old documents, and unused lists
  • Review the structure of the farm. Hypothesize ways to break the sites into separate site collections based on department and operational functions
  • Consider document dispositioning
  • Tailor the sites to the needs of the business
  • If there is more than 25 TB of storage consider running SharePoint in a hybrid scenario

Metalogix Migration Manager is a third-party tool that offers a direct migration to SharePoint Online from SharePoint 2010/2013. The best part about the tool is that it doesn’t even need to be installed on servers! It provides a powerful reporting functionality to compare content between sites and backup files. The management tools with Migration Manager allow for an abundance of commands.

Using a Third Party to Migrate

Organizations that require a migration without the constraints of the out-of-the-box approach will often use a third-party product. Metalogix Migration Manager for SharePoint was specifically developed to allow organizations to directly migrate from legacy SharePoint versions to SharePoint 2010, SharePoint 2013, SharePoint Online, Office 365, or as a consolidation project between multiple SharePoint farms. Migration Manager for SharePoint has many advantages, as it allows for flexibility of migration versions and farms, granular migration, PowerShell support, reorganization of sites, templates, and databases during the process, and many more other enhanced capabilities. Migration Manager does not use undocumented direct writes to the database, therefore using the product does not affect agreements with Microsoft.

Migration Manager allows organizations to improve its information architecture during a migration or upgrade. It allows users to maintain architecture governance plan in the long term after the migration takes place. Features include:

  • Restructuring servers for better information management, performance, search or usability
  • Merging lists or splitting lists
  • Item level restructuring
  • Re-templating
  • Turning sites to site collection or vice versa turning a site collection to a site

Migration Manager possesses the ability to create a test plan, as it allows the migration to take place in phases with the ability to perform full-blown test migrations that don’t affect production performed in advance.

Using Pre and Post-Migration Checklists

Pre-Migration

Before your migration takes place, review the following prerequisites:

  • Learn about the new SharePoint hardware and software requirement and upgrade accordingly
  • Peruse MSDN and Microsoft Knowledge Base upgrade articles to plan your upgrade and make note of any potential pitfalls
  • Use the read-only pre-upgrader checker to find points of failure and run PowerShell custom components to find customizations
  • Install all custom components in the target environment
  • Build out site structures ahead of time to reduce migration time and overhead
  • Import users to reduce migration time overhead
  • Create jobs/logic to split apart large content databases and site collections to move back within Microsoft stated limitations and reconsider site structure/taxonomy
  • Create incremental jobs if users are still active in the source environment and no downtime is possible
  • Create PowerShell jobs and scheduled jobs and run them at a specified time
  • Based on the functionality of the SharePoint API, the checked-out status of documents cannot be saved during a migration using third-party products, so it is essential that all documents be checked-in before they are copied
  • On the target SharePoint server configure the following:
  • Configure SharePoint and accept all file types for migration
  • Configure SharePoint and accept the largest file size for migration
  • Set up third-party web parts and custom content types on the target server before migrating. To make sites look similar set up customized templates, workflows and themes on the target. Create custom site columns on your target server. Migration Manager will automatically migrate columns added to lists on the source, but the column type must exist on the target

 Post-Migration

After your migration, the following tasks should take place:

  • If you are using a third-party migration solution, then copy alerts from the source to the target environment in case they fire off alerts during the actual migration
  • Run any incremental jobs created in pre-migration
  • Send automated e-mail to site owners and site collection administrators after the site migration completes
  • Review content with site owners to ensure a smooth transition

Not all of these variables will apply to every migration, but it is important to review them before, during, and after the migration to ensure process sustainability.

Verifying the Migration

Once the migration takes place, verify the migrated content in the new environment. Compare the source and target environments, especially if troubleshooting whether or not a document successfully made it to the new platform. For the newer version of SharePoint, there are very few native approaches to identify whether or not content has been migrated. Spot checking that data exists but does allow for metadata, version history, and other key information from the source and target copies. Migration Manager allows a comparison to happen, identifying that the source and target environments have been correctly migrated and all metadata versions are preserved.

Conclusion

Migrations may occur within an organization every few years or so. It requires extensive planning, auditing of the content, troubleshooting, comprehensive testing, customizations, external system integration and an ideal information architecture. Take into account all these factors for a successful SharePoint migration. For assistance in your SharePoint migration contact the expert team of consultants at AAJ.