Migration of objects

When migrating a form from one server to another, Migrator migrates the form and the menus referenced by the form. This makes sure that the form works correctly when a user opens it in Mid Tier. In some cases, Migrator tries to migrate more than the form and menus, as described in the following sections.

Migrating join forms

When migrating a join form, Migrator builds a tree that represents the structure of the join form. For example, to migrate Join Form A, Migrator goes over the tree from top to bottom to find all the regular forms first (shaded forms). To make sure that the forms are created in the correct order, all the regular forms are migrated first, then all the join forms.

Join form migration example

Before migrating the forms, Migrator processes them as follows:

• Retrieves Join Form A, and sees that it has two member forms: Join Form B and Join Form C.
• Retrieves Form B, sees that it is a join form, and adds it to the join form list.
• Retrieves Join Form C, sees that it is a join form, and adds it to the join form list.
• Looks at Join Form B and sees that it has two member forms: Regular Form D and Join Form E.
• Retrieves Regular Form D, sees that it is a regular form, and adds it to the regular form list. At this point, all processing stops for Regular Form D because it does not have any members.
• Retrieves Join Form E, sees that it is a join form, and adds it to the join form list.
• Looks at Join Form E, sees that it has two members: Regular Form H and Regular Form I.
• Retrieves Regular Form H, sees that it is a regular form, and adds it to the regular form list. At this point, all processing stops for Regular Form H because it does not have any members.
• Retrieves Regular Form I, sees that it is a regular form, and adds it to the regular form list. At this point, all processing stops for Regular Form I because it does not have any members.
• Looks at Join Form C and sees that it has two members: Regular Form F and Join Form G.
• Retrieves Regular Form F, sees that it is a regular form, and adds it to the regular form list. At this point, all processing stops for Regular Form F because it does not have any members.
• Retrieves Join Form G, sees that it is a join form, and adds it to the join form list.
• Looks at Join Form G and sees that it has two members: Regular Form I and Regular Form J.
• Retrieves Regular Form I and sees that it is a regular form. However, it has already been added to the regular form list. At this point, all processing stops for Regular Form I because it does not have any members.
• Retrieves Regular Form J, sees that it is a regular form, and adds it to the regular form list. At this point, all processing for Regular Form J stops because it does not have any members.

The forms are then migrated as follows:

• Regular Forms D, H, I, F, and J are migrated first, because they do not depend on any other forms.
• Join Forms E and G are migrated next, because they are required for Join Forms B and C.
• Join Forms B and C are migrated next, because they are required for Join Form A.
• Finally, Join Form A is migrated, which was the original request.

Migrating a form and related objects

When migrating a form with related objects, Migrator retrieves a list of the active links, filters, escalations, associations, guides, applications, and web services attached to the form, according to the options you set. It then adds those objects to the list of objects to be migrated.

For example, if you migrate a form with one active link and one filter, Migrator migrates the form, the active link, the filter, and any menus used by the form. If you migrate a join form, Migrator includes the objects related only to the join form. It does not include the objects related to the forms needed to complete the join form migration.

AR System and Migrator use field IDs, not field names, to determine differences between source and destination environments. For example, if the source form has a field name of Field_ABC, and the destination form has a field name of Field_XYZ, with the same field ID, Migrator replaces instances of the form Field_XYZ with Field_ABC on the destination server.

After a migration from a development server to a production server, you might notice that field names on forms or fields referenced in workflow (such as Set Fields actions) have been changed on the production server.

If field names are the same, but field IDs are not, and the migration includes data, then the scenario is reversed: Migrator migrates data to the destination form and creates entries on the destination server where the field IDs are the same. If the source form has a field name of Field_ABC and the target form has a field name of Field_ABC with different field IDs, Migrator migrates the data to the destination field ID that matches. If the field types are not the same, the migration fails.

Before making modifications to your development environment, migrate the production server to the development server. This ensures that field IDs are synchronized. If you need to add fields to both environments manually, assign them the same field ID.

Archive forms

If you are migrating a form that has an archive form associated with it, the archive form is created on the destination if it does not already exist, or it is modified if it already exists. When a regular form is migrated for the first time, the server creates the form itself, then the archive form.