How to import an export package from another Gentics CMS installation.

1 Introduction

The import allows you to import implementations with tag types, pages, templates etc. to a Gentics CMS system, that have been exported on another Gentics CMS system previously.

2 Create a new import

You can find the menu item Import and Export in Gentics CMS in the Administration tree.

You have two options to start a new import: You either use a download URL including a password (from another Gentics CMS system), or you can also upload a previously created export file as a zip archive to the server. If you choose the download URL you will also have the possibility to search for newer versions of this export in the future. If you decide to use the file upload you can update the import by just uploading a new version of the export file. Changing the filesize limit is described here.

The download URL also has the advantage that the export/import data will be directly transferred from server to server, which is allot faster when your client (browser) is connected with a slow network connection.

Additionally, you can also run the import with the permissions of another Gentics CMS group. In order to do this you have to enable the checkbox “Execute import using another usergroup” and select a group from the “Select group” dropdown menu.

If no special group is selected, the import will be run with the permissions of the groups the current user is in.

3 Content of the import and target folder

After setting the import file and clicking on Next you will get detailled information about the import file.

Choose a target folder to which the contents should be imported. Please consider that you also have to select a target folder for imports that on the first sight of view don’t require one. This is required because there might be objects for which no target folder was exported, but they need one. In the previously given example, this would be an image that is used by a page in the exported node, but the image itself was saved in a node that is not part of the export.

4 Test run with conflict detection

Before the actual import, there will always run a test run of the import that will detect possible conflicts. During this test run no data will be changed. If the test run won’t detect any conflicts, the status will change to Test successful and the actual import can be started.

It’s possible that conflicts with existing local objects can occur. In this case, please click on the text conflicts found during tests, to display them, resolve them and finish the import.

5 Resolving conflicts

The following image contains a list of objects, that cause a conflict during the import. This can have several reasons. One possible reason would be that an object was modified locally. Another possible reason would be that objects that will be deleted by the import are still referenced by other objects locally.

You can set the desired behavior for objects with conflicts.

  • Ignore: Objects with conflicts will not be imported. The local version will not be touched.
  • Replace: Local objects will be replaced by the object in the import file.
  • Create new: The local version will not be touched and a new object will be created from the import. Warning: Objects that do not cause a conflict will be linked to the copied object with this behavior. Should there for example be a conflict with a tag type, all instances/occurrences of it (e.g.: page tags) will be linked to the newly created tag type.

The conflict behavior can be set globally in the import with the radio buttons or can be defined for single objects in the list below.

There is also a possibility that conflicts occur, that can’t be resolved in the scope of the normal conflict behavior. Reasons for not resolvable conflicts can be missing permissions (if the import group doesn’t have all required permissions on the import system) or objects that have been excluded in the export on the source system, but are necessary for imported objects to function correctly (e.g. templates, tag types, …).

6 Final examination and running the import

After you have chosen a conflict behavior for the different objects, you get to a final Summary and confirmation dialog of the objects that will be added.

Please note that objects, that are deleted out of an existing export on the source Gentics CMS system, will also be deleted on the target import system, when the previous export has already been imported on the target system and when it is an update of an existing import. This will appear as conflict in the list like in the previous image.

The import can be started with a click on the button “Start import in background”. The view will change to the list of imports and will show the progress of the current import. By clicking on “Cancel” you can abort the currently running import.

When the import finished successfully, it will be shown in the status column.

7 What the import will (and will not) do

  • The import will act as normal user (the user performing the import).
    • If objects are created through an import, the user performing the import will be stored as creator, the time of the import will be the creation time of the object.
    • If objects are modified through an import, the user performing the import will be stored as editor, the time of the import will be the edit time of the object.
    • If pages are modified through an import, a new version (with user and time of the import) will be created.
    • If pages are published through an import, the user performing the import will be stored as publisher, the time of the import will be the publish time of the page.
  • User information is not synchronized between systems and will not be exported or imported.
  • Page versions will not be exported and imported. Importing a page will create a new version on the target system.
  • When template tags, that are editable in pages are changed though an import (e.g. the used tagtype is changed), all pages using that template will be modified during the import.
  • The connection data of imported content repositories will not be imported to prevent the target system to unintenionally publish into the same content repository database as the source system.
  • New imported nodes will have updates of Contentmap/Filesystem disabled by default.

Extra care must be taken with pages, which are published or planned and then modified. Since the export only contains the modified version of the page, which must not be published, the imported page will not be (re)published.


When a page is created, published and then modified on the source system, it will have the following versions:

  • Version 0.1 (Initial Version)
  • Version 1.0 (Published Version)
  • Version 1.1 (Modified Version)

When the page is exported, the export will contain the contents of Version 1.1.

When the page is imported on a target system as new page, it will not be online, and will have the following versions:

  • Version 0.1 (Imported Version)