Showing results for 
Show  only  | Search instead for 
Did you mean: 

Merging 2 environments.


Merging 2 environments.



I would like to merge 2 evironments (they have the same level of version and patches), Is there a good way to do this ?


Many thanks

Tags (2)
2 Replies

Re: Merging 2 environments.

Hello hrapin


There is not administration feature for this.

You need to merge environments manually two by two (source and target). .



  • Use the logical backup feature to capture systemdb repository customizations to a .MGR file.
  • Use one file with both metamodel extensions and technical data extensions (no data)
  • Test a merge procedure that consists in importing various files/languages and compile
    When the procedure is correction, run this merge procedure in production

Common rejects causes:

  • Certain languages are missing in the target environment
  • Certain repositories are missing (check idabs, not names) in the target environment
  • Certain users are missing (check idabs, not names) in the target environment
  • Customization of the source environment are imported though several files (usually one with metamodel and one with technical data):
    It is recommended to use one file with both metamodel extensions and technical data extensions

Re: Merging 2 environments.

I aggree with Jérôme, but I'd like to add comments regarding this subject with respect to an RDBMS deployment.


I have an environment whose data is stored in RDBMS (SQL in this case) with multiple working databases. I duplicated the environment and this copy became the production environment. The production environment evolved: system repository evolutions, addition of a new repository, and removal of certain repositories. The original environment has not evolved. Now I seek to merge the two environments, keeping the system repository of the newer environment, conserving all of the working repositories of both environments. What is the best method?

As we are not in a context of flat GBMS standard MEGA files, simple referencing changes or file copies are not possible. As the new system repository contains all of the elements of the older system repository there is no need for a merge via exports and imports or logical saves. Those actions can be risky with regards to the perimeter of the export/save, the cleanliness of the resulting system repository, and the behavior of the customizations. The ideal approach in this case is to create a new environment and use the “restore” function to point to an existing database for the system repository. Then create a new repository for each working repository to recover and use the “restore” function to point to the existing database for these working repositories. As there are naming rules between the environment and repositories in the MEGA Administration tool and the databases as they are stored, one must be vigilant regarding the names on both sides such that the necessary elements are identifiable. If there is a case of a working repository having the same name in two locations, a logical save of one, the creation of a new repository with a unique name and the import of the logical save, allow having a clean new structure.

It is preferable to perform these operations on a test platform to validate the process and its result. In order to do so, request from a DBA the copy of the databases. It goes without saying that all concerned data be in the same application version.