Migration et reprise de données Oracle
Un fichier chargé n’est pas une reprise réussie.
Les données doivent arriver au bon endroit. Elles doivent surtout permettre de facturer, acheter, payer et justifier les comptes. Redshift traite la reprise comme un chantier métier et technique, avec des responsables et des preuves.
Le vrai risque commence avant le chargement
Plusieurs systèmes sources, des règles implicites, des doublons, des historiques dont personne ne veut décider : la difficulté commence bien avant le fichier cible. Si les propriétaires métier ne valident pas ce qui doit être repris, transformé ou laissé de côté, le chargement ne fera que déplacer le problème.
Mettre les règles à plat
Nous cadrons les objets, les sources, les volumes et les dépendances. Pour chaque objet : qui extrait, qui nettoie, qui valide le mapping, qui accepte les écarts ? Les règles de transformation et de qualité doivent être explicites. Le mécanisme de chargement est choisi selon l’objet et le périmètre ; un outil ne remplace ni la préparation ni le contrôle.
Répéter avec des critères de sortie
Une répétition sert à mesurer les temps, les rejets, les corrections et les dépendances de la séquence. Elle doit conduire à une décision : peut-on refaire l’opération dans la fenêtre de bascule, avec les mêmes contrôles et des responsabilités connues ? Répéter uniquement les objets faciles donne une confiance très confortable. Et très fragile.
Rapprocher avant de déclarer terminé
Un statut technique réussi ne prouve pas que la reprise est exploitable. On rapproche les volumes et, selon le périmètre, les montants, soldes et relations entre objets. Chaque différence doit être expliquée, corrigée ou acceptée par le bon responsable. Les critères et tolérances sont convenus avec les métiers ; ils ne se découvrent pas la veille du démarrage.
Ce qui reste, et comment on commence
Le chantier doit laisser un inventaire des sources, des règles de mapping, un suivi des anomalies, des preuves de rapprochement et un déroulé de bascule répété. Pour commencer, apportez un inventaire et un bilan de la dernière répétition. Les données sensibles restent dans un environnement autorisé : pas de fichier client envoyé par le formulaire public.
Les questions qu’on nous pose.
Faut-il reprendre tout l’historique ?
Pas par réflexe. Les besoins opérationnels, comptables, réglementaires et de consultation doivent être distingués. La décision associe les métiers et les responsables concernés ; nous ne fixons pas à leur place les obligations de conservation.
Qui valide la qualité des données ?
L’équipe technique produit les contrôles et explique les écarts. L’acceptation appartient aux responsables métier désignés, selon des critères convenus avant la bascule.
Pour creuser. Et passer à l’action.
Quand les données fragilisent le programme →
Vos données sont-elles prêtes à déménager ? →
La fiche de ressource précise les conditions d’accès au document.