Contact Info

Löberenstrasse 47

Phone: +41 44 586 5018

Web: EFEXCON Homepage

Rufen Sie an: +41 44 586 5018 oder +49 711 518 66 990|info@efexcon.com

Mastering a complex SharePoint migration with Sharegate

Mastering a complex SharePoint Migration with Sharegate requires good preparations, experience and profound understanding of SharePoint. And Sharegate. This post shows several learnings and good practices from a project we just finished. The scope of the project was the migration of about 130 Sites from a SharePoint 2007 platform that had been hosted externally to a SharePoint 2013 farm hosted internally at the customer’s datacenter.

In March 2015 we were informed that our project platform based on SharePoint 2007 would be shut down at the end of the year, the replacement should be the standard SharePoint 2013 platform of the “Bund”, the Swiss governments platform.
One thing we knew for sure: Our internal project managers should focus on their projects and should not waste time with migration work of their working platform SharePoint.
But the initial situation was critical already: We had started too late, the datacenter had almost no resources for this project and we suffered from massive technical restrictions due to datacenter policies that made an automated or server based migration impossible.
Damaris Jeker, Stv Fachbereichsleiterin, Bundesamt für Landwirtschaft BLW

General Migration procedure

In this project, the migration team split the work into technical and administrative tasks:
The technical team did the whole planning and the Sharegate based migration.
The administrative team did the whole planning for communication, scheduling, testing and quality control including handover to the business owners.
For each site, the business owner defined a responsible person who had to

  • communicate when the old site would be locked for migration or if the site would be archived instead of migrated
  • do the initial testing after a site migration
  • configure permissions
  • invite the users to the new site once a migration was done

The migration hat to be done from client side without any server side installations due to IT policies of the customer’s internal datacenter.
Sites that had been marked for archiving had been taken out of our scope of the project and has been done by another partner.
After all sites had been analyzed and classified for archive or migration, we had 74 Sites left for migration that had been categorized into 60% sites with normal complexity and 40 % of sites with a high migration complexity.

How we structured the project phases

Pre-Check

1. Analyze existing farm
2. Identify differences to the new farm (asides a jump over 2 versions)
3. Define exception patterns for non migratable data, structures or WebParts (Limitations)
4. Analyze local list structures to transform them to Website columns and Content types
4. Identify Sites with similar templates and structures
5. Define mappings for migratable data and structures

Migration-Preparation

1. AD-Migration of Roles and Users
2. Definition of a Dummy migration user for all content of User not migrated to the target platform
3. Create Site templates and Website columns and Content types
4. Create the sites in the target environment
5. Create the site communication plan* and the schedule for all migrations

Thanks to the professional and efficient support from EFEXCON AG, we still mastered it – despite all technical hurdles, bad luck and mishaps. The result at the end of the project was simply top: We even undercut the tight schedule and even the budget, the migration quality was excellent and the users where excited and motivated to work on with the new SharePoint 2013 platform.
Damaris Jeker, Stv Fachbereichsleiterin, Bundesamt für Landwirtschaft BLW

*The site communication plan

Before we migrated a site with Sharegate, we informed each site owner with 5 informative messages:
– 4 weeks before migration: Announcement of the migration date including the explanation about the procedure
– 2 weeks before migration: Reminder about the upcoming migration and suggestions on what to tell the site users
– 1 week before migration: Information about the preparation process and a checklist of things the site owner should have finished now
– 3 days before migration: Information about the upcoming locking of the existing site and reminder that all users have to finish their work on documents and check-in everything within the next two days.
– 1 day before migration: Last reminder that the migration will start tomorrow
– After migration: Information of the Site owner with the link to the test plan and the mandatory acceptance report for his Site and the information about his duties before inviting users
– 1 week after acceptance report: send out of thanksgiving for support and the successful working together.

How we structured the migration

