I'm currently working on an upgrade from Tridion 2013 SP1 to SDL Web 8.5.

As part of the upgrade, we're implementing publishing using Topology Manager.

I'm in the process of defining the Topology Manager configuration. This includes details for Business Process Types, Target Types, Topologies, etc.

As well as ensuring that this works in each of the DTAP environments, I also want to make sure that future database restores back through environments are as straightforward as possible.

The client has a lot of published content. Therefore, in the past, we have backed-up and restored the Broker databases (which contain all of the content) as well as the Content Manager database and this has worked fine.

Similarly, in the new system, we'd like to avoid having to republish all of the content again following a database refresh as this could take days.

As with Tridion 2013 SP1, it appears that the details of which items are published where are stored in the PUBLISH_STATES table within the Content Manager database, with references to the items (Pages, etc.), along with the Target Type that they're published to.

Screenshot of the PUBLISH_STATES table

However, it appears that in SDL Web 8, there is now a reference from the Target Type to the Publication's Business Process Type...

Screenshot of the TARGET_TYPE table

... which in turn references the Topology Type (which is defined within Topology Manager, rather than the Content Manager database).

Screenshot of the ORGANIZATIONAL_ITEMS table

Given that this reference to the Topology Type is stored within the Content Manager database and will come back as part of the database restore, my thinking is that keeping the name of the Topology Type (along with the Purposes) consistent across all environments will ensure that this publishing status is correct back in the earlier environments. Q1. Is this a correct assumption?

Also, Production, Acceptance and Test all have Staging and Live Purposes. However, Development only has Staging. Presumably, we can just run the normal database script (with permission from Support) to prevent items from showing as published to 'Live' in the Development environment. Q2. Is that still a valid approach in Web 8.5?

Q3. Is there anything further I need to consider?

Update (3rd July 2017): With regards to my third question (anything further to consider), it may be worth mentioning that I also need to consider the Publication to Web Application Mappings within Topology Manager, to double-check that these are still correct following the database restore. There are a small number of new Publications making their way through environments, so these will need to be recreated and their Mappings recreated. I will also need to delete the old mappings before doing the database restore.

  • 1
    Presumably you could just decommission the Live target. Alternatively, do the right thing and set up Live in development. Commented Jun 30, 2017 at 7:01
  • Good point on the target decommissioning, Dominic. It hadn't crossed my mind - I must have been obsessing about databases too much! :) Thanks. Commented Jun 30, 2017 at 7:27

1 Answer 1


A1. Indeed, to support porting/restoring the CM DB as a whole across DTAP environments, you should ensure that each environment has the same set of Topology Types (IDs) defined.

You don't need to have actual Topologies of all those Types in each environment (e.g. you may not have a Staging/Live Topology in Dev). In this case, you may want to switch the Business Process Type used in your Publications after porting.

For example, you only have a Staging env. in Development and Staging and Live in Production. It makes sense to use a "Development" (Staging only) BPT in Development and a "Staging/Live" BPT in Production.

After you ported your Production CM DB to Development, your Publications will be using the "Staging/Live" BPT. This should work in Development too, but publishing to "Live" will never resolve anything (because you don't have a "Live" environment in Development). You may want to switch your Publications on Development to the "Development" BPT, but that means you should have that BPT defined in Production too (unless you want to add the BPT each time after porting the CM DB).

A2. As Dominic mentioned, please use the decommissioning functionality in the public API instead of DB-level operations.

  • Thanks Rick. That is exactly what I was hoping to hear! :) Commented Jul 3, 2017 at 7:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.