Only CMS content to be moved to new CMS installation, Content Delivery remains same

Question

Due to recent LOB (Line of Business) separation we need to move the CMS content of particular LOB to all new CMS installation. Additional details are below:

1. Current CMS is holding content for 3 to 4 websites.
2. Websites Pages are created in their dedicated Publication.
3. Content is also created in dedicated website Publication.
4. Schema/Template (design) is shared across different websites.
5. All website are running on individual servers. e.g. Australia site on Australia based server, Canada site on Canada based server, so no migration required on Delivery server (Upload and Delivery)

We need guidance on taking correct approach. The approaches we are thinking about are:

• CMS database copy: This approach is comparatively easy, but It will copy the Content, Users, Custom Pages of other websites as well.

After DB copy I think we will not be able to delete the unwanted Pages as they will have status as published.

• Content Port: As we are not moving Content Delivery we may have to publish all Pages, and for each item we may have multiple entries in DB (as TCM will be changed), this may break working website as well. So we think this is not an approach.

So in DB copy how can we ignore other LOB/Websites content?

Answer 1

So in DB copy how can we ignore other LOB/Websites content?

If the split is by Publications meant for different CMS instances, you could try to ignore the other content. But @Nuno hints at, as each CMS adds new Publications and items with possibly overlapping identifiers, you'll easily run into conflicts.

The supported way to remove content is to unpublish. The cleanest, and least risky way is probably to make the split and publish the desired content from each new CMS. At some point someone needs to decide which set of items go to which CMS.

Since you'd need to split across development, test, acceptance, and production (DTAP), consider starting a split or even a merge in a (ideally separate) development environment.

This could be the following steps:

1. Save your work. Back up your databases and start with a replication of Production.
2. Identify the split in the CM. Organize or identify pages and content meant for one of the new CMS. This could be through Bundles, Folders, Metadata, spreadsheets, scripts, etc.
3. Identify publishing differences. Also track the current/desired published state of items.
4. Split. Introduce a new BluePrinting branch (new child Publications where you will "split" content, design, and/or functionality)
5. Optionally copy content and/or pages meant to be separated and rewire pages to use cloned content. This is a bit of work, though.

With the split identified, start one or two new DTAP "streets" to continue the projects, decommissioning and removing old Publications from the new instances.

+1 to @David's point on this being an expensive exercise. I'd definitely consider sharing people, infrastructure, DTAP processes, and CM development if possible.

Otherwise, I'd recommend a bit at a time working with the business(es) to make sure the final setup works with them as well as IT.

Answer 2

While it might indeed be easiest to solve this using permissions, there may indeed be other reasons to separate the CMSes. The problem is indeed the publishing bit. Copying the DB will also copy all publish states, so you have a problem deleting unneeded items. Content-porting won't move the publish states, so you would need to make sure to republish all content ported items again.

If you are using Tridion 2013 SP1 or later, there is a functionality called "decommission publication target" (also explained here : http://www.tridiondeveloper.com/decommission-a-publication-target). That would allow you to set the publish state of all items published to a certain target to 'unpublished', which would allow you to delete the target and all items.

Note that the decommission publication target functionality doesn't actually unpublish anything, it just sets the publish states in the CMS