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.

1 Comment »

  1. […] 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 […]

    Pingback by Getting our users on board in the migration to SharePoint Online – a checklist « blog.frederique.harmsze.nl — December 1, 2018 @ 1:22

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress