Recently I led a team from Perficient to upgrade our existing SharePoint 2010 intranet (The Hub) to SharePoint 2013. That process involved months of planning culminating in a solid week of fretting as the migration took place over several days. Since everyone on the team is involved with client work, we couldn’t in good conscience make our clients take a back seat while we worked on internal systems. This meant lots of nights and weekend work and I want to thank my entire team for their help.
This will be the first in a multi-part series describing how Perficient migrated from a relatively small SharePoint 2010 intranet (~20GB) to a flourishing SharePoint 2013 intranet (~300GB) over the course of a few months. Let me briefly describe the 2010 Hub so you get a feel with where we started.
Starting Point
The Hub was created by the former PointBridge team in May of 2012 for our annual sales conference to provide a social and collaboration space to replace the legacy systems that PointBridge had. It included NewsGator for Social Sites and a tile-based customizable homepage dubbed the Information Workspace. We also customized the master page to provide a more "modern" look and feel. These customizations were used in around 20 NewsGator communities covering topics like Mobile, Office 365, and Sales Enablement.
The upgrade was focused on several things: remapping the information architecture that had grown organically resulting in poor maintainability (even the experts can rethink things), removing the NewsGator components and other customizations to focus on out-of-the-box functionality initially, and rebuilding the Information Workspace as an App for SharePoint. A point I want to make clear: we removed NewsGator to understand the out-of-the-box social capabilities that SharePoint 2013 provides in comparison to NewsGator. This first post is about the Information Architecture remapping that we did.
Information Architecture Remapping
Perficient’s SharePoint intranet is focused on topical communities, business units, and internal team collaboration (mostly sales and pre-sales). This resulted in a single "communities" site collection at a managed path, a business units site collection at a managed path, and a "communities" sub-site off the root. The downside of using a single site collection for broad areas and subsites for the categories are primarily permissions management and database segmentation. Moving to a situation where you have numerous site collections and a managed path for broad categories solves these issues, but the movement presents challenges as well.
Permissions Management
In SharePoint, permissions can be applied at the web application, site collection, site, list, folder, and item levels. So when you access anything in SharePoint, the security is validated at all of these levels if there is custom security applied. Clearly, the more levels you have, the slower this operation becomes. So we wanted to avoid having unnecessary levels. In addition, as you add disinherited permissions levels, you get more and more permissions groups, which only serves to exacerbate the problem. Perficient’s new environment replaces the site collections with managed paths allowing us to take advantage of the next item: database segmentation.
Database Segmentation
At the content database level, site collections cannot cross database boundaries, nor can anything within them. So having a bunch of site collections allows us to take advantage of multiple content databases and keep per-database size to a minimum. This is good for multiple reasons:
- Smaller databases means less to restore in the event of an individual failure
- The ability to span multiple drives on your SQL server and therefore multiple LUNs in the SAN
- Backups can be more easily spread across multiple sources
We envisioned the usage of the Hub taking off as we gained momentum and excited people with the new SharePoint 2013 capabilities. This made is very likely that we would have a lot of content which would lend towards very large databases in the old model.
Promoting Sites to Site Collections
However, promoting a site to a site collection is not as easy as moving a site collection from one URL to another. The promotion process involves exporting a site and importing back as the root site in a site collection. This was further complicated by the use of the NewsGator communities site template, which would not exist in the new environment. Also, by moving subsites to root sites in a site collection, you run the risk of security snafus.
To resolve these issues, we leveraged a temporary SharePoint 2013 farm to export the sites from one web application into root sites on another web application. In the case of NewsGator communities, we exported each list individually and rebuilt the sites as SharePoint 2013 communities bringing the security with each list. Once the sites were imported into the new web application, we converted the security from what it was in the initial site to a site collection model with viewers, editors, moderators, and owners.
After security was complete, we could detach the content database from the temporary farm and attach it to the production farm and be ready to go.
