Move content from one DB to another DB

Hello David,

it really depends on your requirements for the governance of your content. For simple requirements, where the built-in governance workflows might be sufficient, you could do it with just one DB. Model content that hasn't gone through the approval process is not part of a change list. If you set your publication to "Last version" the latest work of your Designer users is not visible in the portal until it has been approved and hence become part of a new version.

If you want to implement peer review by people who are not equipped with a Designer licence this is an indication you have to go for a concept with a second database.

Export/Import is possible between DBs. It can be done manually by people with a certain privilege on the database, but if you want to do this regularly I would advise to automate that with a script - possibly executed in the context of your (custom) governance workflow. There are quite a few considerations and decisions you have to take during such an Inter-database-merge and if you are not consistent here (human factor) you may cause a mess.

Thanks for your answer ! 

Hello David,

if you are going for two DBs the topic to look for should be merging, not export/import. This gives you more control about update cycles from DEV to PROD.

You would need ARIS Architect to access two DBs simultaneously and the Database export privilege for both the source and the target database.

APG Governance workflows (as opposed to the Connect "Mini" workflow "approve content") work with merge and have the necessary scripts (services) already included (DB Governance Automation Models).

Regards, Martin

Thanks Martin for your answer. 

I do have Architect Licence, but what concerns me on the Merge process is that PROD DB might not be really updated with changes made in DEV as it will "merge" all changes not just update it ... I shall give a try though and see if that works. Thanks.

Hello David,

the only difference between Export/Import and Merge is, that with Export/Import you get an XML file that you have to store somewhere before you import it to the target database. This poses the risk of importing multiple XML files in the wrong order, so you could overwrite younger content with older stuff. A merge is always instantaneous.

Indeed the tricky part both with merge and export is selecting the correct scope you want to merge. There are various options to choose from, which you have to understand thoroughly before merging/importing to your production DB. Otherwise you might not get the result you want to achieve. Also on the import side you have to decide whether you want to overwrite the attributes in the target or just merge what is missing. There are various options for conflict resolution.

...that PROD DB might not be really updated with changes made in DEV as it will "merge" all changes not just update it.

Hello David,

if your merge strategy is "DEV overwrites PROD", you can do so very easily. Just check the necessary settings in Architect's Merge Dialog.

Also it would make sense to let your users have only read access to your PROD db, if your data flow should only go from DEV to PROD.

Regards, Martin

Thanks Martin, I will go with the Merge option as you recommend. Thanks!