My Role as Data Migration Lead – SharePoint 2013

Introduction

As part of any large ITO deal within a large IT organisation you are sucked into accounts on a particular role to fulfil a particular contractual obligation. I spend the best part of a year on such an account. My role was the Data Migration Lead for one of the largest implementations of a SharePoint 2013 farm in the UK. The SharePoint farm is to be used by 140,000 people across the UK and has over 40 servers! My role was to facilitate the migration of existing solutions to SharePoint 2013 (On-premise).

Problem Scenario

A large public sector organisation within the UK government currently have a number of internal online solutions which provide various facilities such as team collaboration, blogs, wikis, document storage and a managed publishing intranet site. Each solution uses a different tool to provide said service. For example team collaboration uses Documentum eRooms. The managed publishing site uses Oracle Stellent & Publishing Server. The majority (all except the intranet solution) have been implemented as pilots which have turned into production systems without any proper testing or capacity planning. This has been due to the lack of business focus on a particular solution and new tools being introduced over a span of 10 years. To remedy this, a project to combine these existing web based services to a new platform – SharePoint 2013 (On premise) is being undertaken. As part of the new solution there is a great desire for one platform for all ‘web based’ services and to migrate any data from the existing tools.

My Initial Thoughts

I have never been involved in a migration of this scale. I thought I have a solid understanding of SharePoint, I have the capacity to analyse existing solutions and I understood what the end result needs to be. So how difficult could it be? Very it turns out!

To summarise I had to:

• Migrate all existing web services to SharePoint 2013
  • Provide a Collaboration service (Team Sites, My Sites, Blogs & Wikis, Self-service creation etc…) with existing data
  • Provide a Publishing Intranet site with current content
  • Influence the design of the SharePoint 2013 based on current solutions

My Approach

My first task was to develop a migration strategy. This was a plan of attack. How would we migrate each solution in its current form to SharePoint 2013. First things first, I googled ‘data migration strategy’. The results came up with a number of slides and articles with useful pieces of information which got me thinking. From all this information I came up with three very high level steps. The first step is to understand the ‘as is’. The second the ‘to be’. The third to map the two.

1. The ‘as is’ is the current solutions. It was to understand and gather system information, usage stats, any customisations, understanding if the current solution maps to SharePoint OOTB functionality, any bespoke features are required.
2. The ‘to be’ would be a little more difficult in this scenario as it was yet to be decided at this point. But this gave me the opportunity to work with the development teams and SharePoint leads to help shape the solution to match the requirements of the data migration based on the clients’ needs.
3. So matching the ‘as is’ and ‘to be’ would require some magic or a third party tool? Magic wasn’t really my thing so I opted for a third party tool. So I looked at some of the market leaders such as AvePoint & MetaLogix. Both provided very similar functionality for a similar sort of price. They enabled the existing solutions to be migrated to SharePoint 2013.

So with these three key steps identified, I decided to delve a little deeper into what is required. I formalised my approach into three phases:

• Analysis – This phase was designed to understand the ‘as is’ and help define the ‘to be’. It was set out provide guidance policies and understanding the current Information Architecture and how that would be translated on the SharePoint 2013 platform.
• Approach – This phase was to plan and understand pre and post activities in detail. This included the selection of a third party tool, a success matrix, mapping documents and implementation plans (delivery, roll back communications)
• Delivery – This phase was to implement the plan outlined and measure the success.

Great! We are nearly there, or so it would seem….

So I had a strategy and it was agreed by all parties. Then came the analysis and workshops to understand the finer details. This is a time consuming process as business stakeholders and end users have day jobs and need to be available to help you to understand the ‘as is’ solutions. Getting agreement from the business on which data sources are to be migrated is a must. The owners, administrators and users of the existing solutions provide an insight into:

1. How these tools are currently used?
2. How they can be improved?
3. What their priorities were?

After understanding the ‘as is’ it was time to create the relevant documentation to enable the delivery of the migration. This involved the implementation plans, success matrix, communication plans, roll back plans etc. As we opted to use a third party tool to aid in the migration, a procurement process was instigated to ensure the correct tool was selected based on fair and measurable criteria. As these items progressed the business needed to agree and cleanse the data they had created over the past 10 years. This, as you can imagine was a laborious task which still being undertaken today! This approach has been a great way to structure a migration which focuses on business needs and provides solutions to existing pain points. It provided a solid foundation to adapt when required during the process and provided a road map for the team implementing the migration.

Its high level approach was intentional as it needed to provide flexibility to allow for a variety of data sources. It did take into account that the destination: SharePoint 2013.

To Summarise

Below I have highlighted some key points to consider when undertaking a data migration to any SharePoint farm:

• If you have more than one data source in the ‘as is’ – verify if all are required by the business
• Consider cleansing your data in the ‘as is’ before migrating
• Understand the ‘as is’ solutions and how they currently function in detail
• Understand your SharePoint implementation – which services are enabled, features, edition etc…
• Look at it from all points of view – SharePoint Roles, End Users, and Business Stakeholders etc.
• Priorities – Understand which ‘as is’ solution has the biggest impact on the business and which will provide a quick win
• Agree a scope of work – what is to be migrated exactly, number of versions, any functionality etc.
• If you are using a third party tool, ensure you have the right tool for the job. Test it. Make sure it can do what you need.
• Ensure you have a roll back plan – just in case J
• Ensure you communicate with the business when and how these changes will affect them
• Measure the success of the migration by using a success matrix – use the end users to quantify the success.

Hopefully my experience with this process has been useful to you. If you have any questions or comments please feel free to get in touch… Happy migrating!

V