Couple of weeks ago, Efexcon (one of our partners) approached us with a case study from his most recent migration project. In this blog post, Rüdiger Gros, CEO of Efexcon AG, gives us insights on why, and how, he performed a migration from SharePoint 2007 to SharePoint 2013 for the Swiss “Bundesamt für Landwirtschaft” (Federal Office for Agriculture).
This post shows several learnings, and several examples of 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.
General Migration Procedure
In this project, the migration team split the work into technical and administrative tasks:
- The technical team did all the planning, as well as the Sharegate-based migration.
- The administrative team did the planning for communication, scheduling, testing, and quality control, including handing it over to the business owners.
For each site, the business owner defined a person who would be responsible for communicating when the old site would be locked for migration. They then had to perform initial testing, after a site migration, as well as all the permission configuration. Once a migration was complete, they would invite the users to the new site.
The migration had to be done from client side, without any server side installations, due to the IT policies of the customer’s internal datacenter.
How We Structured the Project Phases
The basis for a well-performed SharePoint migration is its structure and planning. Here’s how we proceeded:
- Analyze existing farm
- Identify differences in the new farm (other than the obvious differences caused by the jump over 2 versions)
- Define exception patterns for non migratable data, structures, or WebParts (Limitations)
- Analyze local list structures to transform them to Website columns and Content types
- Identify Sites with similar templates and structures
- Define mappings for migratable data and structures
Preparing the Migration
First off, the AD-Migration of Roles and Users to set the foundations. We then went ahead with defining a Dummy migration user for all User content not migrated to the target platform.
Once this was done, we created Site templates, as well as Website columns and Content types, then created the sites in the target environment. Finally, we created the site communication plan (presented below), and the schedule for all migrations.
The Site Communication Plan
Before each site migration was performed with Sharegate, we sent the site Owner 7 detailed messages, each deployed during key points in the process. Remember: the cornerstone of a successful migration to SharePoint 2013 is informing concerned parties of your actions along the way.
Now that you’ve properly scheduled your migration, you should start notifying people, early on in the process, of your intentions. Here’s what we did:
- 4 weeks before migration: Announcement of the migration date, including the procedure explanation
- 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 by 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
A common mistake that many people make is not communicating with teams after the migration. Keep in mind that, while you know exactly what you’re doing (hopefully), some will have a hard time adopting the new environment, or negatively perceive the value of your migration to SharePoint 2013. Here’s how we kept the concerned parties in the loop:
- After migration: Informing of the Site Owner, with a link to the test plan, and the mandatory acceptance report for his Site, as well as information regarding his duties before inviting users
- 1 week after acceptance report: Message thanking Site Owner for their support, as well as an acknowledgment of the successful experience working together.
How We Structured Migration to SharePoint 2013
You know the saying, right? There’s no SharePoint migration like a well structured one!
Allocating time to structure your migration will help you with two major things: First, you’ll make sure you don’t forget or skip a crucial step. Second, it’ll prevent you from getting lost along the way. Managing such a project can be overwhelming, so having things broken down into stages will help you stay on track. Let’s look at what we did:
- Test the migration of representative sites to test migration behavior.
- Verification of the migration tool’s capabilities for handling various authentication infrastructures, from source to target farm.
We tested a competitor tool and Sharegate, and found that only Sharegate could handle the complex authentication infrastructure with two-way SMS authentication. The competitor could login to the sites, but was unable to transfer data.
- Apply the mappings to Sharegate and migrate data
- Manual rework of some list content stylings (HTML/CSS) that looked different after migrating from 2007 to 2013
- Quality assurance check according to the test protocols
- Documentation of procedure improvements, for the next scheduled site migration, in the Migration Wiki
- Linking 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, we 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 very simple answer is: Because Sharegate is simple to use, and very powerful. In detail, Sharegate showed, once more, that it has major advantages over other competitors products.
In this project, no other tool besides Sharegate was able to handle the complex authentication infrastructure at the client level. 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
For each site, we mapped the data structures, and then started the migrations. In the event that a migration failed, due to technical or other reasons, we restarted the same migration as often as required. To be clear, 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.
While Sharegate delivers excellent migration performance, it also brings a 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 during the nights.
Which Elements Caused Trouble?
Never data. Which is good. Most often links. These are the most popular link-issues:
- 5% Document content that uses absolute URLs to point to other documents
- 5% Wiki content that uses absolute URLs to point to other wiki documents or document libraries
- 90% Links that were 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, for example, 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.
A Great Migration Partner
Due to detailed analysis, planning, and communication, we successfully completed this project, with impeccable customer satisfaction, in shorter time than originally planned.
Sharegate was an important key to our success, as Sharegate was very tolerant to farm failures and problems, and supported it as the perfect companion. In this project, we didn’t have to migrate workflows, so I can’t tell you anything about the workflow migration features for this customer’s environment. Every customer’s scenario will be unique but, until now, we can comfortably say that Sharegate is a great partner for tools and support.
For more resources on preparing a SharePoint migration you can read:
- How to Build a SharePoint Migration Plan
- Avoid Surprises with SharePoint Pre-Migration Report
- Best SharePoint Practices: the Inventory
- Build an inventory before a SharePoint Migration and put it in Visio