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

November 30, 2018

Getting our users on board in the migration to SharePoint Online – a checklist

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

I am involved in a migration project, to move thousands of sites from SharePoint 2007 to SharePoint Online. There is the technical aspect to it, but I am mostly concerned in how we can get our users on board. Give them the benefits of the upgrade to new tools that meet their needs better, whilst mitigating the hassle of the actual migration and change.

I have talked about the question what you should migrate, in what form and in which order in a previous post. Now here’s an annotated version of the 15 point checklist I use in the actual migrations.

1.Determine the migration scenario

Do you want to migrate the sites as they were, or only the content? To what template? With what mapping of the metadata? And what about the permissions? We have different scenarios for different situations. For example, archive sites, project sites and department sites for different business units, which have different source templates and different needs.

2.Test the results of the migration factory

Once you have the scenario, test it in a trial migration of a representative set of sites before you ask the business users to test anything. We have seen some unexpected results in early attempts, so we have learned to invest the time in these tests, to make sure the business users don’t trip over these problems. We keep track of all the sites and their migration status and the issues in SharePoint lists.

3.Involve the key users

Talk to the business about their needs, what do they think is still relevant from the old sites, what do they want with the new sites. And ask some key users to check the sites you migrated. After you have weeded out the errors.

4.Plan the final migration of live sites outside office hours

You need a content freeze for the migration. No problem for archive sites, because nobody is actively using them. But for active sites, you need to minimize the time users cannot work in these sites. Our solution is to migrate the bulk of the content while they work, and then do an incremental migration to update the content over a weekend. Plan the migration weekend with the business, to try and suit their calendars.

5.Communicate beforehand what will happen

Some people take any changes in their stride, but others really want know beforehand what will happen. So make sure all users are aware of the upcoming migration. Communicate, for example via the intranet and/or email:

  • Which sites will be migrated (for example, project sites or department sites) and to which environment they will be migrated. Hopefully they have already heard something about the new environment, like the rollout of Office 365 with SharePoint Online and you can refer to that.
  • What do they have to do. For example, stop using the old sites Friday before 18:00, park files locally if they have to work during the migration weekend, on Monday reconnect their Outlook plug-in to the new address, and check if all of their content was moved over correctly.
  • How are you going to help them. For example, provide them with a user manual, an email address and phone number they can contact, and in-house support on the day after the migration.
  • Who they can contact if they have questions now or later. If you send the message by email, send it from the mailbox they can contact.

Also, make sure you tell the key users, secretaries and other influences what will happen, so that they can answer any questions their colleagues may ask them and prod them in the right direction.

6.Check which sites need special attention

We are migrating department sites at the end of the year. So the Finance people started to panic, because this is their busiest time and they do not want anything to interrupt their work. We reassured them that the old sites remain available in read-only mode; they can always still find the information there. And we take extra care when we migrate their sites. We also pay special attention to sites that have a lot of traffic, like sites that are included in the main navigation of the intranet.

  • Test if the content has been migrated properly. We cannot test every single site that is migrated, but we make sure to test these high priority sites.
  • Check the permissions: can they all still read and contribute the same as in the old site?
  • Are the start page, the site menu and the views in the lists and libraries correct and clear? We migrate from an on-premises environment that can handle view of over 5000 items to an online environment where such views may break.

7.Fix the glitches like overweight views

We migrate from an on-premises environment that can handle view of over 5000 items to an online environment where such views may break. So when we migrate large sites, we have some views that give an error instead of a list of items or documents, sometimes even default views, This would freak out the users, so we make sure we fix those views with filters based on indexed columns. Fortunately, we can do this before the migration weekend, once the bulk migration has been performed – because we already index the relevant columns in the site template.

8.Arrange for the update of links to the migrated sites

In this round, we are migrating some department sites that are connected to their intranet via static hyperlinks. In a previous round, we migrated project sites that were linked to CRM. These links need to be updated. We do not own that intranet or the CRM environment, but we do not want our users to hit dead links. So we asked around and found the managers of those systems who could update the links.

9.Provide an entry point to the new sites

The users have to know where they can find and access their new ‘digital homes’. We have done that in different ways.

  • When we had reliable list of owners for each site, and owners we could trust to inform their members, we sent the owners a mail with their URL (using a mail merge on our list of sites and owners). However, in most cases our governance failed in the past, and we don’t have a reliable site owner.
  • For the migration of a large number of project sites, we told the users to access their new sites from CRM, because that already was their preferred entry point and we could update the site links in CRM.
  • For another migration, we pointed the users to a site overview page with a search option where they could find their site. And we gave them the tip to Follow that site when they have found the new address.

10.Offer help materials

Our users need to take some actions after the migration, like reconnecting their Outlook plug-in to the migrated sites. You need to give them instructions on how to do that. Also, they have to learn how to use the new SharePoint Online environment. Most of it is intuitive enough, but not everything and now for everyone. So you need to give them a user manual and tips on that.

Offer them a single point of entry for all of these help materials. If you use a SharePoint site for this, you can update the information as you experience the migration and hear the questions that can come up. But be aware that some users will print put all of the materials as soon as you send them the link, so make that first version a serious one.

11.Send a message before the migration starts

If you have published a message on the intranet about the start of your migration, you cannot assume that everyone has seen it. So send an email Friday afternoon. Make it short and to the point, and put the key message in the Email subject: stop working in your department site before 18:00.

12.Run a script to compare the number of items in the old and the new sites

After the incremental migration to update the latest additions and changes in the migrated sites, the number of items in the source and the target should be the same. Unless the users have deleted files from the source file and the incremental migration cannot take that into account.

We had a script to compare the number of items automatically, and at the end of the migration weekend is the time to run it. In one round of migrations we forgot to run the script at that time and only ran it after the first day the migrated sites had gone live. But by then there were many discrepancies, especially when users got enthusiastic about the new options…

13.Make sure the old sites are locked after the migration

After the final migration to the new sites, users should not add or edit anything on the old sites anymore. Yes, this is obvious. But no, this does not always turn out well. We have had a glitch in the script, so that people were still able to work in the old sites. And of course these people had not paid attention to the communication.

So you need to double check that these sites are locked down in read-only mode, to allow the users to check the migration but force them to move to the migrated sites.

14.Send a message after it has finished

After you have finished the migration, make it perfectly clear to the users that they have to switch to their newly migrated site now, where they can find it, what they have to do now, and where they can find help. Put in on the intranet, send an email, tell all the key users and secretaries. This is not the time to be stingy with your communication.

15.Arrange for support on the day after the migration

There are always some issues or at least questions after a migration: where is my site, I’ve lost some documents, how do I connect the new site to my Outlook plug-in, … Try to be at their offices, to give them personal attention. Pay attention to the details when you arrange it, especially if “strangers” are to help out in this matter: who should be where and when, who is the host at that location and what are their contact details.

 

This weekend we are migrating the department sites of one of our more prolific business units. And yes, we use the checklist, specified for the migration at hand. In OneNote, with checkboxes to indicate what we have already completed. Check.

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