blog.frederique.harmsze.nl my world of work and user experiences

July 31, 2018

Some notes on the migration of SharePoint sites

Filed under: SharePoint — Tags: — frederique @ 23:11

Currently, I am involved in a project to move a large organization into the cloud of Office 365. That includes the transition from SharePoint 2007, 2010 and 2013 to SharePoint Online. Very useful, but quite challenging, because of the number of sites, unclear ownership and the complexity of the original environment. So let me give some tips, based on our experiences.

Only migrate what is still relevant

To save migration effort and to prevent the innocent user from getting swamped in obsolete information, you should try to exclude information that is no longer relevant.

This is tricky, because most content owners have a knee-jerk reaction when you ask them what can be  deleted: “nothing can be left behind”. But you may still get rid of some things. This is most important when it comes to items that are hard to migrate: it is really worth the effort to do this?

Determine which sites we can ignore

In this organization, we have not been able to pinpoint any “real” sites that we can just leave behind. They have many long running projects, most of the old information needs to be stored at least ten years and usually longer, and they don’t like to delete anything. However, we also have sites are not “real”.

So, we can still ignore quite a few test sites, demo sites and training sites that showcase the old functionality but won’t mean anything after the migration to SharePoint Online.

Determine which lists and libraries we can ignore

Within the team sites, there are some lists that we can ignore. For example, as they now manage the contacts in CRM, the contact information stored in the SharePoint sites is obsolete.

So the technical guys doing the migration, excluded these lists from the migration scripts. And they were happy to do so, because these lists had some weird customizations that them caused problems.

Determine which fields can we can ignore

The libraries had some fields with very strange content, like ID-codes that do not make any sense to ordinary users. As it turned out, some those were left-overs from the previous migration, from Lotus Notes to SharePoint 2007. Other fields we encountered were part of a very old version of the site template and no longer used by anyone.

So we left these obsolete fields out of the new templates and out of the property mappings.

Archive what you can, only migrate as ‘active’ what you must

We have to keep a lot of information from projects that have already finished. The **

Determine which sites are still active and which are inactive

We based our status labels on existing lists of project (for example in CRM), last modified dates and information from the business. We have some humongous Excel sheets to gather, enrich an manage all of this information. Over the course of our long term project, we have to update this list.

Create a simple archive template

The goal of these archive sites is to allow users to find old information. This implies these sites don’t need to have advanced functionality. No smart lookups, workflows, beautiful image carousels or anything like that.

So we created a very empty site template: a container into which we could migrate the old lists and libraries. The tech guys included in the migration script steps to make sure that no fields are required anymore. And complex lookup fields that have a lot of customization are mapped to basic text only fields. After all, all we want to do is preserve the content, present it in views that help them make sense of that content and allow for searching.

Migrate the archive site at your leisure

The good thing about archive sites, is that nobody adds or edits anything there. So you don’t need to worry about a content freeze for these sites, which makes our lives a lot simpler.

Prioritize

Think where you want to start. For us the key criteria when we plan which sites are moved first are:

  • In which SharePoint does the original site live?
  • How complicated is the target template and migration script for this type of sites?
  • Do we have owners or other stakeholders who we can contact about these sites?
  • Are the new sites needed for another project?

Get rid of SharePoint 2007 first

We want to move out of the severely prehistoric SharePoint 2007 first, before it crumbles completely. After all, SharePoint 2007 has been declared officially “dead” by Microsoft almost a year ago (SharePoint Server 2007 end of support roadmap) https://docs.microsoft.com/nl-nl/office365/enterprise/sharepoint-2007-end-of-support?redirectSourcePath=%252fen-ie%252farticle%252fSharePoint-Server-2007-End-of-Life-Roadmap-ba124775-d5c0-4d68-b88d-8458ad4c3717 And we are experiencing difficulties with storage space on this server,

So we do our best to get as much as possible out of SharePoint 2007 as soon as possible, before we start on the “younger” SharePoint environments.

Start with the simple scenario’s

We did not want to get stuck figuring out all the complications in the beginning. Instead ,we got started with what we could do at that time. This way, we could iron out the kinks of our basic process and migration technology before we start pushing the envelope with the more complex stuff. And we can already lighten the load on the old servers and show the stakeholders some progress before things get more complex.

So we started with the migration of archive sites, rather than active sites. And we started with a set of sites that were relatively homogenous and relatively simple. We are still working up the courage to take on the “swamp” of other sites…

Start with sites that have clear ownership

Unfortunately, we have a lot of sites that have no clear content owner. The site owners in Sharepoint are IT people, not people in the business. Because we have over 8000 sites, we do not want to dive into each individual site, to check who has been active in there recently…

