4

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?

  • 2
    If the separation is only notional (i.e. not a full company separation/sale) this seems like an expensive solution to a permissions problem especially given no content is shared? – Dave Forber Dec 1 '17 at 11:19
  • +1 Dave. And publishing from two CMs to a single CD will cause problems later on. – Nuno Linhares Dec 1 '17 at 13:54
4

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.

| improve this 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

| improve this answer | |

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.