Large SharePoint 2013 migration, HNSC, change URL after Migration, crawling and DNS
Say you are migrating several terabytes of content from SharePoint 2010 to SharePoint 2013. Chances are that you are creating a temporary migration URL for your 2013 environment where users can test the migration. Further, you migrate content in several stages, probably one business unit at a time, or one web application at a time, so on so forth.
Now once, you move all the content of a business unit or department or project to 2013 and want to keep the same URL as your 2010 environment, what do you do?
Let’s put a concrete example.
- Say your 2010 URL: https://companyA.contoso.com = intended SharePoint 2013 URL.
- You create a 2013 temporary Migration URL: https://companyABeta.contoso.com. This is the URL that you share with the users of the content owners so they can test.
- If you have any web parts that were dependent on search, then the temporary migration URL is the content source for crawl.
Now, once testing is complete and the testers go ahead, then you switch all the users to the 2013 site. To do so you probably,
- · Take an outage for migration.
- · Change the temporary URL to the desired URL, which is the same as your 2010 URL. For example, rename the https://companyABeta.contoso.com to https://company.contoso.com
- · Point DNS to the 2013 production, and users can now access the new site content.
Now the problem is that after you have changed the URL, SharePoint sees a new URL and thought there will be an incremental crawl, it would be like a full crawl. Based on the volume of the content, it could take a while. Search based functionality would not be available till crawl is complete. Also, you will have to do these steps again and again, till you migrated all the business units or departments. Wouldn’t it be nice, if you did not have to re-crawl every time you migrated the content from 2010 to 2013?
Ok Let’s put a concrete example.
Say in SharePoint 2010 you had the following two web applications. You are using attach/detach method, or a tool like AvePoint or Metalogic to move this content.
SharePoint 2010 web applications
- CompanyA.contoso.com
- CompanyB.contoso.com
SharePoint 2013 logical architecture
- One web application with 2 HNSC having the same URL’s; that is,
- CompanyA.contoso.com
- CompanyB.contoso.com
Proposed migration steps.
- Create your web application in SharePoint 2013. https://mylab
- On the default zone create the HNSC collection using the script.
New-SPSite 'https://CompanyA.sp.contoso.com' -HostHeaderWebApplication 'https:// mylab' -Name 'CompanyA portal' -Description 'Portal for CompanyA' -OwnerAlias 'contoso\administrator -language 1033 -Template 'BLANKINTERNET#0'
New-SPSite 'https://CompanyB.sp.contoso.com' -HostHeaderWebApplication 'https:// mylab' -Name 'CompanyB portal' -Description 'Portal for CompanyB' -OwnerAlias 'contoso\administrator -language 1033 -Template 'BLANKINTERNET#0'
NOTE: Do not create a DNS entry for the 2013 environment. If the user types https://CompanyA.sp.contoso.com from their device, they should be navigated to 2010 site, not 2013. Since the HNSC is created in the default zones, search will use this to crawl.
Now, when I migrate the content to 2013, how will users test this content to approve migration?
3) Now, create a separate URL for users to test this site. Use the Internet zone.
Set-SPSiteUrl (Get-SPSite 'https://CompanyB.sp.contoso.com') -Url 'https://CompanyBPublic.sp.contoso.com' -Zone Internet
Set-SPSiteUrl (Get-SPSite 'https://CompanyA.sp.contoso.com') -Url 'https://CompanyAPublic.sp.contoso.com' -Zone Internet
4) Now set up DNS entry or host file to point to the public URL’s so users can test.
5) Now when migration is complete, the internet public URL may be removed, and DNS reset to the final URL to direct users to that URL. As the original URL is maintained, search will not re-crawl the data.
What if you are not using HNSC?
You could do the same as above. The only difference would be how you make the site available for testing while the 2010 site is still live. Instead of using Set-SPSiteUrl to create a test URL, you should temporarily extend the web application and make it available for testing by creating a DNS entry. Once you are done testing, remove the extended application and the DNS.