So we started with sites belonging to a business unit that has a mostly complete list of all project sites in CRM, stating the region it belongs to. The secretaries of those regions were able to take charge. They can tell us which sites are still active, which are important and need special attention, and how to deal with sites that turn out to be exceptions. And they could do some testing and give us sign-off on migrated sites.

Align with related project

We are not only transitioning to Office 365, but also to a new version of CRM in Dynamics 365. For one of our business units, CRM and SharePoint were always part of the same way of working. They work from CRM and the information is stored in SharePoint. The CRM project is moving faster than the SharePoint migration.

So we prioritized the migration of the SharePoint sites belonging to this business unit, allowing the Go Live date for the CRM project and the SharePoint project to coincide.

 

All in all, we are still working on the migration to SharePoint Online. But with these tricks, at least we are making progress and we’ll get there eventually.

June 4, 2016

Surprises from sites and owners in the migration

Filed under: Governance — Tags: — frederique @ 9:13

In our recent project to migrate all active collaboration sites of an organization, we interacted with a lot of site owners. We had anticipated several questions that the site owners would have and challenges that they would meet. But there were some moments when I got reactions that I had not expected at all.

We mailed about 700 site owners about 750 site collections. And it is a rather heterogeneous bunch: they come from all departments in the organisation. Some are very SharePoint savvy, while others turned out to have no clue. Some are incredibly proactive, while other could not be coaxed into any action. I have already told about the lessons learned in the migration as a whole in a previous post. Now let me elaborate on some of the surprises the owners and the sites had in store for us.

People listed as Main Site Owner who had no owner permissions

We had a migration list, detailing all collaboration site collections with two Main Site Owners who we would contact several times over the course of the migration project. We asked these people to confirm if they really were the site owners we should contact.

Interestingly enough, I got quite a few responses when I sent out the new URLs of the migrated sites, of Main Site Owners who could not access the migrated sites. At first I feared something had gone wrong with the security settings in the migration. But then it turned out that none of the people who complained about access had actually had permissions on the original site. So the migration was perfect: no permissions to no permissions. But the question is, why did these people confirm that they were Site Owners of a site where they were no kind of owner at all?

The people who gave me more details all thought that we were talking about some other site. The apparently had not clicked the prominent link visible in the migration list. They had seen the site name, and sometimes the name of their co-Main Site Owner (most sites had a deputy) and assumed they knew what site it was. They were mistaken.

Bottom line: people are only human, and very busy. So take into account that the response is not always accurate.

Mix-up between different kinds of SharePoint sites

I’ve talked several people who turned out to be confused about the different kinds of SharePoint sites we have in this organisation. There are different sites from the Local organisation: collaboration sites, intranet portal, sites with special applications (at a separate address). And there are also sites from the Global organisation. I have to admit, the environment also confused me when I got here, but that was mostly because I did not know how to get from one part to the other. But I can see the difference between the Local sites and the sites managed by the Global organisation: they not only have a different address but also a different colour.

We emphasized in our communication that we would only migrate Local sites from the collaboration address, which were branded as Group Sites. Nevertheless, I have had several questions about people asking about the migration of sites that turned out to be one managed by Global or subsites in the Portal.

Bottom line: for some users, all of those SharePoint environments are the same. Don’t assume that everybody understands the difference between intranet and extranet sites, portal sites and collaboration sites, regular sites and secure sites…

Some site owners voluntarily indicate that their sites does not have to be migrated

In previous migration projects we saw that Site Owners always said that everything had to be migrated. Unless they found out that they were the ones who had to migrate their own sites. In this project we told the people that the IT team would migrate their sites, but still 26% of the sites could be deleted, according to the Site Owners. We did tell them that they would have to take some actions along the course of the migration. Maybe that was enough to avoid unnecessary migrations. Or maybe these people are just very orderly and like to clean up, at least when prompted to do so…

Bottom line: Ask explicitly if sites should be migrated, because that may result in an unexpected clean-up.

Some site owners have set up exotic configurations

The site owners are in charge of their own sites. And some of them took the opportunity to rebuild their standard site into something exotic. And these exotics don’t always survive a migration. There were some spiffy calendar overlays ,workflows with manual links, strange things in Infopath forms, pages with weird styling, browsable reference guides in htm, non-Sharepoint pages in mht format,… Some of it we knew about, but some of it surprised us when we saw it. And most of it migrated smoothly, but some things broke.

Bottom line: Keep an eye on sites as part of your regular governance. Otherwise you may run into unexpected issues when you migrate or update, and when the unusual sites break down.

A migration is a nice occasion to meet your site owners and sites. Let’s not wait for the next migration to do it again, but keep in touch with the owners and keep an eye on their sites.

May 31, 2016

10 lessons learned in a Team Site migration

Filed under: Governance,SharePoint — Tags: — frederique @ 23:10

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

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.

Powered by WordPress