Vorgeschlagener Workflow für eine komplexe Datenmigration

In diesem Artikel wird ein schrittweiser Prozess für die Migration großer Datenmengen vorgeschlagen. Beim Übertragen von Daten aus einem leistungsfähigen cloudbasierten CRM ist es wichtig, aufgrund der komplexen Einrichtung sorgfältig zu planen – z. B. benutzerdefinierte Objekte, Verknüpfungen zwischen Daten und eindeutige Datensatz-IDs. Sie müssen sowohl die technischen Schritte als auch die Funktionsweise der Migration in der Praxis durchdenken.

• Technischer Ansatz: Behandelt wichtige Migrationsschritte – Extrahieren, Transformieren und Laden von Daten in Dataverse – und stellt gleichzeitig Integrität, Erhaltung von Beziehungen und Optimierung der Leistung durch Validierung und Fehlerbehandlung sicher.
• Funktionaler Ansatz: Deckt funktionale Migrationsaufgaben wie Datensegmentierung und Archivierung ab und hebt hervor, dass Geschäftsbeteiligte einbezogen werden müssen, um sicherzustellen, dass die Daten ihren Anforderungen entsprechen.

Technischer Ansatz für die Datenmigration

Stellen Sie eine reibungslose Migration sicher, indem Sie einen strukturierten Ansatz verfolgen – Extrahieren, Transformieren und Laden von Daten, während Integrität beibehalten und Unterbrechungen minimiert werden.

Aus der Quelle Daten in die Staging-Datenbank extrahieren

Bei komplexen Datenmigrationen empfehlen wir das Staging von Daten in einer separaten Datenbank (z. B. SQL Server). Dieser Stagingbereich erfasst eine Momentaufnahme des Quellsystems, ohne laufende Geschäftsvorgänge zu unterbrechen.

Wichtige Überlegungen:

• Vollständige vs. Deltalast: Organisieren von Daten als vollständige oder inkrementelle (Delta)-Lasten. Verwenden Sie automatisch generierte Zeitstempel, um die Datenankunft nachzuverfolgen und Änderungen für zukünftige Lasten zu identifizieren.
• Failoverbehandlung: Entwerfen Sie den Prozess zum Überspringen von fehlgeschlagenen Datensätzen (z. B. wegen der Feldlänge, ungültiger Nachschlagevorgänge) ohne den Migrationsprozess anzuhalten. Protokollieren und Beheben von Problemen vor der Neuverarbeitung.
• Feldzuordnung: Konvertieren Sie Quellwerte, um sie in den Zielformaten der Staging-Ebene und in den Wertebereichen der Staging-Datenbank abzustimmen, bevor Sie die Daten zu Dataverse migrieren, um die Effizienz zu verbessern.
• Datenüberprüfungen: Führen Sie Integritätsprüfungen aus, um Probleme wie fehlende Verweise abzufangen. Da die Datenextraktion Stunden oder Tage umfassen kann, verwenden Sie die Staging-Ebene, um unvollständige Datensätze zu filtern und Konsistenz sicherzustellen.
• Datenvisualisierung: Verwenden Sie die Stagingdatenbank, um Daten zu überwachen und zu analysieren , z. B. Datensätze zählen oder Finanzfelder addieren – vor der endgültigen Migration.

Transformieren von Daten in Ziel-Stagingdatenbank

Nachdem Sie Daten aus dem Quellsystem extrahiert haben, transformieren Sie sie in eine Ziel-Stagingdatenbank, die das Dataverse-Schema widerspiegelt und Werte enthält, die für direktes Einfügen oder Aktualisieren bereit sind.

Wichtige Transformationsschritte:

• Feldzuordnung: Ordnen Sie Quellspalten den Dataverse-Spalten zu. Verwenden Sie Skripts, um Tabellen bei Bedarf zu verknüpfen und zusammenzuführen.

