Protiviti / SharePoint Blog

SharePoint Blog

October 05
A SharePoint Migration Story | Part II: Developing a Strategy

​In the first installment of this two-part series, A SharePoint Migration Story Part I: A Bear in the Woods, I reviewed the high level topics that can lead to detailed considerations as you dig deeper into the details of your migration project.  For example, as you get into the classification or categorization of content you typically work to uncover metadata, processes or activities which can facilitate decisions about your migration strategy.  Logical groupings of content, sites and content classification can help you make decisions about what content gets migrated and what content does not.  

In the second half of this series we will explore a strategic approach to migration planning.   There are several options, including some great suggestions introduced by my colleague Greg George in his blog post, Content Migration Strategies.  

Another great source of information for developing a migration strategy is a presentation given recently by a colleague of mine, Erica Toelle, on Plan to Migrate to SharePoint Online.  Some of the points mentioned earlier in this series come from Erica’s insights and this presentation.

It’s in the Details – Migration Planning Must Include Future Business Needs

In one instance where I was working with a client to plan a migration strategy for a particular department site, we got to a point in the planning process where we discussed how end users were currently using the site in SharePoint 2010, how much data was currently stored and what type or amount of data we could expect in the new site once business users were migrated to it.  This is my bear in the woods…

During our pre-migration analysis, we uncovered that business users from a particular department were storing project documents in a source site collection, where each project was stored within a different library.  They had a robust set of metadata and document sets already in place to categorize content, as well as permissions to control access to this content.  This all needed to be migrated over to the destination environment.  They had almost 50 projects stored in this one site collection, all requiring migration.  None could be retired and their site collection had reached almost 200 GB in size.  The size of the site collection roared like a bear as soon as we found it because of the SharePoint 2013 content DB size threshold of 200 GB.  This threshold applies here because no RBS was in place and would not be the destination.  This led to discussions about how end users would use the destination environment once the migration was complete.  We found that this data set in the source was just the tip of the iceberg – there were many more such projects coming to SharePoint very soon, with large amounts of documentation, which end users were going to be manually moving into the SharePoint 2013 destination once our migration of these 50 projects were complete.  Ultimately, it was estimated that this business group would be storing about 2 TB of project documents over the next 2 years, all active content, all requiring similar levels of classification and permissions.

So, in this case it was not sufficient for our pre-migration analysis to simply include details about the existing environment and how we would move that data into the destination, preserving all of its metadata, permissions, etc.  Our planning process required us to deal with the bear in our path – to also include details about how the business group will use the site in the future.  We needed to account for this future state in architecting the new environment, and ensure that the projected data over the next 2 years could also be stored and managed effectively in the new environment.

As part of our plan, we determined that storing 1 project per library was a well-established process that worked well for the business group, so we decided to keep that process in place going forward.  In particular, we established that a single project would not span more than 1 library.  As well, the current information architecture with its metadata fields and document sets was also well established, robust and they were structures that the business group wanted to continue using for future projects.  They also already had a workflow that the business group ran to create new project libraries, setting up all the appropriate content types, document sets, configuration and permissions.  So we planned to move this structure and workflow into the destination environment as is.  However, we still had the current and projected quantities of data to deal with.

So, we worked with the client IT team to establish some new processes for dealing with current and projected quantities of data.  When you are dealing with this much data, and rapid data growth from 200GB to 2TB, managing data must become an active task for the IT team and not simply a response once data limits have been exceeded.  The following are some highlights from the plan we established with the client’s IT team:

Due to the current site collection size, we determined that the current 1 site collection would be split into 2 site collections in the destination, with projects remaining in their existing libraries.  We chose a set of libraries that would be migrated from the source to each site collection such that we had roughly an equal number of libraries in each and an equal amount of data in each (these numbers could not be exactly equal but we worked to evenly distribute the data as much as possible).  Our migration plan actually itemized the names of each library and which site collection it would be migrated to.

We determined that each site collection would be stored in a separate content DB so data growth could be controlled and monitored discretely.

