Moving items around within a single Tridion environment

Think back of three key words you extracted out of the first notions you got when learning Tridion. It will not be a wild guess to say one of those key words would likely be 'Blueprinting'.

The Blueprinting hierarchy within Tridion is the skeleton of your implemenation, like the chassis of a car. Building a robust chassis will help the car when facing bumps in the road ;)

But the question now is... how to proceed when, for any reason which is not so relevant anymore, the initial Blueprinting hierarchy is not strong or extensible enough and you wish to transfer it into a new one that follows known best practices?

I do not have one answer for all the cases, but a lot of them are going to be helped by SDL Content Porter.

I am aware that many people have developed some "allergies" against Content Porter, but we should not underestimate its power for certain things; a good example is its Blueprinting awareness.

In this article, I will give you a couple of tricks and simple steps to follow when restructuring your Blueprinting hierarchy. That is to say, we are porting from and to the same environment, but from and to different Publications within that environment.

In my sample case,  the source hierarchy consisted of three publications:

Publication A: Top parent. Contains Schemas, English content, Taxonomies, Template Building Blocks
Publication B: Child of B. Contains Design elements like css and javascripts, Component and Page Templates, Structure Groups and Pages. Website in English
Publication C: Child of C. Some localised design elements, localised content, localised Structure Groups and Pages (localisation is only needed for one language). Website in Spanish

The destination hierarchy  will consist of a simple diamond structure, together with the Empty Parent, a Spanish translation layer to localise Components and and two Website publications.

The exact relationships in the new hierarchy are not relevant for my explanation. It is more important to share details about the process and settings involved.

• The easiest way to move content into a different Publication is just renaming the destination with the source name. There is no need to complicate your life with mappings if it is not needed.
  Remember to change the publication key at the same time.
• I recommend doing the import process step by step. Here you need to take the dependencies into account for the order of execution:
1. Import Categories on Schema Master
2. Import Schemas on Schema Master
3. Import Components on Content (EN)
4. Import localized version of the content on Translation Spanish
5. Import Template Building Blocks on Design Master
6. Import Templates on Design Master
7. etc
• Content Porter works on webdav url basis. This means that a renamed localized Component could end up being duplicated as if it was a different Component.
  But don't panic! The good thing is that if you use Content Porter well, Content Porter will figure out this relationship and will rename the localized Component accordingly without creating a duplicate. The same worked in my test for keywords.
  To accomplish this, you have to select “Resolve shared items with BluePrint mapping” when doing the import. See online doc here.
• When you are moving content into a hierarchy which does not resemble the source hierarchy, you will likely get an error like “The child publication cannot become a parent” or something similar. 
  When this happens, you can fix it by selecting the option "Selected children only" on the right context menu when clicking on the specific publication in Content Porter (see image below).
  
  

These are my recommendations based on the challenges I encountered during executing my sample case. The import process worked well for me!

Always keep in mind the relevant settings and the order of execution. Also try to avoid bringing dependencies which are not needed at all.

I wish you a happy port! ;)