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.