Compared to moving content items, moving sites is a very different story. In short, you do not move any content items, but just change the master-links of the content items within the site.

Special Role — The Site Indicator: Even more, strictly speaking, moving a site in the hierarchy is just about changing the master-links of the site indicator documents. Just doing this, though, would break with the multi-site concept and cause subsequent issues in normal editorial work. That is why in the end, all master-links in a site must be aligned with the site-indicator, thus, represent the same master-derived relationship.

Still, having this distinction between the site indicator, and the other content items is important when it comes to the order of when to apply master-link changes. The general advice is that it is always the site indicator, which is the last document in a given site where a master-link is adapted.

Challenge: Missing Links — Gaps in Content's Master Links

It is perfectly valid, if some documents do not have a master link in derived sites, which is, when there is no counterpart in the master site.

The challenge is best described by example: Assume that you start your transformation process with two documents "Easter Campaign" in the sibling sites en-GB and en-FR, that are not represented in the current root-master site en-IE.

Challenge I: The API, for example in SitesService that you will use during the transformation process will not be able to identify these as variants of each other. Thus, you need some good guess (like by "same name" assumption) to identify these.

Challenge II: For frictionless editorial work after the transformation, you will want to add a master-derived relationship between these two documents at the end of the transformation process.

A possible option to take is described in next section, where we repair the gap of a specific document before the transformation starts: en-IE: Create Translation Settings .