• Optionset-Konvertierung: Konvertieren Sie textbasierte Optionsetwerte in Dataverse-Ganzzahlen, indem Sie eine Zuordnungstabelle (z. B. OptionSetMapping) und Sammelaktualisierungsabfragen verwenden. Erstellen Sie eine Tabelle, um die Standardisierung und Automatisierung der Transformation von Optionset-Werten von Quell- zu Zielsystemen zu ermöglichen.

  Tabelle: OptionSetMapping

  Spaltenname	Datentyp
  Name der Quelltabelle	Schnur
  Zieltabellenname	Schnur
  Quelltext	Schnur
  Zieltext	Schnur
  Zielwert	Schnur

  Verwenden Sie die OptionSetMapping-Tabelle, um Optionsetwerte im großen Maßstab effizient zu transformieren und zu aktualisieren. Um beispielsweise alle Optionssatzwerte in der Kontakttabelle basierend auf übereinstimmenden Textwerten zu aktualisieren:

  Update C.\<OptionsetValue\> = M.\<TargetValue\> 
  FROM Contact C 
  JOIN OptionsetMapping M 
    ON C.OptionsetText = M.TargetText 
    AND M.TargetTableName = 'Contact'
  

• Vermeiden Sie benutzerdefinierte GUIDs: Lassen Sie Dataverse GUIDs generieren, um Fragmentierungs- und Leistungsprobleme zu verhindern.

• Zeichenfolgenlängenüberprüfungen: Stellen Sie sicher, dass Zeichenfolgenwerte den Dataverse-Grenzwerten entsprechen. Kürzen oder bei Bedarf anpassen.

• Berechnete Felder: Fügen Sie abgeleitete Felder (z. B. Name für Nachschlagevorgänge) hinzu, wenn sie in der Quelle fehlen.

• Weitere Überlegungen: Berücksichtigen Sie beim Entwerfen von Tabellen, die mit dem Dataverse-Schema übereinstimmen, die folgenden Schlüsselspalten und unterstützende Tabellen.

  • DataMigration_CreatedDateTime: Automatisch generierter Zeitstempel zum Nachverfolgen von Datenladevorgängen.
  • Aktionsflagge: Gibt Einfüge (I), Update (U) oder Delete (D) an.
  • Verarbeitungskennzeichnung: Verfolgt den Status – Verarbeitet (P), Nicht verarbeitet (U), Fehler (E) oder Erfolg (S).
  • Eindeutige Spalte: Verwenden Sie eine eindeutige ID (z. B. die eindeutige ID aus dem Quellsystem), um Datensätze zuzuordnen.
  • Erfolgs-/Fehlertabellen: Verwalten Sie separate Tabellen (z. B. Contact_Success, Contact_Error), um Ergebnisse zu protokollieren und Wiederholungen zu unterstützen.

Sequenztabellen und Vorabladen von Nachschlagevorgängen

Ordnen Sie ihre Tabellen nach statischen Transformationen an, um zyklische Abhängigkeiten zu reduzieren – Fälle, in denen Tabellen aufeinander verweisen und isolierte Importe unmöglich machen. Verwenden Sie diesen Ansatz:

• Alle Tabellen auflisten, die für die Migration geeignet sind.
• Zählen Sie einzigartige Nachschlagen pro Tabelle (ignorieren Sie Felder wie Created By und andere Tabellenabfragen, wenn keine Migration erfolgt).
• Sortieren Sie Tabellen in aufsteigender Reihenfolge nach Nachschlageanzahl.
• Schließen Sie N:N-Beziehungstabellen ein, und zählen Sie beide Nachschlagevorgänge.
• Schließen Sie Nachschlagevorgänge mit mehreren Tabellen aus (z. B. in Bezug-Felder).

Dieser Ansatz definiert die Reihenfolge der Datenmigrationslast und funktioniert in den meisten Szenarien gut. Für komplexere Fälle:

• Verwenden Sie einen eindeutigen Bezeichner (z. B. Importsequencenumber), um Datensätze zwischen Staging und Dataverse abzugleichen, wenn GUIDs beim Einfügen generiert werden.
• Trennen Sie Erfolgs- und Fehlerprotokolle, um Sperrprobleme zu vermeiden und die Leistung zu verbessern.
• Laden Sie Nachschlage-GUIDs aus bereits migrierten Tabellen vor, um Verweise beim Einfügen aufzulösen.
• Umgang mit zyklischen Abhängigkeiten durch:
  • Einfügen von Datensätzen ohne abhängige Nachschlagevorgänge.
  • Aktualisieren dieser Nachschlagevorgänge nach dem Laden verwandter Datensätze.