1. Test migration of representative sites to test migration behavior
2. Verification of the migration tools capabilities to handle the different authentication infrastructures from source to target farm
– We tested Metalogix and Sharegate and found out that only Sharegate could handle the complex authentication infrastructure with two way SMS authentication. Metalogix could login to the sites but was not able to transfer data.
3. Apply the mappings to Sharegate and migrate data
4. Manual rework of some list content stylings (HTML/CSS) that looked differently after the migration from 2007 to 2013
5. Quality assurance check according to the test protocols
6. Documentation of procedure improvements for the next site migration in work schedule of the Migration Wiki
6. Linking of the migrated sites to the global navigation

What kind of data and structure did we migrate?

– About 85% of the migration had been list data and documents
– About 10% had been Wikis and blogs
– About 5% had been Image-libraries
Almost all list modifications or custom lists or libraries have been customized locally, without website columns or website content types.
To fix that and to prepare the new platform for a better search experience, he project team created the best possible ‘website data model’ with website columns and website content types and built the site templates based on these structures as far as this was possible.

Why we used Sharegate

The most generic answer is, that Sharegate is simple to use but very powerful. In detail, Sharegate showed once more that it has some relevant advantages over other products like Metalogix.
In this project, no other tool then Sharegate was able to handle the complex authentication infrastructure at the client. The other thing is that support and access to technical support works pretty well for us. And we had to master the migration without any server side access. Sharegate proved to be the best one here, too, even with large amounts of documents and sometimes long latencies.

How we used Sharegate

Pretty basic. For each site, we mapped the data structures and started the migrations. In case a migration failed due to technical or other reasons, we restarted the same migration as often as required.
Technical problems did not come from Sharegate but from either the source or the target farm, so we had to fine-tune the farm settings several times to master the migration.
As Sharegate delivers a very good migration performance, it also brings heavy load to the farms so we started to split migrations in easy parts that ran throughout the days and scheduled complex or mass data parts in the nights.

Which things caused trouble?

Never data. Which is good. Most often links or changes in display behavior of SharePoint.

These are the most popular link-issues:

– 5% Document content that point with absolute URLs to other documents
– 5% Wiki content that points to absolute URLs to other wiki documents or document libraries
– 90% Links that have been too long after migration. This happens mostly with E-Mails stored to Document libraries or documents stored in deeply structured folders. The root cause is of course that if the root path to the source farm consists e.g. of 10 characters where the destination farm root path consists of 25 characters, all links will be enhanced by 15 characters, which can cause migration issues.

These are the most popular display-issues:

In the source farm, several HTML-formats had been used in Lists and Views to display nice KPIs or images centered in the display column.
In 2013 the list behavior has changed and the trade-off to display HTML-formatted fields required to
• either change the format template of a view to basic table, which leads to the fact that all other views are no longer displayed in SP 2013 style
• or to ‘tweak’ SharePoint lists with Display-Templates and JavaScript (see: http://www.learningsharepoint.com/2013/04/01/add-task-status-indicators-in-sharepoint-2013-using-js-link/)

Summary

Due to a detailed analysis, planning and communication and an incredibly good working together between the customers and our project members, we could master this project with perfect customer satisfaction in shorter time than originally planned.
Sharegate was an important key to our success as Sharegate was very tolerant against farm failures and problems and supported is as the perfect companion.
In this project we did not have to migrate workflows, so I can´t tell nothing about the workflow migration features for this customer’s environment. Each customer’s scenario is different, but until now we can say that Sharegate is a great partner for tools and support.

r.gros
CEO at EFEXCON AG
Ich schreibe über Customer Relationship Management (CRM), Customer Service, Customer Journey, Inbound Marketing, Content Marketing, Social Media, Software, SharePoint, Office 365, über Projekterfahrungen, Projekt-Turnarounds und Startups.
Ansonsten bin ich Trailrunner, Mountainbiker, Zuhörer, Erzähler, Startup-Macher und CEO
2016-10-20T21:27:21+00:00