Recently I was in the lead in a migration project, in which we upgraded collaboration sites from SharePoint 2010 to 2013 and moved them to another location. Let me share with you some lessons I learned in that project. Some from friendly feedback, others from hitting snags head on. Some related to SharePoint, and others that don’t have anything to do with technology but are all about people: communication and process.
SharePoint
1.The content database attach upgrade method is quite handy
We had hundreds of sites to upgrade and migrate in a short time. There was no time and manpower to do it manually or to write a custom code solution to do the migration. We did have a migration tool at our disposal but that was not suited for bulk migrations, and the other tools we looked at we too expensive. So we decided to use the content database attach upgrade method.
We were quite pleased with the result: we did manage to migrate 551 site collections in one weekend, even though some were quite large. The content and settings moved along nicely, including timestamps and the names of the authors, even if they had left the company.
2.Ask a SharePoint developer to script clean-up in Powershell: automate repetitive tasks
Unfortunately, the old collaboration sites were chock-full of weird customizations. They had even customized the permission mechanism, for Pete’s sake… So we did not want to upgrade the sites completely as-is. We could have tried to reconfigure the sites manually, but that would be a lot of work.
So a SharePoint developer wrote Powershell scripts, to clean out the unwanted customizations and transform the sites. We could not get rid of everything, but after the clean-up, the migrated sites are a lot more future-proof…
- SharePoint developer. We talked to other developers, but we found out that they could not write these scripts sufficiently quickly and accurately. The scripts had to tie into SharePoint functionality, so the developer needed a good grasp of the way SharePoint works.
- Automate as much as possible before the migration weekend. We had a non-stop process over the weekend for the production migration, where people had to perform tasks in the middle of the night. That can be a recipe for disaster. So the developer automated as much as possible, so that he hardly had to type in any commands and took little risk of making mistakes.
3.Align the settings between the old and the new SharePoint
We found out the hard way that the settings in our new SharePoint 2013 environment differed from the settings in our old SharePoint 2010 environment. These differences pertained to exotic exceptions in our collection of collaboration sites, so we had not included them in our regular test cases. For example:
- The threshold for the maximum number of items in a list has been increased in the old environment to 13.000, while in the new environment the lists complained after 5.000 items.
- HTM and MHT files were opened in the browser in the old environment. In the migrated sites, users are prompted to save such files.
So next time, we will make sure to compare the settings and align them beforehand.
The team’s process
4.Test the functionality
We started testing at an early stage, from different perspectives.
- Content: Is the content intact, including things like the number of items, the timestamps and author names, and versions?
- Settings: Are the settings intact, including for example views, web part pages, permissions and site settings?
- SharePoint functionality: did the we somehow break the regular SharePoint functionality or does it all still work properly?
We needed to know what the Site Owners and other users would get after the upgrade. Firstly, because the developer was able to fix some issues before the real migration, in his clean-up and upgrade scripting. And secondly, because this allowed us to warn the Site Owners which elements would not transfer well. Fortunately, this pertained only to functionality that very few sites used. For example, the Term Store is not part of the content databases. We left it behind, because nobody really used Managed Metadata.
5.Test the infrastructure
In addition to the functional test of the environment, we also tested how the migration would run on the infrastructure:
- Disk space. Given the size of the content databases, how much space do we need on the servers? Do we have that space? We didn’t, so we requested additional space.
- Time. How much time does the migration take on the servers we have? What if we add a server for parallel processing with our clean-up scripts?
- Snags. What snags do we hit? For example, we found out that we had to install a feature that was no longer used but still referred to from within SharePoint. And we found out that some servers would pause in the middle of the night, if we didn’t take special precautions.
I am very glad we did several test runs, because in our first runs we got nowhere near the finish line within the planned timeframe of one weekend. And after these tests and subsequent changes, we did manage to finish the migration of the production environment by Sunday afternoon.
6.Create a cookbook and timetable for the team
Especially during our migration weekend, the pressure was on and we worked round the clock to perform our tasks. Some tasks and some transitions between tasks could not be automated easily. So we made them foolproof in our process:
- Cookbook: We could blindly follow the clear and explicit steps we had written down in our cookbook beforehand, based on our thorough tests.
- Timetable: The SharePoint developer/architect who devised the technical migration method created an excel sheet with all tasks, with calculated fields indicating when they had to be started. The calculations for the planned times were based on the durations found in our tests, and the calculations for the actual/expected times were based on our progress during the migration weekend. This way, we all knew when we could expect it to be our turn.
Migration timetable (thank you Macaw colleague Peter Heibrink!)
7.Keep the lines open
Part of our team was in The Netherlands and the others were in India. So we could not get together in a real-life “war room”. So we worked from our homes during that migration weekend, and we kept in touch via digital means:
- Conversations in Skype for Business. This was our main channel for informal chats and voice calls, to check progress, ask questions, get answers, put forward suggestions and generally encourage each other.
- An e-mail thread to keep all stakeholders informed when we moved to the next step. They could read the e-mail on their mobile devices – not everybody had to stay glued to their laptops for the entire weekend.
- A list of emergency phone numbers, so that we knew how to call and wake up key people if anything got stuck.
The most important thing is actually not the digital communication channel, but the willingness of the team members to share their thoughts, to express any doubts or questions they had, and to answer questions. This way, we could really work as one team.
Communication with Site Owners and Users
8.“Beautiful” emails are ignored as spam. Make it functional and personal
We started with an email to all Site Owners. It looked like a newsletter, styled to fit the corporate look & feel. We regretted that decision, when at a later stage we heard that some Site Owners had completely missed the communication. They literally said: “nobody reads those emails in newsletter format.” Oops.
What worked best, were emails that:
- Have a functional look. No fancy styling, just mail to a colleague.
- Have a clearly visible key message, in the subject and in the first lines: what is the point, what do we need from you. For example: “Group Sites migration starts Friday May 20 18:00h: Check in the final documents and inform the users”
- Make it clearly relevant for them personally as much as possible. For example, in the subject of an individual mail we put: “Can we delete the Group Site XYZ?”, when the owner of a big site hadn’t told us if he wanted us to migrate it. This take a lot of time, but did allow us to take some unwieldly sites out of the migration. And when we mailed the new URLs after the migration, we used a mail merge to send every owner a mail with their own name and specific link, highlighted in a clear but ugly yellow.
9.A self-service migration list helps, but you still need to process email replies
We set up a migration site (already in SharePoint 2013), with information about the migration, a discussion list for questions and remarks, and a self-service migration list:
- Information about each collaboration site collection: In that migration list we put an item for every collaboration site collection, with key information: the main site owners as far as we knew them, the URL, some metadata carried over from the site request list.
- Fields that we wanted input on: We asked the owners to check the Main Site Owner fields and change the names if needed. We also asked them to switch the status field, to indicate if the site should be migrated or could be deleted.
- Dynamic views helped the owners and users find the sites relevant for them: filtered by Main Site Owner = [Me], grouped by department, grouped by status.
Within a few days after our initial mail to all site owners, about half of the items in the list had actually been updated by the site owners themselves. That saved us a lot of time and effort! But then again, about a quarter replied by email so that we had to administer their wishes. It was more important to us that we actually get an answer than that this answer was given via our preferred channel, so we thanked them anyway. And the rest had to be chased to elicit any answer at all. Fortunately, we had decided that if we got no response from the owners, we would simply migrate the site to avoid getting into time-consuming fights..
10.Asking the Site Owners if they want to migrate their sites is worth the effort
We contacted the site owners, because we wanted them to take a small part in the migration: make sure their site was ready for migration and inform their users. So we asked them to confirm they were the main site owners we should contact.
Because we were mailing them anyway, we also asked them to tell us if they wanted to migrate their sites. We fully expected everyone to blindly respond that of course their sites had to be migrated, especially because 6 months earlier we had sent out a regular request to delete inactive sites. But lo and behold, it turned out that the site owners said that a full 26% of all collaboration sites could be deleted! That saved us a lot of time during the migration weekend.