Laden von Daten in Dataverse

Der nächste Schritt besteht darin, Ihren Ansatz zum Laden von Daten in Dataverse zu bestimmen und zu implementieren.

1. Toolerstellung: Wählen Sie ein Tool basierend auf der Datengröße und -komplexität aus:

   • SDK-Konfigurations-Migrationstool
   • Azure Data Factory
   • KingswaySoft
   • Schreiber
   • XrmToolBox's Data Transporter

2. Wichtige Überlegungen (tool-agnostisch):

   • Behandeln von zyklischen Abhängigkeiten: Sequenztabelle wird geladen, um Zirkelsuchen zu minimieren. Fügen Sie Datensätze ohne abhängige Nachschlagevorgänge ein, und aktualisieren Sie sie später.

   • Track record IDs: Zeichnen Sie Dataverse-GUIDs in einer Erfolgstabelle auf und aktualisieren Sie dann die Haupttabelle mithilfe eines eindeutigen Identifikators (zum Beispiel Importsequenznummer).

   • Optimieren sie die Batchgröße und die Anzahl der Threads: Lesen Sie Anleitungen zum Optimieren der Leistung für Massenvorgänge. Die von Ihnen verwendete Anwendung muss Dienstschutzfehler verwalten, die auftreten, wenn eine außergewöhnliche Anzahl von Anforderungen an Dataverse gesendet werden. Wenn Sie Ihren eigenen Code schreiben und die Dataverse-Web-API verwenden, stellen Sie sicher, dass Sie 429 Fehler wiederholen, wie in den Dienstschutz-API-Grenzwerten beschrieben. Wenn Sie das Dataverse SDK verwenden, werden diese Fehler für Sie verwaltet.

     Um eine optimale Leistung zu erzielen, optimieren Sie die Batchgröße und die Threadanzahl basierend auf der Tabellenkomplexität:

     • Out-of-the-Box(OOB)-Tabellen (z. B. Kontakt, Konto, Lead): Diese Tabellen sind aufgrund integrierter Plug-Ins und Aufträge langsamer. Empfohlen: Batchgröße 200-300, bis zu 30 Threads (wenn ≤10-Nachschlagevorgänge und 50 bis 70 Spalten).
     • Einfache Tabellen (wenige oder keine Suchen): Empfohlen: Batch-Größe ≤10, bis zu 50 Threads.
     • Moderate komplexe benutzerdefinierte Tabellen (einige Nachschlagevorgänge): Empfohlen: Batchgröße ≤100, bis zu 30 Threads.
     • Große/komplexe Tabellen (>100 Spalten, >20 Nachschlagevorgänge): Empfohlen: Batchgröße 10–20, bis zu 10 bis 20 Threads, um Fehler zu reduzieren.

3. Infrastrukturtipps: Um die Datenmigrationsleistung zu maximieren, führen Sie Ihre Migration von einem virtuellen Computer (VM) aus, der sich in derselben Region wie Ihre Dataverse-Umgebung befindet. Dieser Ansatz reduziert die Latenz erheblich und beschleunigt den gesamten Prozess. Erfahren Sie, wie Sie den Bereich Ihrer Dataverse-Umgebung bestimmen.

4. Fehlerbehandlung: Ignorieren Sie keine Fehler. Beheben Sie sie, um Kaskadierende Fehler zu verhindern. Verwenden Sie Standardwerte (z. B. leere Nachschlagelisten, Standardoptionswerte), um Platzhaltereinträge einzufügen und GUIDs zu erfassen.

