I have a requirement where i need to do DB restore from one CMS environment to other.

CM DB 1 to CM DB 2 Broker DB 1 to Broker DB 2

CM DB 1 and CM DB 2 are having different tridion users though they have same groups.

I can simply restore the CM DB 1 to CM DB 2 and Broker DB 1 to Broker DB 2 ,but i will loose my Tridion user which are there in CM DB 2. I want to take backup of tridion users from CM DB 2 and after restore i want to put the user back.

Before Restore - I need to do following activities, take backup of tridion user from CM DB 2. After Restore - Delete tridion user from CM DB 2 . Update the tridon user from the above backup taken before restore.

I want to know if it is possible and if it is safe.

4 Answers 4


If you move/copy the database you will move all the users that were part if the original environment.

If you simply want to move all the cms content I'd recommend using content porter to migrate the data rather than hacking away at your database import / export.

For your broker database I'd simply recommend republishing to your new broker database once you've performed your content port / migration.

There's other ways to do it, but this is the safest and supported way.


Moving databases between environments has always been supported. You couldn't run a DTAP street properly without that capability. Mostly, Content Porter is used to move templates and the like forwards towards Production, and database backups/restores are used (less frequently) to bring realistic production data back towards the Development environment. Of course, you get the exact same database, which won't be suitable for your environment, so you'll need to fix some things.

Firstly, to address your question directly: you can add and delete users to/from a newly restored database just as you would with any other Tridion system. When adding users via the GUI you rely on choosing from a list of users in the local domain (or configured LDAP server), but there is no such restriction at an API level. You can use a power tool to add a user from a different domain, but mostly it's more convenient to simply script it. (There's an example of using PowerShell/Core Service to add a group and a user on my blog post about setting rights and permissions)

The first thing you'll need when you restore your database is an administrator account in the domain where your restored system runs. Often this is in a different domain from where the backup was made, so in this case, it makes sense to create the administrator account before you make the backup. You may find it convenient to have administrator accounts for all your environments in your production database. (Some security policies won't allow this, but you may be able to add an account before making the backup and remove it immediately afterwards.)

Another good thing to do before making the backup is to shut down the various Tridion services, or at least the ones which subscribe to queues. These services will unsubscribe themselves as queue consumers on shutdown, which means that your backup won't have queue consumer records relating to the wrong environment. (If this won't work, ask support for a database script that cleans this up in a supported manner.)

As others have noted, you'll also need to deal with publication targets and other things, most of which can be scripted easily enough. The most important of these is that the content manager's view of what is published will be wrong. You'll want to delete published items from your file system, install clean broker databases, and set the publish state in the content manager to unpublished before publishing from your restored system as appropriate. The correct way of doing this differs from one version of Tridion to the next, but in 2013SP1 you can simply decommission the target.

  • An excellent hint about 'creating administrator accounts for all your environments in your production database'. I'd never thought about this before, and always scripted it. Jul 29, 2014 at 4:50

Jitender, As you are already doing un-supported and not-recommended way, you may choose to go further unsupported way - You can write a utility using APIs to retrieve the User Information, save it somewhere and post DB sync, You can use the same utility to import them back.

Alternatively even most Not-Recommended way that you can dig further in the CM database and write SQL scripts to have all the User Information in the form of SQL script which you can run further post DB sync (If you remember we have done so for SDL Tridion 2011 for an earlier project) but the reason was entirely different.

Please note, it is always recommended that you make use of Content Porter as much as possible, but given the pain we all faced while exporting/Importing the Content Porter, it require to go with DB restore but obviously this un-supported method will comes with some downside of penalties in the form of "Everything Sync" which you may not want.


Adding to John's answer:

If you still want to go with DB restore (I know, content could be huge and Content Porter doesn't work ideally many times), here is short little blog for it. But you have to manage users by yourself, there is no safe way to restore useres AFAIK :)


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.