top of page


Updated: Jan 26

When you modify a form when it already has records that are useful to you, you must implement a migration strategy. Each time you activate a form, you create what is called a version. The new files in this form will therefore all be created with this version.

But what about the files that precede this activation?

Three strategies are possible:

Strategy 1: Migrate all old records to the new version


The objective here is to keep a coherent set of files which are based on the same data structure. We will therefore migrate the old files to the new version.

Setting up:

To do this, you must first create the migration. This is offered to you in a window directly after activating the form.

In the following screen (which only appears if fields have been deleted) you must match the system names of the previous version with the system names of the new version to preserve data from renamed fields. Then simply validate by clicking on "Save and apply".

If no fields had been deleted, you can directly "Start migration" from the window.


The method proposed above allows you to migrate the files to the server. But the files can remain in their state on mobiles. If this is the case, when the mobile sends an update of the file, the latter will be automatically migrated upon receipt on the server.

Cases where this strategy is recommended:

  • When you are creating the form and it is not yet used in real conditions.

  • When you do not modify the data structure

  • When you add a functionality that you think is necessary on all forms (including existing forms or those currently being processed).

  • Ex: setting up a representation or a location field of the file on a map

  • Added a new condition to prevent an automation from taking place with each modification

Strategy 2: Allow file migration


The strategy here is to allow files to move to the new version only when they are updated.

Setting up:

Just follow the previous protocol, but do not apply the migration in the last step. You will therefore have to click on "Save" and not on "Save and Apply".

Cases where this strategy is recommended:

If you wish to update a report template or an automation based on a newly created field while minimizing the impact on the current work of your collaborators (see below: Special case of automations and report templates ).

Strategy 3: Leave the cards in their version


Finally the third strategy consists of leaving the sheets in their version.

Setting up:

When you activate the form and the following pop-up appears, click on "Close".


It will always be possible in the future to change your mind and migrate the files. To do this, click on the "Parameters" button, then in the "Advanced actions" click on "Migrations".

You can then create a new migration ('New' button) in order to configure how to move from one version to another and move the files from one version to another ('Manual migration' button).

Cases where this strategy is recommended

  • If you want to add a required field, this method is required.

  • When you delete a field in a form and you don't want to lose data from previous forms.

  • When you make significant changes to the form and you are unsure of the impacts a migration might have.

  • Generally speaking, a migration can always take place retrospectively, but we cannot reverse a completed migration. So if in doubt, it is safer not to migrate.

Additional information:

Triggering the automations:

A migration does not trigger the automations (regardless of the trigger configured).

Calculation of formulas:

All automatic formulas are recalculated during migrations. If you do not want these formulas to be recalculated, we invite you to either transform them into manual formulas, or not to perform the migration.

Exception: formulas are not recalculated during migration if there are at least 5 formulas with relationships (parents and/or children).

Special case of automation and report models:

All the functionalities of a form are governed by the versions (conditions, representation, functional status, workflow, etc.) with the exception of automation and report models.

If you delete a field or a condition in a version of the form that is used in an automation or in a report template, the functioning of the latter is therefore compromised for the forms of this version.

Conversely, if you want to update a report template or an automation based on a newly created field or condition, they risk working poorly on forms in older versions. It may therefore be appropriate to migrate them with strategy 1 or 2.


Related Posts

See All


Documentation Utilisateurs

bottom of page