Migrating from MOSS 2007 to SharePoint 2013

Technology needs upgrade and SharePoint is no exception infact newer versions of SharePoint are usually released in 3 year cycles. It is essential for businesses to upgrade to newer versions if they want to continuously leverage the new technological advancements in the IT industry.

When it comes to migrating SharePoint farms between different versions it has always been both interesting and challenging. The level of complexity in a SharePoint migration is proportional to the level of customiszations applied to the environment. All most all the SharePoint environments that I have worked on are customized to different levels of complexity, some are heavily customized with many complex custom workflows (SharePoint/.Net workflows, K2 and Nintex) and integrated with external systems via custom connectors or Business Connectivity Services (BCS), etc… These type of complex environments are often challenging to migrate and require proper planning and a phased approach.

In this article I will briefly talk about the some key aspects that are worth considering when migrating from MOSS 2007 to SharePoint 2013. I like to cover the migration from MOSS 2007 to SharePoint 2013 because this will include migration from SharePoint 2010 to SharePoint 2013 as well.

  1. Migrating Content has to be a 2 step process, if no 3rd party tools are used. I.e. Upgrade MOSS to a temporary 2010 environment via database attach and then move the content to SP2013 using the same approach. 3rd party tools such as AvePoint can also be utilized. Eventhough most of the content can be migrated ‘as is’, it’s important to use this opportunity to clean up the content before moving to SP2013.
  2. Migrating code, this has to be done manually and it’s a key component in the process of migration. The existing code needs to be analyzed and evaluated in detail before deciding on whether to build the solution from scratch or to do a code migration. You must look at code-based customizations, whether custom-built, in-house code, or third party tools, add-ins, or web parts, and determine what will and won’t work in the target version of SharePoint.
  3. The odds are pretty good that some of your customizations won’t work, and you will have to decide whether the functionality those customizations provide is still necessary, or whether the customization can be left behind. If the customization is necessary, but incompatible, you will have to determine the cost and effort required to remediate the customization so that it works with your target version. Most likely the core source code might be reusable so that you can avoid reinventing the wheel and thus reduce cost and effort.
  4. The effort that I have just mentioned is the same whether you are going to 2010 or 2013. And, in fact, it’s extremely likely that the remediation you undertake will result in the customization being ready for either version.
  5. It’s not the target version of SharePoint that is the issue rather it is the mess you have in your 2007 environment that is the real problem. Once you solve that, you are ready to migrate to either 2010 or 2013.
  6.  Permission and Authentication model, since SP2013 uses claims authentication by default and classic authentication is soon to be deprecated, special attention needs to be given to the new security model when architecting the whole solution. In my view point it’s better to do the permission migration separate to content and code migration, probably after the code and content migration which will help you to isolate and identify any specific permission related issues that may occur.

Some of the other general things that you might have to consider in successful migration and adaption of the new SP2013 are

  1. End user training and adoption
  2. Administrator training and familiarity of the system
  3. IT gets familiar with 2013 before making the decision.

If you move users from 2007 to 2010, that’s going to require training—a significant amount of training, in fact. SharePoint 2010 has rough edges in discoverability, and gaps in usability, that were solved in SharePoint 2013. That means that your users will require more training going from 2007 to 2010, than from 2007 to 2013. You’re also going to have to train users twice. You’ll have to train them to use 2010, and then when you do finally move to SharePoint 2013, you will have to train them again because the user interface and user experience is quite different in each version of SharePoint.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s