We configured site quotas in the destination environment on these site collections to send email alerts to the IT team when a site collection reached a particular threshold, which we set to 150 GB.   The SharePoint content DB threshold is 200GB as mentioned above, but the IT team wanted some advance warning when a site collection was approaching this limit so that they could work with the business group to avoid exceeding the 200GB threshold for any site collection.  Specifically, we had to deal with situations where a site collection might be at 190GB and the business group was still adding 20GB more for a particular project – remember we did not want a project split across 2 libraries (especially across 2 different site collections) and we didn’t want any site collection to exceed 200 GB.

We also established a very well defined and documented process for the IT team to create a new site collection for the business group whenever the current site collection reached our threshold.  There are specific steps we identified that they needed to perform in order to keep things simple and transparent for the business group.  

So, with these procedures in place, the plan was to allow the business group to add new project libraries and content to a ‘latest’ site collection.  As that site collection grew to approach the size threshold, the IT team would create a new site collection.  This new site collection would then become the ‘latest’ site collection.  One important step is that once the new site collection is created, a string within our business department’s home page (see ‘project page’ below) is updated with the URL of this new site collection.  We then needed to work with the business group to establish a process and some UX so that they didn’t need to care about which site collection they were working with.  We wanted business users to simply focus on their projects and content, and let the IT team worry about how and where that data was stored – we wanted them to click a single link on the main home page for the department which would take them to the “latest” site collection to add new projects or more content..

Working with the business group, we established a process and an easy to use UX so that they could focus on their projects and content, instead of having to worry about where they would store data.  The following are some highlights from the plan we established with the business team:

In terms of UX, we created a new site page– call it the “project page”.  It was configured with some web parts which listed names and links to all the project libraries on a single site page, categorized by year.  The project page was hosted in our 1st site collection in the destination environment (remember our large source site collection was split in 2 as part of the migration).  Any link in the environment that took business users to this departmental site collection was configured to take users to the “project page” because this was their jumping off point to get to any project library.

All project libraries listed in the project page were configured as links to take users to the appropriate project library, regardless of which site collection it was stored within.  All site collections related to this department were configured with a link to take the user “Home” which was back to the “project page”.  So, when navigating SharePoint to access content for a particular project or trying to find a project within which to store new documents, business users didn’t need to care about which site collection a project library was stored within.  They simply went to their department’s project page and clicked the link for the library they were interested in, or clicked Home in order to return to their project page.

Now – what happens when a new project needs to be added?  Remember we mentioned a workflow earlier that allowed business users to easily add new project libraries while automatically configuring required content types, permissions, etc.  We modified this workflow to also do the following:

Get the value of the string mentioned earlier, which is located on our ‘project page”.  This string contained the URL to the ‘latest’ site collection created by the IT department.  Remember, the IT team has a step to update this string with the URL of the “latest” site collection they’ve created.

Create the new project library within this ‘latest’ site collection.

Add a new entry to our “project page”, with the project name and the appropriate link to the project library.  This link will of course point to where the project library that was just created, which is within the “latest” site collection.  

Once again, business users do not need to worry about which site collection they store their data within.  They simply focus on their projects and their content.  As well, IT teams can be alerted as site collections approach their content DB site threshold and proactively work with the business team to manage large amounts of data within SharePoint.  This was a fairly simple solution to the need however it did require careful planning with both the business group and IT, the configuration of some new components and establishing some new processes.  

An important point through all of this is that the need to address this requirement came out of a pre-migration analysis that started with some critical high level topics and quickly moved to discussing and working through technical details dealing with how business users are working with large amounts of data today, and how they will work with it in the future.  Once again, the goal of a pre-migration analysis is to remove any uncertainties for when the migration actually takes place.  This particular business challenge is one that we very much want to plan for up front, as opposed to finding out about after the migration to the new environment is complete.  Hopefully these types of discussion and planning sessions will help you deal with that bear in the woods.  

Need help planning your SharePoint Migration or Upgrade? Take a look at our SharePoint Pre-Migration Assessment​ offering.

Quick Launch


© Protiviti 2019. All rights reserved.   |   Privacy Policy