Lors d’une migration, il est nécessaire de convertir les données pour les adapter aux modifications du modèle de données. Si les volumes sont importants et les modifications significatives (en particulier si le retard accumulé implique d’enchaîner plusieurs migrations), la durée de ces traitements peut atteindre plusieurs jours.
Plusieurs approches peuvent être envisagées :
| Migration complète | Les données accumulées depuis la mise en œuvre sont toujours présentes. La migration complète les retraite intégralement mais impacte la durée des traitements de chaque version intermédiaire. |
| Nouveau projet | Lors de la mise en œuvre initiale, les principales données (clients, fournisseurs, articles) avaient vraisemblablement été reprises de l’application antérieure, ainsi que le détail des soldes clients et fournisseurs (écritures ouvertes). En revanche, les commandes ventes et achats en cours avaient été ressaisies et la configuration avait été initialisée manuellement. Il est bien sûr possible de procéder de la même manière, mais il faudra alors extraire les données de la version actuelle pour les importer dans la nouvelle puis ressaisir les documents en cours (reliquat des commandes achats et ventes, dernière situation de chaque contrat…) et définir les procédures de transition (réceptions non facturées, les demandes d’appro…). |
| ‘Subset’ (extrait) | Cette méthode consiste à créer dans la version actuelle une nouvelle ‘société’, pour y copier les données sélectionnées de la société concernée. C’est alors cette nouvelle société ainsi allégée qui sera prise en compte par les traitements de migration. Une étude détaillée permettra de préciser la liste des données copiées ou retraitées et les règles à appliquer, en particulier pour la reprise des documents d’achats et de vente . |
Itérations
Quelle que soit la méthode retenue, il faut généralement envisager deux itérations de la reprise de données avant la reprise définitive.
La première reprise de données, dès le lancement du projet, permet de disposer, lors des ateliers de formation, de données propres à l’entreprise pour simuler des cas concrets permettant aux acteurs de se projeter dans la solution cible. A ce stade, il n’est pas indispensable de disposer de l’intégralité des données prévues lors de l’étude. Les problèmes rencontrés lors de cette première reprise seront contournés et consignés pour être traités lors de l’itération suivante.
Une seconde itération est généralement nécessaire pour tenir compte du retour d’expérience de la première et valider les conditions de la reprise définitive. Elle permettra en particulier de relever les temps nécessaires, pour en tenir compte dans la planification de la migration définitive (elle doit pour cela se dérouler dans le même environnement que celui qui sera utilisé à cet effet).
Des travaux supplémentaires pourraient s’avérer nécessaires si les hypothèses de l’étude de reprise initiale sont revues entretemps, et/ou si d’autres itérations étaient demandées.
Commentaires récents