The keys to successful SharePoint 2013 migration


 Fabrice Di Giulio, Technical Solutions Professional, AvePoint

Migrating to Microsoft SharePoint 2013 introduces a number of capabilities which could provide a new perspective on you current Intranet as well as the integration of social and collaborative functionality. New features provide organizations with enhanced collaboration management, native integration of enterprise social networks, and a significant improvement of search-related functions. However, successful migrations – either on-premises or SharePoint Online – require an in-depth study of the current environment to identify critical points.

There are many collaborative, enterprise document management, and Intranet solutions – all of which possess their own specific functions. The first question that you need to ask is this: Is a migration to SharePoint 2013 the right move for your organization, given potential risks based on business needs or heavy customizations?

A migration is considered a project and can easily be viewed as a maintenance operation. You should undertake a comprehensive audit of your current environment to identify the pitfalls that could drag out the project planning. In this article, I present the most important questions for pre-migration and solutions to these issues.

What is the state of your current collaboration platform deployment?

It is necessary to have a good overview of documents, taking into account network and hardware infrastructure, user mapping, security directory and implementation, and interactions with other systems. Uniting IT roles can also provide a complete overview and help identify the individuals involved at different migration project stages. Focal points of an overview should include:

  • Infrastructure: Given the infrastructure required by SharePoint 2013, project size, and geographical scope, decisions can be made to preserve the existing infrastructure or turn to a new platform.
  • Active Users: Gaining an accurate account of active users can be an important decision-making tool. I have seen environments where several thousand users were declared, but were either inactive or hardly active. The amount of active users has an impact on important aspects such as data availability, validation process, and security.

How much content needs to be migrated?

Take into account existing content residing in your current environment, including documents, images, pages, the number of versions for each object, and content hosted on external file shares. Clearly understanding the totality of content will help you size up your destination environment and define an appropriate migration strategy answering the following questions:

  • Should all the information be migrated?
  • Do we need to purge any content before migrating?
  • Should an archive strategy be implemented?
  • Should an offloading content strategy be implemented?

What is the level of customization in your current environment?

This question is most applicable for migrations from previous SharePoint versions to SharePoint 2013 or SharePoint Online. Aside from this, it becomes more complex to consider a customized migration.

You must distinguish multiple types of customization, including graphic customizations and those related to a third-party tool, such as workflow software. If it’s possible to support SharePoint 2013, consider a migration tool or technical support. Also, you need to ascertain the impact of customization on SharePoint 2013. Do you need to redevelop a component, or does simply using a native SharePoint 2013 feature meet this same need? If not, should you redefine the business need or simply discard the customization?

What level of technical requirements are necessary for migration?

In general, technical requirements are not an issue once the auditing of the current environment has been carried out. However, the level of functional requirements will often impact the duration of the pre-migration phase.

A common business requirement is the structuring of data. Based on my experience, it is difficult to reach a consensus internally due to data restructuring. Some environments will need to be organized by site collections, while others will require organization based on sites. However, just moving files or folder across different document libraries is impossible natively. Third-party tools, however, can carry out restructuring jobs after the migration with ease.

Another requirement is the level of fidelity of migrated data. In other words, how important is it that you retain the history of your data upon migration? You should address the content-specific items such as language, file name characters, different metadata managed by a source system, and security settings for a document. Then, you should move on to items as they are applied to entire directories, sites, and libraries.

What is the expected type of migration?

There are several ways to carry out a migration:

  • Full migration from an old system to a new system: In this scenario, the old system will be shut down once the new one is online. This implies that sufficient tests have been completed to validate the project before the full changeover is performed.
  • Successive migration based on user groups: With this method, a full migration is applied to different sections of the source environment. Site collections, sites, or libraries that are being migrated successively can minimize the migration time by isolating scopes.
  • Incremental migration: Here, the first full migration is carried out for resetting and validating the target environment. Meanwhile, the users continue to work on the existing environment. An incremental migration then takes place to synchronize content between the two environments. Once the migration is validated and users are trained, a final incremental migration enables permanent changeover.

How should I migrate?

There are many ways to carry out a SharePoint migration, so keep in mind that there is no single blueprint – every project depends upon size and scope of the migration:

  • Manual migration: In this kind of migration, the target environment is configured manually and then the content is migrated via native SharePoint features. One of the advantages of this process is that it is completely free, and requires only one trained SharePoint administrator. However, this migration method only takes care of the movable content (e.g. documents) – excluding all customizations.
  • Scripted migration: This permits you to use resource or configuration files to carry out batch import, initialize metadata, and run SharePoint configuration operations. This option has very few technical limitations and can support large migrations. However, there is an immense skill level required to develop the scripts and it can also be quite time consuming.
  • Third-Party migration tool: The development of a specific migration tool is time consuming – time that developers could spend on creating business solutions on the service catalog. Developing a migration solution is the equivalent of creating a solution that can only be used once. A third-party solution is more user-friendly and provide an efficient, cost-effective solution for migrating business-critical content from various electronic repositories into the latest release of SharePoint.

In order to successfully complete a migration project, there are many aspects to consider. Consider all potential issues outlined above before beginning your project to ensure success. And remember that not every migration is the same – even if a past project was simple, a migration from a different source can be vastly more complex. Third-party tools will prove invaluable in allowing you to automate all or part of the migration.

Comments (1)

  1. Kirti k says:

    What kind of role is required for carrying out SharePoint migration from On-Premise to Office365 ? What if the company does not give you Office365 global admin permission and you require permission more than a site collection administrator ?

Skip to main content