Moving components to child publication

Question

Similar this question but in reverse - we've identified some Blueprint optimisations that mean we need to move components from a parent down to a child.

• The folder structure should remain the same.
• These components are in use on pages lower in the Blueprint.

Copy/paste works, but it only creates new components in the child publication - the pages still point to the parent ones.

Using Content Porter and mappings also seems to mean a multi-step process of exporting components and pages etc.

I know this is unsupported but digging around the CM DB in the ITEMS table I can see a PUBLICATION_ID - updating this to the ID of my new child publication would seem to give me what I want - the component in the right place but the reference on the page maintained.

I know the Core Service is probably the supported route but for the sake of one field in the db I'd have to write/test/deploy code to do this.

• Anyone done this before?
• Would SDL Support provide a script to do this that I could just feed component Ids to?

UPDATE

Looks like the compound key reference to ITEM_REFERENCE_PUBLICATIONS stops any update to the field in ITEMS.

Answer 1

Moving items across Publications will always require you to write some code, as you noticed you can use copy/paste only inside a Publication and not across Publications.

So you will have to create a new item (as a copy of the original) and update all the links from the original to the new item.

There are no ready made database script to perform these kind of actions that Customer Support will hand out to you, on special occasions it could be that a SDL Consultant performs these kind of actions for you, but that will have to be discussed on a case by case basis (since these kind of database scripts can have a huge impact and corrupt your data).

In most cases I found that a database script might seem the most logical way forward, but it is nothing that can't be done by a tool or manual action (provided you create new items and update all references). The latter is of course a much saver way and having worked with the database scripts myself, I do prefer the API route (so you don't have to test the whole system for possibly corrupt items afterwards).

Answer 2

+1 to Bart's answer though I'd suggest a DB script is akin to setting up a perfect content port without a "go back" option because of checked-in status, dependencies, and localization across the BluePrint.

The logic should be clear but with some subtle gotchas. For items in a given folder:

1. Check-in (or ignore) checked-out items
2. Copy item to a "temporary" folder (assuming you want to shared item, regardless if its a localized version of the original item)
3. Update references for each item that uses the original item to the copy, accounting for:
   • Checked-in status (like above)
   • BluePrinting preference (probably updating a parent if it exists if not localized)
4. If preferred, delete the old item, applying the above but in reverse as needed (remove references, unlocalize, and possibly unpublish)

You'll probably want to note any issues or skipped items. If you can account for these scenarios, then a DB script might make sense, but I'd prefer a little help from the CME or API to avoid the corrupt items Bart mentions.

I describe similar considerations for the opposite scenario of moving items up a BluePrint--mainly you have to confirm distance/direction, dependencies, and directories.