SharePoint Stuff

The path to a trial migration

I’ve been suitably inspired by Andrew Warland’s fantastic two-part series documenting his approach and migration to SharePoint Online, so much so that I thought it would be a fun series to write about my own experiences.

Take a look at Andrew’s blog series here.

It is’nt my intention to necessarily document Microsoft best practice in this series, rather just to explore some of the challenges, sucesses and experiences I notice along the way.

The current situation

My organisation has recently made the decision to move to to the cloud, with O365 being the naturally preferred destination. SharePoint has been well embedded, and heavily used within the business for several years, with on-premises SharePoint 2010 currently in production.

Finally, in terms of the SharePoint architecture and data volume, there are only three web applications to merge together as part of the migration effort. However, there are several site collections within our main intranet web app, plus many sub-sites nested within them, meaning the huge database sizes behind these site collections could prove difficult come migration time.

A note on the new, flat structure

Our current environment has a well established top-down structure in place that is generally consitent across the environment.

Having already made the investment in ShareGate, this will be the tool of choice for the migration. In the version 11.0 release of ShareGate, a new restructure option now allows you to promote sub-sites to top-level sites post inital migration from the source SharePoint environment.

Considerations for a successful migration plan

One of the biggest issues to be resolved before we can start any sort of migration activity, is the fact that we have several content databases well over the 200GB recommended general use size limit.

• Read about the recommended size limit here

Microsoft best practice suggests that any environment that has site collections, sites, content databases, libraries or lists that exceed the software boundaries and limits should be remediated prior to any migration activity. In this case, the main idea is to split each content database that exceeds 200GB into seperate content db’s, and where neccessary, move or promote sub-sites to site collections and attach new db’s.

Armed with the knowledge of the recent restrcuture functionality coming to ShareGate, plus my own personal feeling that any remediation activities to our current environment may in of itself carry adverse risk to the estate we proposed a different approach.

• Issues with splitting up large site collections into smaller content databases
• Promoting sub-sites to site collections in SharePoint 2010

Trial migration begins

With all the reporting capabilities at our disposal via ShareGate, I was able to get a firm grasp of what resides within each site collection in our environment, in terms of:

• The size of each sub-site underneath the top-level
• Number/ size of libraries and lists
• Number of items in each of the above
• Any workflows running in any of the above

From this I ran a trial migration of a sub-site from SharePoint 2010 to a newly created team site in SharePoint Online.

Pre-migration

Before I kicked off the migration, I ran the source analysis tool within the Migration > Plan section of ShareGate. I noted the following obersavations:

• The source analysis within “migration” in the ShareGate tool, although listed as only being able to analyze up to SharePoint 2013, does in-fact work for 2010

• The source analysis cannot run at the sub-site level, meaning that you need to run it at the site collection level then just filter down to the sub-site in question through the report itself
• Source analysis gives you a report of all checked-out files within a source site.From this, I created a simple view within each of the libraries that contained checked-out files to send to the site owners for action

Post-trial migration

The trial migration completed successfully as expected, however there were several interesting results I noted:

1. Everyone receieves a welcome email

If you migrate the permissions, once the source permission groups migrate each user will recieve a welcome email to the new SharePoint Online site.

There’s no GUI control for this as of this time of writing, but you can switch off the email notifications via PowerShell.

2. /Pages/ or /SitePages/…that is the question

Publishing sites seem to be the trickiest to migrate, especially those with custom master pages or page layouts. When migrating publishing sites, the Pages library is migrated wholesail, meaning the content won’t reside in the SitePages library (where new client-side pages are located).

3. Un-editable modern homepage

After the migration had completed, the new team site homepage threw up an error every time you tried to edit it.

I tried some of the documented resolution steps found here, but none of them worked for me. My solution was to just create a new page to replace the broken homepage, add all the relevant webparts and make this one the new default homepage.

Transforming classic publishing site pages to client-side pages

Publishing site pages will all be migrated as classic SharePoint pages, without the modern look and feel of a client-side page. My understanding is that for publishing pages with custom page layouts, additional metadata or custom content types will need to be transformed via PowerShell and creating a custom mapping file.

• Understanding and configuring the publishing page transformation model
• Video: Page Transformation for publishing pages based upon custom page layouts
• Page transformation webcast series

(I’m planning on writing a seperate blog post walking through an advanced publishing page transformation in the near future)

Its also worth considering that in the release notes for ShareGate 11.0 it makes mention of the fact they are researching the ability to transform classic to modern pages, so that could well simplify this process in a future release.

Conclusion

Overall, I was happy with our trial migration and believe it is a viable approach for us to move from on-prem to O365. Some lessons learned for myself would be to consider and SharePoint permissions audit prior to migration to remove any unecessary permissions, send an inventory out to site owners aswell as checked-out files, all in the name of reducing the migration effort.

This will be an ongoing series of posts, which i’ll focus more the on the nitty-gritty of the migration effort than anything else, but as always if there is any feedback or suggestions on how to improve this site, please let me know!