5. Statusaktualisierungen: Legen Sie den aktiven Status nur während der ersten Datensatzeinfügung fest. Aktualisieren Sie sie für inaktive Datensätze oder benutzerdefinierte Statuscodes nach der Datenüberprüfung. Für die meisten benutzerdefinierten Tabellen können Statusaktualisierungen unmittelbar nach dem Einfügen folgen. Bei besonderen Tabellen wie Fall, Verkaufschance oder Lead verzögern Sie Statusaktualisierungen jedoch bis zum Ende der Migration. Sobald diese Datensätze geschlossen wurden, können sie nur geändert werden, wenn sie erneut geöffnet werden – ein zeitaufwändiger Prozess, der die Datenintegrität gefährdet.

6. Besitz und Sicherheit: Legen Sie während der Dateneinfügung den richtigen Datensatzbesitzer fest, da sowohl die Sicherheit auf Benutzerebene als auch die Sicherheit der Geschäftseinheiten in Dataverse an die Geschäftseinheit des Besitzers gebunden sind. Weisen Sie die richtige Geschäftseinheit bei der Erstellung zu – wenn Sie diese nachträglich ändern, werden alle Sicherheitsrollen entfernt.

   • Verwenden Sie Stub-Benutzer:
     • Dataverse unterstützt Stubbenutzer (nicht lizenziert), die für große oder historische Migrationen nützlich sind. Stub-Benutzer werden automatisch der Sicherheitsrolle "Vertriebsmitarbeiter" zugewiesen– benennen Sie diese Rolle nicht um oder ändern Sie diese Rolle. Stub-Benutzer können Datensätze besitzen, wenn sie Lesezugriff auf Benutzerebene auf die relevanten Tabellen haben.
   • Empfehlungen:
     • Erstellen Sie während der Migration alle nicht lizenzierten Benutzer, wobei die richtige Geschäftseinheit zum Zeitpunkt der Eingabe festgelegt wird.
     • Ändern Sie die Geschäftseinheit nach der Erstellung nicht. Dadurch werden alle Rollen entfernt, einschließlich Vertriebsmitarbeiter.
     • Stellen Sie sicher, dass die Rolle "Vertriebsmitarbeiter" Lesezugriff auf alle migrationsberechtigten Tabellen hat.
     • Auch Benutzer, die in der Dataverse-Umgebung mit dieser Rolle deaktiviert sind, können Datensätze besitzen.

7. Währungsbehandlung: Legen Sie wechselkurse während des Einfügens mithilfe eines Vorvalidierungs-Plug-Ins fest, da Dataverse historische Kurse nicht unterstützt.

Datenlast in Dataverse veröffentlichen

Führen Sie nach dem Laden von Daten in Dataverse die folgenden Schritte aus, um die Datenintegrität sicherzustellen und nachgelagerte Probleme zu minimieren:

1. Aktualisieren der Haupttabelle mit GUIDs:

   • Kopieren Sie nach einem erfolgreichen Laden die Dataverse-Datensatz-GUIDs aus der Erfolgstabelle in die Haupttabelle, indem Sie einen eindeutigen Bezeichner wie importsequencenumber verwenden.
   • Aktualisieren Sie das Verarbeitungskennzeichen, um Datensätze als:
     • P – bearbeitet
     • E – Fehlerzustand
     • U – Unverarbeitet Diese Strategie ermöglicht effiziente Wiederholungen, indem bereits verarbeitete Datensätze übersprungen werden und unterstützt die Nachschlageauflösung in nachfolgenden Ladevorgängen.

2. Wiederholung fehlgeschlagener Datensätze: Um die Überarbeitung zu reduzieren und referenzielle Integrität beizubehalten, sollten Sie die folgenden Aktionen in Betracht ziehen:

   • Kürzen Sie Zeichenfolgenwerte, wenn sie die zulässigen Längen überschreiten.
   • Verwenden Sie Standardoptionswerte, wenn Zuordnungen fehlen.
   • Weisen Sie einen Fallbackbesitzer zu, wenn der ursprüngliche Besitzer nicht verfügbar ist (auch als Stubbenutzer).
   • ** Verwenden Sie leere oder Standardwerte für unaufgelöste Abfragen.
   • Sogar Platzhaltereinträge können beim Generieren von GUIDs helfen, die für Nachschlagevorgänge in verknüpften Tabellen erforderlich sind.

