Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Assuming that you have performed exported a backup export and then reimported it on a new instance, the main step of the reimport is the mappings:

...

In this page, Requirement Yogi asks you what is the new ID of records on the new instance. If you are reimporting on the same instance, all IDs remain the same. If you are reimporting on a new instance, then all of the Page IDs, User IDs, etc. have changed.

This screen allows you to carefully map the old and new IDs.

It can be very long and very menial to manually check every ID. But it is extremely important to do it well, for the health of the future data. For this purpose, it is smart to access the database in SQL and cross-check the data manually. The data is located in AO_32F7CE_DBBACKUPMAPPING, columns DESTINATIONVALUE and STATUS.

A specific example was provided in Checking that the Jira mappings are correct. The same principle applies to Confluence.

How this page helps you

  • “Map automatically” will try to lookup the values in the new database, and match the records. For example, it will lookup the pages with the same title, and the same version number (only for unmapped and mapped-with-a-yellow-mark records). After this automation, it comes back to this page.

  • “Import this data” will attempt to import the current set of data. Is it marked as a “Destructive operation” because it first deletes the target scope (e.g. it will delete the Jira project if you are importing a Jira project, or the full instance’s Requirement Yogi data if you are importing an instance). After this step, you can come back to the mappings, fix something and reimport.

  • Filters will help you see which records still need to be mapped.

...