Upgrade / migration / site -> site collection question in Sharepoint 2010 and Sharepoint 2016

Question

Hoping for some thoughts / guidance on the approach for this. I'm in the middle of a project to upgrade / migrate a SP2010 environment to SP2016. Due to the gaps in versions, the approach we're taking is to provision a SP2016 environment, create the required topology and then use a migration tool (most likely Sharegate) to actually migrate the content from the old environment to the new environment.

The existing usage is fairly simple (there's not much in the way of customisation) but the volume data is not trivial - it's at least a few hundred gb, currently all in a single content database. Due to this, as part of the migration it makes sense to reorganise a bit and ensure e.g., site collections have their own database.

Anyway, the question / guidance: there is a subsite of the root site collection which has a lot of content and this is one that I would like to move to its own site collection so its data can go in to separate content database. The issue though is that the URLs will need to remain the same post-migration because it's linked to from another system.

I'll try to illustrate! At the moment there is a SP2010 Server, which we'll call SP2010SERVER. There is a CNAME in DNS that points to (with AAM configured AFAIK) of e.g., SHAREPOINT. So at the moment you can browse the content in SP2010SERVER using the DNS name of SHAREPOINT. There is a subsite, which we'll call SUBSITE1, and the urls to it are e.g., http://sharepoint/subsite1. (Note: there are lots of other subsites and site collections with managed paths etc.)

We have the new SP2016 server; which let's say is called SP2016SERVER. When complete, the idea is to switch the DNS record so that SHAREPOINT now points at SP2016SERVER.

I need to move the current SUBSITE1 to its own site collection in the new environment whilst retaining the URL of http://sharepoint/subsite1. Migrating the content to the root site of a new site collection is fairly trivial I think but the question is how to retain the URL. I can't use a managed path (afaik) because if I configured e.g., 'subsite1' as a managed path, it would still need a site collection name after the path.

I've been looking at host-name(d) site collections as a possible solution. I think in this case you can moreorless specify any URL for the site collection, but I've not used them before and all the examples I've seen tend to use a sort of subdomain.domain.tld. type setup.

Would this work for my needs? And if not, are there any alternative solutions or options for this?

I imagine I could achieve the same with some sort of IIS magic / redirection etc. but was hoping to avoid this if possible.

Thanks for any thoughts / help!

Answer 1

You describe the migration of data from the subsite to site collection as being trivial, but typically this type of change is Not trivial -- unless you are using some sort of migration tool such as ShareGate -- but if you are planning to use built-in export/import or backup/restore, you are probably not going to be able to move a subsite to a top-level site collection.

As far as keeping your path, when you create a managed path, you have the choice of making it a Wildcard inclusion or Explicit inclusion.

Wildcard inclusion is what you seem to be thinking of, where there is no site living at the root of the path, but you can create any number of site collections whose path start under that managed path. For example, if you create a wildcard inclusion managed path /pathA/, then there would be no site at http://sharepoint/pathA/, but could potentially be site collections create with urls of http://sharepoint/pathA/site1 and/or http://sharepoint/pathA/site2.

But choosing the Explicit inclusion option is exactly the opposite, allowing a maximum of one site collection to created whose path is directly under the managed path. Thus if you create /subsite1 as an Explicit inclusion managed path, then you can create exactly one site collection with the path http://sharepoint/subsite1. You can, of course, always created subsites within that site collection, but no other site collection can use that managed path.

In terms of having that site collection have a different base url than the "root" site collection, you have a few choices:

1. The host-named option requires PowerShell, since these options are not in the central admin user interface, but there are cmdlets to create a host-named site collection (that essentially uses IIS host headers behind the scenes, although this step seems to sometimes randomly get skipped, so check in IIS, and add the host header binding if it is not already there after you run the powershell script) at the root of your new url domain (i.e. New-SPSite 'http://sharepoint' -HostHeaderWebApplication (Get-SPWebApplication 'http://sp2016server')), and then you have to create a host-name managed path through powershell (i.e. New-SPManagedPath 'subsite1' -HostHeader -Explicit) if you want to have an explicit managed path available, then finally, you would create another host-named site collection that makes use of the host-named managed path (i.e. New-SPSite 'http://sharepoint/subsite1' -HostHeaderWebApplication (Get-SPWebApplication 'http://sp2016server')).
2. You can create a new webapp in central admin that responds to the new url, and your new managed path and site collection are created within this webapp. This is probably the easiest of the listed choices -- but, if there are not going to be any other site collections using this base url, this is probably way overkill.
3. The third option is to create an alternate access mapping that allows your single webapp to be access via two or more base url domains. The downsides to that, based on your question, is that your root site would effectively be accessible by both http://sharepoint and http://sp2016server, and then once you create your explicit managed path and associated site collection, it would be accessible from both http://sharepoint/subsite1 and http://sp2016server/subsite1.