Verwenden von elastischen Tabellen für die Datenmigration

Flexible Tabellen sind so konzipiert, dass große Datenmengen in Echtzeit verarbeitet werden. Mit elastischen Tabellen können Sie große Volumes von Daten importieren, speichern und analysieren, ohne dass es zu Skalierbarkeits-, Latenz- oder Leistungsproblemen kommt.

Flexible Tabellen bieten einzigartige Funktionen für flexible Schemas, horizontale Skalierung und automatische Entfernung von Daten nach einem bestimmten Zeitraum.

Elastische Tabellen werden in Azure Cosmos DB gespeichert und unterstützen:

• Schemalose Daten über JSON-Spalten
• Automatische horizontale Skalierung
• Time-to-Live (TTL) zum automatischen Löschen veralteter Daten
• Partitionierung zur Leistungsoptimierung

Flexible Tabellen eignen sich am besten für Massenimporte mit variablem Schema.

Empfohlene Datentypen für elastische Tabellen während der Datenmigration

Elastische Tabellen eignen sich ideal für bestimmte Datentypen.

Datentypen, die für elastische Tabellen ungeeignet sind

Flexible Tabellen sind für flexible szenarien mit hoher Skalierung optimiert – aber nicht jeder Datentyp passt. In diesem Abschnitt werden allgemeine CRM-Datenmuster hervorgehoben, die an anderer Stelle besser gespeichert werden, um Die Leistung, Kosteneffizienz und Wartung sicherzustellen. Weitere Informationen zu Features, die derzeit nicht mit elastischen Tabellen unterstützt werden

Funktionale Datensegmentierung und Archivierungsframework

Eine effektive technische Planung umfasst die Auswahl der richtigen Tools und Infrastruktur, das Ausrichten von Quell- und Zieldatenvolumes sowie das Einrichten von Überwachungs- und Abstimmungsprozessen. Viele Migrationen werden aufgrund einer fehlenden Vorabanalyse komplex, insbesondere bei der Bestimmung, welche Daten verschoben werden müssen und wo sie hingehören. In diesem Abschnitt werden die Kernprinzipien der Datenanalyse beschrieben, um eine erfolgreiche Migration zu unterstützen.

Datensegmentierung

Die Datensegmentierung ist ein wichtiger Schritt bei der Migration von einem CRM-System zu Dataverse. Organisieren Sie Datentabellen nach Geschäftsfunktion wie Vertrieb, Service oder Marketing, um die Migrationsplanung und -ausführung zu vereinfachen.

Tabellensegmentierung

Beginnen Sie, indem Sie alle Tabellen auflisten, die für die Migration berechtigt sind, gruppiert nach Geschäftsbereich (z. B. Vertrieb, Marketing, Service). Führen Sie dann folgende Schritte aus:

• Dokumentieren Sie das Schema in Excel oder einem ähnlichen Tool.
• Führen Sie grundlegende Abfragen im Quellsystem aus, um die Spaltennutzung zu überprüfen.
• Kennzeichnen von Spalten mit geringer Nutzung. Wenn weniger als 5% Datensätze Werte enthalten, wenden Sie sich an die Geschäftsbeteiligten, um zu entscheiden, ob sie beibehalten oder verworfen werden sollen.

Diese einfache Analyse kann den Migrationsumfang erheblich reduzieren. In langfristigen CRM-Systemen ist es üblich, 30 bis 40 % der Spalten zu eliminieren und bis zu 20 % von den Tabellen zu entfernen, um den Prozess zu verschlanken und die Leistung zu verbessern.

Relevanz von Spalten

Einige Spalten des Quellsystems werden direkt dem Dataverse zugeordnet, während andere zu berechneten Feldern werden. Trennen Sie diese Spalten, und wenden Sie sich an die Projektbeteiligten, um zu entscheiden, ob Migrationsaufträge erforderlich sind.

Ignorieren Sie Spalten, die nur im Quellsystem relevant sind oder im Ziel nicht aussagekräftig sind. Dies umfasst viele sofort einsatzbereite Felder wie Erstellt von, Geändert von oder Zeilenversionsnummer, es sei denn, sie dienen einem bestimmten Zweck in Ihrer Migration.

