# Migrations

Lorsque vous modifiez un formulaire alors qu'il possède déjà des fiches qui vous sont utiles, vous devez mettre en place une stratégie de migration. Chaque fois que vous activez un formulaire, vous créez ce qu'on appelle une [version](/user-documentation/documentation-utilisateur/components-concepts-terminology.md#version). Les nouvelles fiches de ce formulaire seront donc toutes créées avec cette version.

Mais qu'en est-il des fiches qui précèdent cette activation ?

## Stratégie 1 : migrer toutes les anciennes fiches vers la nouvelle version

### Présentation

L'objectif ici est de conserver un ensemble cohérent de fiches reposant sur la même structure de données. Nous allons donc migrer les anciennes fiches vers la nouvelle version.

![](/files/hsZJhy7LWhwSHRQLL1aA)

### Mise en place

Pour cela, vous devez d'abord créer la migration. Celle-ci vous est proposée dans une fenêtre directement après l'activation du formulaire.

![](/files/y005CyT1Pe4WeT2nF5db)

Dans l'écran suivant (qui ne s'affiche que si des champs ont été supprimés), vous devez faire correspondre les noms système de la version précédente avec ceux de la nouvelle version afin de préserver les données des champs renommés. Il suffit ensuite de valider en cliquant sur « Enregistrer et appliquer ».

![](/files/8BzMT40rUuNSmSmKvC3A)

Si aucun champ n'a été supprimé, vous pouvez directement « Démarrer la migration » depuis la fenêtre.

{% hint style="info" %}
La méthode proposée ci-dessus permet de migrer les fiches sur le serveur. Mais les fiches peuvent rester dans leur état sur les mobiles. Si c'est le cas, lorsque le mobile envoie une mise à jour de la fiche, celle-ci sera automatiquement migrée à la réception sur le serveur.
{% endhint %}

### Cas où cette stratégie est recommandée

* Lorsque vous êtes en train de créer le formulaire et qu'il n'est pas encore utilisé en conditions réelles.
* Lorsque vous ne modifiez pas la structure des données.
* Lorsque vous ajoutez une fonctionnalité que vous jugez nécessaire sur toutes les fiches (y compris les fiches existantes ou en cours de traitement).
* Ex : mise en place d'une [représentation](/user-documentation/documentation-utilisateur/build/building-forms/representation.md) ou d'un champ localisation de la fiche sur une carte.
* Ajout d'une nouvelle [condition](/user-documentation/documentation-utilisateur/build/building-forms/conditions.md) pour empêcher une [automatisation](/user-documentation/documentation-utilisateur/build/building-forms/automations.md) de se déclencher à chaque modification.

## Stratégie 2 : autoriser la migration des fiches

### Présentation

La stratégie ici est de permettre aux fiches de passer à la nouvelle version uniquement lorsqu'elles sont mises à jour.

![](/files/AKQx6YenIfD2iAdr3mQQ)

### Mise en place

Suivez le protocole précédent, mais n'appliquez pas la migration à la dernière étape. Vous devrez donc cliquer sur « Enregistrer » et non sur « Enregistrer et appliquer ».

### Cas où cette stratégie est recommandée

Si vous souhaitez mettre à jour un [modèle de rapport](/user-documentation/documentation-utilisateur/build/building-the-reporting/report-templates.md) ou une [automatisation](/user-documentation/documentation-utilisateur/build/building-forms/automations.md) reposant sur un champ nouvellement créé, tout en minimisant l'impact sur le travail en cours de vos collaborateurs (voir ci-dessous : cas particulier des automatisations et des modèles de rapport).

## Stratégie 3 : laisser les fiches dans leur version

### Présentation

La troisième stratégie consiste à laisser les fiches dans leur version.

![](/files/dZAdzq66BAx0pMGDCpM6)

### Mise en place

Lorsque vous activez le formulaire et que la pop-up suivante apparaît, cliquez sur « Fermer ».

![](/files/y005CyT1Pe4WeT2nF5db)

{% hint style="info" %}
Il sera toujours possible, par la suite, de changer d'avis et de migrer les fiches. Pour cela, cliquez sur le bouton « Paramètres », puis dans « Actions avancées », cliquez sur « Migrations ».

Vous pouvez alors créer une nouvelle migration (bouton « Nouveau ») afin de configurer comment passer d'une version à une autre et déplacer les fiches d'une version à une autre (bouton « Migration manuelle »).
{% endhint %}

### Cas où cette stratégie est recommandée

* Si vous souhaitez ajouter un champ obligatoire, cette méthode est nécessaire.
* Lorsque vous supprimez un champ dans un formulaire et que vous ne voulez pas perdre les données des anciennes fiches.
* Lorsque vous apportez des modifications importantes au formulaire et que vous n'êtes pas sûr des impacts qu'une migration pourrait avoir.
* De manière générale, une migration peut toujours être effectuée rétrospectivement, mais on ne peut pas revenir en arrière sur une migration effectuée. En cas de doute, il est donc plus sûr de ne pas migrer.

## Informations complémentaires

### Déclenchement des automatisations

Une migration ne déclenche pas les [automatisations](/user-documentation/documentation-utilisateur/build/building-forms/automations.md) (quel que soit le déclencheur configuré).

### Calcul des formules

Toutes les [formules](/user-documentation/documentation-utilisateur/build/building-forms/fields/formulas.md) automatiques sont recalculées lors des migrations. Si vous ne souhaitez pas que ces formules soient recalculées, nous vous invitons soit à les transformer en formules manuelles, soit à ne pas effectuer la migration.

Exception : les formules ne sont pas recalculées lors de la migration s'il existe au moins 5 formules avec des relations (parents et/ou enfants).

### Cas particulier des automatisations et des modèles de rapport

Toutes les fonctionnalités d'un formulaire sont régies par les versions ([conditions](/user-documentation/documentation-utilisateur/build/building-forms/conditions.md), [représentation](/user-documentation/documentation-utilisateur/build/building-forms/representation.md), statut fonctionnel, [workflow](/user-documentation/documentation-utilisateur/build/building-forms/workflow-and-assignation.md), etc.) à l'exception des [automatisations](/user-documentation/documentation-utilisateur/build/building-forms/automations.md) et des [modèles de rapport](/user-documentation/documentation-utilisateur/build/building-the-reporting/report-templates.md).

Si vous supprimez un champ ou une condition dans une version du formulaire utilisée dans une automatisation ou dans un modèle de rapport, le fonctionnement de ces derniers est donc compromis pour les fiches de cette version.

À l'inverse, si vous souhaitez mettre à jour un modèle de rapport ou une automatisation basée sur un champ ou une condition nouvellement créés, ils risquent de fonctionner mal sur les fiches des anciennes versions. Il peut donc être opportun de les migrer avec la stratégie 1 ou 2.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.center.daxium-air.com/user-documentation/documentation-utilisateur/build/building-forms/migrations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
