Migrer et synchroniser les données existantes vers le cadre de CSDM travail

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 3 minutes de lecture

    • Vous effectuez plusieurs tâches pour confirmer que vos données d’application existantes migrent correctement vers les tables requises dans le CMDB.

    Avant de commencer

    Rôle requis : admin

    Pourquoi et quand exécuter cette tâche

    Gardez à l’esprit les points suivants :
    • Certaines CSDM tables ont été introduites récemment, vous ne les connaissez peut-être pas. Consultez la documentation de votre produit pour en savoir plus sur les tables inconnues.
    • Vous pouvez continuer à utiliser des tables personnalisées ou non conformes CMDB . Si vous le faites, cependant, vous risquez de ne pas tirer pleinement parti de vos produits.
    • Assurez-vous d’utiliser les outils de migration décrits dans .Assistance dans le processus de synchronisation du CSDM cycle de vie
    Gérez les attributs que vous utilisez. Rationalisez vos attributs personnalisés. Suivez les instructions suivantes pour décider si vous devez vraiment conserver toutes les personnalisations :
    • Préféré : l’attribut personnalisé n’a pas d’attribut connexe système-de-base , mais il n’est pas nécessaire.
    • Keep : l’attribut personnalisé n’a pas d’attribut connexe système-de-base , mais il est requis pour un cas d’utilisation unique.
    • Refactoriser : l’attribut personnalisé dispose d’un attribut ou d’une système-de-base aptitude qui peut être migré.
    • Pas nécessaire : la personnalisation n’est plus nécessaire. Supprimez les attributs que vous n’utilisez pas ou rarement. Envisagez de supprimer des attributs s’il existe une meilleure façon de traiter un cas d’utilisation.
    Tenez compte des dépendances connexes. Le déplacement d’éléments de configuration (CI) vers une nouvelle table ne déplace pas automatiquement les dépendances associées. Pour identifier les dépendances connexes, utilisez les scripts décrits dans Migration vers CSDM Identification des dépendances entre les tables (disponible sur le ServiceNow Community).
    Important :
    Le script ne déplace pas vos données ni leurs dépendances. Elle identifie uniquement les dépendances. Vous refactorisez les données et les dépendances dans le cadre de la migration.

    Après avoir exécuté les scripts et évalué les données, vous aurez une meilleure idée de l’effort requis pour migrer vos données. Décidez si vous avez besoin de tous les rapports, règles et scripts référencés. Décidez ensuite ce que vous souhaitez migrer et établissez un plan de migration.

    Figure 1. Migration de workflow
    Étapes du workflow de migration.

    Procédure

    1. Sauvegardez vos données.
      Exportez vos données (avec tous les attributs) vers Excel et conservez le fichier dans un emplacement sécurisé. Ayez un plan d’urgence en cas de problème.
    2. Mappez les attributs.
      Identifiez la table où les données doivent aller. Assurez-vous que la table de destination possède les attributs requis système-de-base . Rationalisez vos attributs personnalisés. Décidez des personnalisations que vous conserverez.
    3. Déplacez les CI des classes existantes vers CMDB les classes.
      Remarque :
      N’oubliez pas les tables non conformes et leurs dépendances. Vous pouvez avoir des centaines de rapports, de règles métier, de scripts, de références de table, et autres, qui ont besoin des données dans vos tables non conformes.

      le déplacement de CI vers une nouvelle table ne déplace pas automatiquement les rapports, les règles métier, etc. Comme décrit dans les étapes suivantes, le script correctif identifie les dépendances que vous devez refactoriser. Vous pouvez télécharger le script correctif à partir ServiceNow Community du fichier .

    4. Refactoriser les attributs.
      Solidifiez le modèle de données et préparez les données pour la migration.

      Assurez-vous d’avoir terminé les tâches liées au mappage d’attribut décrites dans les étapes précédentes. Suivez les directives et refactorisez vos données si nécessaire.

    5. Migrez les données.
      Remarque :
      Assurez-vous d’avoir une sauvegarde valide et récente. Effectuez une autre sauvegarde si nécessaire. Lors de la migration, vous perdez tous les attributs personnalisés ou système-de-base qui ne sont pas dans la même hiérarchie de tables.
      Gardez ces points à l’esprit au fur et à mesure que vous avancez :
      • Migrez vos CI vers la nouvelle classe pour déplacer le CI et tous ses objets, incidents et changements connexes vers la nouvelle table.
      • Commencez par quelques CI et augmentez le nombre lorsque vous vous sentez à l’aise.
    6. Corrigez les dépendances de vos tables :
      1. Modifiez les rapports pour utiliser la nouvelle table.
      2. Migrez les règles métier et les scripts selon les besoins.
      3. Mettez à jour les références de table si nécessaire.
    7. Rechargez les données dans les nouveaux attributs à l’aide de la copie de sauvegarde que vous avez effectuée précédemment.
    8. Validez toutes les données et dépendances.

    Résultats

    Vous avez migré votre application vers le cadre de CSDM travail et vos données se trouvent aux emplacements requis CMDB .