Collapsing Multiple SharePoint 2010 Web applications into a single SharePoint 2013 Web application using Host-Named Site Collections

At a client site, I was tasked to migrate a SharePoint 2010 farm from antiquated physical hardware to a new SharePoint 2013 farm in a virtual environment.  In the existing SharePoint 2010 farm, there are several web applications separating different projects.  This was done to isolate them from each other and provide more granular security.  As we should all know by now, Microsoft's best practices within SharePoint 2013  is to use less web applications (limit of 20 web applications per farm) and implement host-named site collections to create multiple "zones" or to use unique URL headers.  Side Note: If you want to learn more about Software boundaries and limits for SharePoint 2013 , visit: http://technet.microsoft.com/en-us/library/cc262787.aspx).

So began my effort to collapse multiple web applications from a SharePoint 2010 farm into a single web application in a new SharePoint 2013 farm.

Step 1: Identify possible duplicate URLs
The first step is to identify all of the sites within an existing web application to see if any of them have identical URL paths.  For instance there may be a site "/sites/sitecollection1" and in both web applications. I like this little PowerShell cmdlt and use it quite frequently to see how our site collections are growing on a monthly/annual basis:

Get-SPWebApplication https://url.domain.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:\filename.csv -NoTypeInformation

Step 2: Create Web Application
The next step is to create a new web application (if one doesn't already exist in the new farm).  Depending on your authentication method, you can either use Central Administration (claims-based) or PowerShell (classic-mode).  In our case, I needed to create the web application in classic mode and then convert it to claims after everything has been moved over.  This was due to the fact that we were using Office Web Apps which requires claims-based authentication.  Here is the cmdlet used to create the web application in classic-mode:



New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

Side Note: For more information about classic-mode authentication, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx

Step 3: Create Empty Root Site Collection
Next, we need to create the top-level site collection.  This is a requirement for any new Web Application.  Also, this will be the only site collection that shows up in the content source.  Even though all other host-named site collections do not appear, by default search will automatically crawl them.


New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 4: Create Host-Named Site Collections

You must use PowerShell to create a host-named site collection, although you can manage it with Central Administration after it has been created.

New-SPSite 'http://portal.domain.com' -HostHeaderWebApplication 'http://<servername>’ -Name 'Portal' -Description 'Customer root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 5: Migrate existing SharePoint 2010 Content Databases to new Host-Named Site Collections
In the interest of staying on topic, I have skipped the steps that include attaching the content database(s), running the pre-upgrade check and testing the spcontent database.  for more information on upgrading SharePoint 2010 databases to 2013, visit this site: http://technet.microsoft.com/en-us/library/cc303436.aspx

Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]

Side Note from Author: Due to an unexpected time crunch, I decided to not collapse the web applications as part of the migration.  I was hoping to be able to provide additional lessons learned and more information from actual experience, but unfortunately this is as far as I got in the production environment.  Regardless, I wanted to document a few of these steps in case we decide to revisit this again in the future or on another contract.