0

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!

  • Are you saying that the new root will be at http://sp2016server, but the (former) subsite will need to be http://sharepoint/subsite1? So, not only do you need to keep the path, but you also need its dns to be different than the root? This is all possible, just want to make sure I am understanding before answering. – willman Jan 17 at 17:05
  • The new server / host will be http://sp2016server but will redirect the existing DNS CNAME to point to it, so that bit is OK, I think. But where in the old environment http://sharepoint/subsite1 was a subweb of the rootweb of the root site collection, in the new environment I need subsite1 in http://sharepoint/subsite1 to be a site collection. – Matt Jan 18 at 13:35
  • Okay, so you can ignore the last third or so of the answer below about having the two site collections having different base urls. You really just need to read about the Explicit managed path. – willman Jan 18 at 14:50
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.
| improve this answer | |
  • Thanks, need to fully digest your answer but as for the migration I am currently planning to use Sharegate. – Matt Jan 18 at 13:36
  • Okay, then yes, then migrating your subsite's content to a top level site collection is not much different than migrating to another subsite. So your only real challenge is getting your new site collections set up correctly before you migrate. Hope the rest of my answer helps with that. – willman Jan 18 at 14:47
  • So, based on your response comment up on the question, there is way more here in my answer than you need. You need to create your root site collection in the new farm, but don't migrate yet. Then set up an Explicit managed path named subsite1, then create a new site collection that uses that path. Then you can migrate root site content to root site content, then subsite content to the new managed path site collection. – willman Jan 18 at 15:04
  • Looks like the explicit managed path is exactly what I need! Will experiment, but many thanks. As you imply, I must have always just used the wildcard inclusion and not paid enough attention to the difference. – Matt Jan 18 at 17:34
  • Explicit managed path was perfect. – Matt Jan 21 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.