Importing content from a staging server

Whether you are preparing your staging server for first use or subsequently moving new content from your staging server to your production server, the export and import process is the same. A general rule of thumb to speed up the process is that you can export and import entire folders or nodes in a tree hierarchy of objects to process all descendant objects at once. When you import an XML file containing multiple objects, you can specify exactly which of them to import (except for tags, which are a special case).

Warning! To ensure that dependencies between objects are always maintained, you must import objects in a specific order as described in the following steps.

1. Export your entire tag hierarchy and import it to the target server:
   1. From the Staff site, go to RiSE > Tagging > Tags.
   2. Select the root Tags object in the tag hierarchy, then from the toolbar, click Export.
   3. When the export begins, you are asked by Windows where to save the exported XML file on your local computer. At this point you can rename the XML file if you prefer to give it a more meaningful name.
   4. In a browser window connected to iMIS of the target server, select the root Tags object in the tag hierarchy, then from the toolbar choose Import. A window is displayed that enables you to browse for the location of the XML file on your local computer.
   5. Click Browse to select the XML file, then click Upload to begin the import process. Unlike when importing other types of objects, you are not asked which tags you'd like to import. Instead, the entire tag hierarchy of the target server is overwritten by the tag hierarchy contained in the XML file.

2. In a browser window connected to iMIS of your source server, ensure that all the objects you plan to export are in a Published state. Objects that are still in a working state will not be included in the XML file created by the Export command. If you are preparing a staging server for first-time use, you must ensure that all RiSE definition objects on the production server are in a published state, because you must export all of them.

3. For each type of definition object, select the objects that you want to export and create an exported XML file:
   • It can be helpful to export objects in the following order, to help you remember to import them to the target server in the same order:
     1. Content types
     2. Tagged list formats
     3. Content layouts
     4. Content records
     5. Websites
     6. Navigation items
   • You can export the entire contents (all descendants) of a content folder, sub-folder in the websites tree, or all navigation items in a branch of a sitemap by selecting a folder or navigation item that contains descendants.
   • You can export a portion of a content folder, or a portion of the websites in a given folder of the websites tree, or a portion of the navigation items within one branch of the sitemap hierarchy by holding Shift or Ctrl while selecting each object. For all other exportable object types (content layouts, content types, and tagged list formats), you can likewise multi-select any portion shown.
4. From the toolbar, choose Export:
   • If the selected object type is a content folder, navigation item, or sub-folder in the websites tree, you are presented with the option to Export children as well?
     • Select this checkbox to export all Published descendants of the object that you selected for export.
     • Clear this checkbox to export only the object that you selected.
   • When the export begins, you are asked by Windows where to save the exported XML file on your local computer. At this point you can rename the XML file if you prefer to give it a more meaningful name.
