Migration Requests

The product provides out of the box migration requests. To see the migration requests provided with the base product, navigate to Admin > Migration Request and view the data that is provided there. The following sections provide general information about the base provided migration requests.

Wholesale Migration

In order to do a full “copy all administrative data” migration, several migration requests are needed. The separate migration requests are used to minimize the dependencies that would be found when trying to copy all data in one request. The following are the recommended migration requests to export / import:

  1. F1–Languages. Use this migration request to copy languages. Note that this is not necessary if the environments use only the ENG (English) language because this language is included as part of the product installation. It may also be simpler to go to the target region and define the languages manually assuming there are not very many languages supported. Note however that all languages defined in the source region must be defined in the target region if administrative data that will be copied includes language rows for that language.

  2. F1–SchemaAdmin. This migration request copies the objects that are part of the building blocks of a schema.

  3. C1-FWOwnedAndCoreBaseAdmin. This migration plan copies the remaining framework owned migration objects not already copied in previous migration requests along with base owned migration plans that are considered “core” and would have a lot of other objects that reference them. Note the following with respect to this migration request:

    • There are several configuration tool objects where only records with a CM owner flag are included in the migration. However for other configuration tool objects, all records are included to cater for the fact that the objects may have customizable columns or CM owned collection entries. The CMA tool will know to only update the CMable portions of base owned objects.

    • The migration request includes Rate Schedule, but it does not include RQ Rule. As a result, it specifically doesn’t include any rate schedules that reference an RQ rule.

  4. C1-BaseAdmin. This migration request includes the remaining administrative tables. Note the following with respect to this migration request:

    • The Form Types copied as part of the request are only those in the status of PENDING, GENERATED or ACTIVE.

    • The base owned Master Configuration migration plan is included here. However, it specifically does not copy the SEPA Master Configuration record because that record references master data such as a Person and Address. If your implementation uses the SEPA Master Configuration, it must be defined manually in the target region.

    • The entries for Rate Version and Rate Components specifically do not include records related to a rate schedule that references an RQ rule.

Piecemeal Migration

The base product provides a migration request to help orchestrate a targeted copy of Form Data. The C1–FormData migration request includes all administrative objects related to managing form data. An implementation may use the migration request as is to copy all form data from one region to another. Otherwise, it can use this migration request as a template for creating custom migration requests that may include specific selection criteria.

Also note that the C1–FormType migration plan has sophisticated instructions so that it may be used in a special migration request to copy one or more form types and their related data. The product has not provided a migration request for this migration plan because the selection criteria would differ for each migration. To create a specific migration request for one or more form types, follow these steps:

  1. Navigate using

    Admin Menu > Migration Request in Add mode.
  2. Define an appropriate Migration Request code and Description.

  3. Define the C1–FormType migration plan.

    Use the Selection Type to define a Specific Key when attempting to migrate one or more form types and their data by listing the form type codes. Or use a Selection Type of SQL Statement if there are multiple form types to select and the selection should be by something other than the code (such as all the form types for a given tax type or all form types effective on or after a given date).
  4. Save the record and proceed to the export and import steps.