Comme chacun sait, l’expérience permet de renouveler ses erreurs !
Je ne prétends pas avoir épuisé l’ensemble des erreurs possibles en matière de migration de base de données donateurs, mais voici une première liste issues de mon expérience de quelques projets récents (tous réussis, rassurez vous !! )

1 Une migration, c’est facile, et cela se passe en 3 temps :

Fichier / exporter dans l’ancienne application
Traiter le fichier intermédiaire avec un bonne vieille « moulinette » (qui a dit qu’il y avait plusieurs fichiers ?)
Fichier / importer dans la nouvelle application

Certains esprits chagrins prétendent qu’il est préférable de faire ça un week-end. Ne les écoutez pas ! quelques heures suffisent !

[intégrité des données, cohérence des référentiels, nouvelle architecture et nouvelles fonctionnalités en phase avec les nouveaux besoins, pointage minutieux des données « avant-après », autant de « détails » à ne pas négliger]

2 Une migration ne concerne que le service donateurs

Inutile d’inquiéter, et de faire perdre son temps aux services comptables, informatiques, et autre DAF !
Ils auront la bonne surprise le jour venu de voir le nouveau système flambant neuf, et seront émerveillés de notre efficacité !
Après tout, est-ce que le SI nous prévient quand une nouvelle version du serveur de messagerie est installée ??
Quand à prévenir l’agence, le routeur, et le CA, alors là ce serait vraiment le comble

[Une migration est un projet, transversal, qui doit impliquer l’ensemble des services concernés. L’aspect communication interne n’est pas à négliger.]

3 Une migration, n’est qu’un changement de prestataire

Nos procédures sont parfaites et n’ont pas besoin d’être revues,
la qualité de nos données est irréprochable (en tout cas c’est ce que nous a dit la Poste lors du dernier Charade/Estocade … c’était quand déjà ?),
Une adresse, cela reste une adresse !

[Une migration est l’occasion de remettre en question un certain nombre de pratiques. Sans vouloir tout remettre en cause, il est opportun de profiter de ce moment pour remettre en adéquation le système de gestion avec ses objectifs, et de valider (et faire valider) les objectifs en question.]

4 Le stagiaire qui vient d’arriver va très bien s’en occuper

On n’a pas que ça à faire dans le service, entre les campagnes de fidé, le bilan pour le rapport d’activité, et la préparation du congrès !
Il est là pour 3 mois, juste le temps de la migration
Si on a externalisé ce traitement, ce n’est pas pour s’en occupe maintenant !

[Il est essentiel qu’un référent interne, reconnu par tous, soit en charge du projet, du début du projet jusqu’à 6 mois après la recette de la nouvelle application]

5 Un cahier des charges, du temps perdu !

On va reprendre le guide de procédures écrit par le prestataire, et changer 2 ou 3 détails.
Au fait, il est où ?

[cf. le point 3 : La phase préparatoire de rédaction du cahier des charges est une étape importante du projet. Que ce soit en terme de contenu naturellement, mais aussi parce qu’elle permet à chaque personne/service/entité impliqué de s’approprier la partie du projet qui le ou la concerne.]

6 L’intendance suivra

Les enveloppes PAP à l’adresse de l’ancien prestataire
La nouvelle agence bancaire, le tampon d’endos
La formation du nouveau prestataire de full filment
….

[Le diable se niche dans les détails ! ]

7 Au fait, qui a décidé qu’il fallait migrer, et pourquoi ?

[En amont même du cahier des charges, un point rapide mais clair devra être fait sur les objectifs de la migration : réduction des coûts, pression sur le prestataire actuel, mise en place de nouvelles fonctionnalités, etc.
Ce « brief » devra être validé par le comité de direction, et une structure associative (bureau, CA) au minimum en être informé ]

Base de données donateurs : comment rater sa migration !