5. In a browser window connected to iMIS of your target server, select the location where you want to import the contents of the XML file, then from the toolbar choose Import. A window is displayed that enables you to browse for the location of the XML file on your local computer.
6. Click Browse to select the XML file, then click Upload to begin the import process.

   Warning! You must import these XML files in the order shown in Step 3, to ensure that dependant objects are present in the target database when the object that depends on them is imported.

   A window is displayed that enables you to selectively choose which objects in the XML file to import, and other options that affect the import results.

   • In the Import File Contents area, ensure that the checkbox for every object that you want to import is selected. Note that if you choose not to import any folders that are listed in the XML file, the system will create a new folder with the same exact name (because the folder's children must still be placed in a folder with that name), but the definition of that new folder will comprise system-assigned defaults instead the original folder's definition.
   • In this context of importing changes and additions between staging and production servers, it does not matter whether the Overwrite existing objects checkbox is selected or not. The only objects from the XML file that will actually be imported are those that are completely new to the target server (they were initially created on the source server), or those that are a more recently published version than the same content record already existing on the production server.

   Note: If the parent folder for the document being imported does not exist in the destination database, the documents are imported to the system root unless the option to override the destination is checked. For example, content imported without a parent in the destination database is uploaded to the @/ root. To avoid this, be sure to export the highest parent folder that does not exist in the destination along with the other documents.

   • In this context of importing changes and additions between staging and production servers, you should generally leave the Override destination with checkbox cleared. When selected, this option ignores the original folder paths of the objects in the XML file and instead places all of the objects in a single flat level inside the definition object you selected as the target location for the imported objects, which is probably not the result that you want. For example, assume that on your staging server, you exported content folder A, which contained several content records and a sub-folder B, which in turn contained several content records. On your production folder, you selected content folder C before beginning the import. In this scenario:
     • If you leave this checkbox cleared, the imported result will be a content folder A with several content records and a sub-folder B with several content records in it. In other words, an exact copy of the exported structure from your staging server.
     • If you select this checkbox, all of the content records from both folder A and folder B will be placed directly in folder C. Additionally, both folder A and folder B will also be placed inside of folder C, with nothing inside of them.
7. Click Import. When the import is complete, review the Messages area to ensure that no unexpected import errors occurred. Note that it is entirely normal to receive various Document already exists in a different path errors. This means that some of the objects in your XML file were identical to an object in the target database. For example, assume that you have exported an entire content folder from your staging server, but only a few of the content records in that folder had been modified since the last time this content folder had been imported to your production server. When you import this XML file into your production server, you would receive this error for all of the content records that you had not changed since the last time you had imported this content folder from the staging server.

Note: If further edit on a sitemap is necessary, modify the navigation item on the staging server and then export only the affected sitemap node, instead of exporting the entire sitemap at its root level.

8. All of your imported objects on the target server are now in a working state, so you will need to republish them before they can be used (or will appear on a rendered website).

• For an import to succeed, one of the following conditions must be true on the target database:
  • All of the objects in the XML file must never have existed in the target database
  • All of the objects in the XML file must have been completely purged from the target database. To completely purge an object you must delete it so that it ends up in the Recycle Bin, and then either purge that specific object from the Recycle Bin or empty the Recycle Bin entirely.
  • All of the objects in the XML file must be replacing older published versions on the target database. For example, if you export objects from a production server to a staging server and make changes to them on the staging server, then you export the newer versions from the staging server and import them back to the production server, the versions from the staging server are newer than the versions on the production server, so the import will complete successfully.
  • All of the objects in the XML file must be replacing completely different objects that have the same path and name AND you must select the Overwrite existing objects checkbox on import. For example, if you create a content record called MyContent in the content folder called MyFolder directly beneath the root (@) content folder, the path for this content record is @/MyFolder/MyContent. If you export the MyContent content record, then delete and purge the original MyContent content record, then create a brand new content record called MyContent in that same MyFolder content folder, then the import will complete successfully. 

  Note: If the parent folder for the document being imported does not exist in the destination database, the documents are imported to the system root unless the option to override the destination is checked. For example, content imported without a parent in the destination database is uploaded to the @/ root. To avoid this, be sure to export the highest parent folder that does not exist in the destination along with the other documents.

• Remember that multiple definition objects are required to render what end users experience as your website. If you import only a website object, that's not enough information to produce a rendered website in IIS. You must also import navigation items, content records, and so on. Every one of the following definition objects are potentially needed to render a website in IIS, so to import an entire website from one iMIS database to another, you need to import all of the following object types: websites, navigation items, content folders, content records, content layouts, content types, tags, and tagged list formats.
• Tags that are assigned to content records and content folders are not saved in the definition of the content record or content folder. Instead, the entire tag hierarchy is used to create an internal table that is associated with content records and content folders by using internal object IDs. This is why you must always import the entire tag hierarchy first before importing any other RiSE definition objects.
• You must have been granted the appropriate CAG permissions and Document system permissions in iMIS to use the Export and Import commands for all RiSE definition objects on both your staging server and on your production iMIS application server.