Dateitypdaten

Wenn Ihr Quellsystem Dateitypdaten enthält, kennzeichnen Sie diese Felder frühzeitig, und planen Sie eine separate Migrationsstrategie. Berücksichtigen Sie die folgenden Dateitypen:

• Office-Dokumente (z. B. Word, Excel, PowerPoint): Für bis zu 20.000 Dateien migrieren Sie zu einer Plattform für die Zusammenarbeit wie SharePoint, um den Mehrbenutzerzugriff zu ermöglichen.
• Multimediadateien (z. B. Bilder, Videos): Wählen Sie eine Plattform aus, die die Wiedergabe unterstützt. Zu den Optionen gehören SharePoint, Streamingdienste oder andere medienfreundliche Speicherlösungen.
• Große Volumes oder Dateigrößen: Wenn Speicherkosten ein Problem darstellen, verwenden Sie Azure Blob Storage oder die native Dateispalte in Dataverse, die Azure Blob hinter den Kulissen verwendet.
• Schutz vor Schadsoftware: Führen Sie Dateien über ein Schadsoftwareerkennungstool (z. B. Azure Advanced Threat Protection) vor der Migration aus, um die Sicherheit zu gewährleisten.

Nach der Überprüfung der Dateirelevanz stellen Sie häufig fest, dass das Gesamtdatenvolumen – insbesondere bei langfristigen CRM-Systemen – erheblich sinkt, wodurch die Migration effizienter wird.

Strategien zur Datenarchivierung

Einige Daten – z. B. alte E-Mails, geschlossene Fälle oder disqualifizierte Leads – bleiben wichtig, aber nur selten darauf zugegriffen. Um das Migrationsvolumen zu reduzieren, ohne Geschäftsvorgänge zu unterbrechen, entwickeln Sie eine intelligente Archivierungsstrategie.

Schritt 1: Identifizieren archivierter Daten

Zu den gängigen Kandidaten gehören:

• E-Mails, die älter als drei Jahre sind
• Geschlossene Fälle
• Verlorene Chancen
• Disqualifizierte Leads
• Marketing-E-Mails, Beiträge und Überwachungsprotokolle

Überprüfen Sie Ihr System, um andere Tabellen zu identifizieren, die Sie archivieren können.

Schritt 2: Auswählen eines Archivierungsansatzes

• Behalten Sie Daten im Quellsystem bei. Behalten Sie einige Administratorlizenzen für den Zugriff bei, während sie andere deaktivieren, um Kosten zu senken.
• Wechseln zum externen Speicher. Verwenden Sie lokale Datenbanken, Azure Blob Storage oder Azure-Tabellen, um archivierte Datensätze zu speichern. Dieser Ansatz reduziert Speicher- und Migrationskosten, erfordert jedoch eine separate Migrationsstrategie.
• Verwenden Sie eine separate Dataverse-Umgebung. Diese Option ist weniger häufig, aber es ist nützlich, wenn Sie archivierte Daten isolieren möchten. Sie können diese Umgebung später zurückziehen, um die Umstellungsplanung zu vereinfachen.

Empfohlene Datenmigrationsinfrastruktur

So stellen Sie eine schnelle und zuverlässige Datenmigration in Dataverse sicher:

• Verwenden Sie einen virtuellen Computer (VM) in derselben Region wie Ihre Dataverse-Umgebung, um die Latenz zu reduzieren und die Migrationsgeschwindigkeit zu verbessern.
• Wählen Sie eine leistungsfähige VM aus. Verwenden Sie mindestens eine D4-VM mit acht Kernen, 28 GB RAM und 500 GB Speicher, um große Datenvolumes effizient zu verarbeiten.
• Bevorzugen Sie eine lokale Datenbank auf dem virtuellen Computer. Vermeiden Sie Remoteverbindungen während der Migration. Wenn Sie Azure Data Factory verwenden, stellen Sie sie in derselben Region wie Ihre Dataverse-Umgebung bereit, um eine optimale Leistung zu erzielen.

Nächster Schritt