Migrieren Sie Altdaten, ohne sie zu vermasseln

Die Migration von Legacy-Daten ist schwierig.

Viele Organisationen haben alte und komplexe On-Premise-CRM-Systeme. Heutzutage gibt es viele Cloud-SaaS-Alternativen, die viele Vorteile bieten; Pay-as-you-go und zahlen nur für das, was Sie nutzen. Daher entscheiden sie sich für die Umstellung auf die neuen Systeme.

Niemand möchte wertvolle Daten über Kunden im alten System belassen und mit dem leeren neuen System beginnen, also müssen wir diese Daten migrieren. Leider ist die Datenmigration keine leichte Aufgabe, da etwa 50 Prozent des Bereitstellungsaufwands für Datenmigrationsaktivitäten aufgewendet werden. Laut Gartner ist Salesforce der führende Anbieter von Cloud-CRM-Lösungen. Daher ist die Datenmigration ein wichtiges Thema für die Salesforce-Bereitstellung.

Wie können wir also einen erfolgreichen Übergang von Legacy-Daten in ein glänzendes neues System sicherstellen und sicherstellen, dass wir seine gesamte Historie bewahren? In diesem Artikel gebe ich 10 Tipps für eine erfolgreiche Datenmigration. Die ersten fünf Tipps gelten für jede Datenmigration, unabhängig von der verwendeten Technologie.

Datenmigration im Allgemeinen

1. Machen Sie die Migration zu einem separaten Projekt

In der Checkliste für die Softwarebereitstellung ist die Datenmigration kein „Export- und Import“-Element, das von einem cleveren „Push-One-Button“-Datenmigrationstool mit vordefinierter Zuordnung für Zielsysteme durchgeführt wird.

Die Datenmigration ist eine komplexe Aktivität, die ein separates Projekt, einen separaten Plan, einen separaten Ansatz, ein separates Budget und ein separates Team verdient. Umfang und Plan auf Unternehmensebene müssen zu Beginn des Projekts erstellt werden, um Überraschungen wie „Oh, wir haben vergessen, die Besuchsberichte dieser Kunden zu laden, wer macht das?“ zu vermeiden. zwei Wochen vor Ablauf der Frist.

Der Datenmigrationsansatz definiert, ob wir die Daten auf einmal laden (auch als Big Bang bekannt) oder ob wir jede Woche kleine Stapel laden.

Dies ist jedoch keine leichte Entscheidung. Der Ansatz muss vereinbart und allen geschäftlichen und technischen Beteiligten mitgeteilt werden, damit jeder weiß, wann und welche Daten im neuen System erscheinen werden. Dies gilt auch für Systemausfälle.

2. Realistisch schätzen

Unterschätzen Sie nicht die Komplexität der Datenmigration. Viele zeitraubende Aufgaben begleiten diesen Prozess, der zu Beginn des Projekts möglicherweise unsichtbar ist.

Beispielsweise das Laden bestimmter Datensätze für Schulungszwecke mit einer Reihe realistischer Daten, aber mit verschleierten sensiblen Elementen, sodass bei Schulungsaktivitäten keine E-Mail-Benachrichtigungen an Kunden generiert werden.

Grundlegend für die Schätzung ist die Anzahl der Felder, die von einem Quellsystem in ein Zielsystem übertragen werden sollen.

In den verschiedenen Phasen des Projekts ist für jedes Feld etwas Zeit erforderlich, einschließlich des Verstehens des Felds, des Zuordnens des Quellfelds zum Zielfeld, des Konfigurierens oder Erstellens von Transformationen, des Durchführens von Tests, des Messens der Datenqualität für das Feld usw.

Durch den Einsatz cleverer Tools wie Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas und dergleichen kann diese Zeit verkürzt werden, insbesondere in der Build-Phase.

Insbesondere das Verständnis der Quelldaten – die wichtigste Aufgabe in jedem Migrationsprojekt – kann nicht durch Tools automatisiert werden, sondern erfordert, dass Analysten sich Zeit nehmen, um die Liste der Felder einzeln durchzugehen.

Die einfachste Schätzung des Gesamtaufwands ist ein Manntag für jedes Feld, das aus dem Altsystem übernommen wird.

Eine Ausnahme ist die Datenreplikation zwischen denselben Quell- und Zielschemas ohne weitere Transformation – manchmal auch als 1:1-Migration bezeichnet –, bei der wir die Schätzung auf der Anzahl der zu kopierenden Tabellen basieren können.

Eine detaillierte Schätzung ist eine Kunst für sich.

3. Datenqualität prüfen

Überschätzen Sie die Qualität der Quelldaten nicht, auch wenn keine Datenqualitätsprobleme aus den Altsystemen gemeldet werden.

Neue Systeme haben neue Regeln, die mit Altdaten verletzt werden können. Hier ist ein einfaches Beispiel. Die Kontakt-E-Mail kann im neuen System obligatorisch sein, aber ein 20 Jahre altes Altsystem hat möglicherweise eine andere Sichtweise.

In historischen Daten können Minen versteckt sein, die lange Zeit nicht angerührt wurden, aber bei der Übertragung auf das neue System aktiviert werden könnten. Beispielsweise müssen alte Daten mit nicht mehr existierenden europäischen Währungen in Euro umgerechnet werden, andernfalls müssen Währungen dem neuen System hinzugefügt werden.

Die Datenqualität beeinflusst den Aufwand erheblich, und die einfache Regel lautet: Je weiter wir in der Geschichte vordringen, desto mehr Chaos werden wir entdecken. Daher ist es wichtig, frühzeitig zu entscheiden, wie viel Geschichte wir in das neue System übertragen wollen.

4. Binden Sie Geschäftsleute ein

Geschäftsleute sind die einzigen, die die Daten wirklich verstehen und daher entscheiden können, welche Daten weggeworfen werden können und welche Daten behalten werden sollen.

Es ist wichtig, dass jemand aus dem Geschäftsteam während der Mapping-Übung beteiligt ist, und für zukünftige Rückverfolgungen ist es nützlich, Mapping-Entscheidungen und die Gründe dafür aufzuzeichnen.

Da ein Bild mehr sagt als tausend Worte, laden Sie einen Teststapel in das neue System und lassen Sie das Geschäftsteam damit spielen.

Selbst wenn das Datenmigrations-Mapping vom Geschäftsteam überprüft und genehmigt wird, können Überraschungen auftreten, sobald die Daten in der Benutzeroberfläche des neuen Systems angezeigt werden.

„Oh, jetzt verstehe ich, wir müssen das ein bisschen ändern“, wird zu einem gängigen Satz.

Das Versäumnis, Fachexperten zu engagieren, die normalerweise sehr beschäftigte Leute sind, ist die häufigste Ursache für Probleme, nachdem ein neues System in Betrieb genommen wurde.

5. Streben Sie eine automatisierte Migrationslösung an

Die Datenmigration wird oft als einmalige Aktivität angesehen, und Entwickler neigen dazu, Lösungen voller manueller Aktionen zu erhalten, in der Hoffnung, sie nur einmal auszuführen. Aber es gibt viele Gründe, einen solchen Ansatz zu vermeiden.

• Wenn die Migration in mehrere Wellen aufgeteilt wird, müssen wir die gleichen Aktionen mehrmals wiederholen.
• In der Regel gibt es für jede Welle mindestens drei Migrationsläufe: einen Probelauf zum Testen der Leistung und Funktionalität der Datenmigration, einen vollständigen Datenvalidierungsload zum Testen des gesamten Datensatzes und zum Durchführen von Geschäftstests und natürlich einen Produktionsload. Die Anzahl der Läufe steigt mit schlechter Datenqualität. Die Verbesserung der Datenqualität ist ein iterativer Prozess, daher benötigen wir mehrere Iterationen, um die gewünschte Erfolgsquote zu erreichen.

Selbst wenn die Migration naturgemäß eine einmalige Aktivität ist, können manuelle Maßnahmen Ihren Betrieb erheblich verlangsamen.

Salesforce-Datenmigration

Als Nächstes behandeln wir fünf Tipps für eine erfolgreiche Salesforce-Migration. Beachten Sie, dass diese Tipps wahrscheinlich auch für andere Cloud-Lösungen gelten.

6. Bereiten Sie sich auf lange Ladungen vor

Leistung ist einer der, wenn nicht sogar der größte Kompromiss beim Wechsel von einer On-Premise- zu einer Cloud-Lösung – Salesforce nicht ausgeschlossen.

On-Premise-Systeme ermöglichen normalerweise das direkte Laden von Daten in eine zugrunde liegende Datenbank, und mit guter Hardware können wir problemlos Millionen von Datensätzen pro Stunde erreichen.

Aber nicht in der Cloud. In der Cloud sind wir durch mehrere Faktoren stark eingeschränkt.

• Netzwerklatenz – Daten werden über das Internet übertragen.
• Salesforce-Anwendungsschicht – Daten werden durch eine dicke API-Mehrmandantenschicht verschoben, bis sie in ihren Oracle-Datenbanken landen.
• Benutzerdefinierter Code in Salesforce – Benutzerdefinierte Validierungen, Trigger, Workflows, Duplikaterkennungsregeln usw. – viele davon deaktivieren parallele oder Massenladevorgänge.

Infolgedessen kann die Ladeleistung Tausende von Konten pro Stunde betragen.

Es kann weniger oder mehr sein, abhängig von Dingen wie der Anzahl der Felder, Validierungen und Trigger. Aber es ist einige Grade langsamer als ein direktes Laden der Datenbank.

Auch Leistungseinbußen, die von der Datenmenge in Salesforce abhängig sind, müssen berücksichtigt werden.

Es wird durch Indizes im zugrunde liegenden RDBMS (Oracle) verursacht, die zum Überprüfen von Fremdschlüsseln, eindeutigen Feldern und zum Auswerten von Duplizierungsregeln verwendet werden. Die Grundformel lautet ungefähr 50 Prozent Verlangsamung für jeden Grad von 10, verursacht durch O(logN), den Zeitkomplexitätsanteil bei Sortier- und B-Baum-Operationen.

Darüber hinaus hat Salesforce viele Ressourcennutzungsbeschränkungen.

Eines davon ist das Bulk-API-Limit, das auf 5.000 Batches in rollierenden 24-Stunden-Fenstern festgelegt ist, mit einem Maximum von 10.000 Datensätzen in jedem Batch.

Das theoretische Maximum liegt also bei 50 Millionen Datensätzen, die in 24 Stunden geladen werden.

In einem realen Projekt ist das Maximum aufgrund der begrenzten Stapelgröße viel niedriger, wenn beispielsweise benutzerdefinierte Trigger verwendet werden.

Dies wirkt sich stark auf den Datenmigrationsansatz aus.

Selbst für mittelgroße Datensätze (von 100.000 bis 1 Million Konten) kommt der Big-Bang-Ansatz nicht in Frage, daher müssen wir Daten in kleinere Migrationswellen aufteilen.

Dies wirkt sich natürlich auf den gesamten Bereitstellungsprozess aus und erhöht die Migrationskomplexität, da wir Dateninkremente in ein System einfügen werden, das bereits mit früheren Migrationen und von Benutzern eingegebenen Daten gefüllt ist.

Wir müssen diese vorhandenen Daten auch in den Migrationstransformationen und -validierungen berücksichtigen.

Darüber hinaus können lange Lasten bedeuten, dass wir Migrationen während eines Systemausfalls nicht durchführen können.

Wenn sich alle Benutzer in einem Land befinden, können wir einen achtstündigen Ausfall während der Nacht nutzen.

Aber für ein weltweit tätiges Unternehmen wie Coca-Cola ist das nicht möglich. Sobald wir die USA, Japan und Europa im System haben, umfassen wir alle Zeitzonen, sodass der Samstag die einzige Ausfalloption ist, die die Benutzer nicht betrifft.

Und das reicht möglicherweise nicht aus, also müssen wir online laden, wenn Benutzer mit dem System arbeiten.

7. Respektieren Sie Migrationsanforderungen in der Anwendungsentwicklung

Anwendungskomponenten wie Validierungen und Trigger sollten in der Lage sein, Datenmigrationsaktivitäten zu handhaben. Die endgültige Deaktivierung von Validierungen zum Zeitpunkt des Migrationsladens ist keine Option, wenn das System online sein muss. Stattdessen müssen wir eine andere Logik in Validierungen für Änderungen implementieren, die von einem Datenmigrationsbenutzer durchgeführt werden.

• Datumsfelder sollten nicht mit dem tatsächlichen Systemdatum verglichen werden, da dies das Laden historischer Daten verhindern würde. Beispielsweise muss die Validierung die Eingabe eines vergangenen Kontostartdatums für migrierte Daten ermöglichen.
• Pflichtfelder, die nicht mit historischen Daten gefüllt werden dürfen, müssen als nicht obligatorisch implementiert werden, aber mit einer für den Benutzer sensiblen Validierung, wodurch leere Werte für Daten aus der Migration zugelassen, aber leere Werte abgelehnt werden, die von normalen Benutzern über die GUI stammen .
• Auslöser, insbesondere solche, die neue Datensätze an die Integration senden, müssen für den Benutzer der Datenmigration ein- und ausgeschaltet werden können, um zu verhindern, dass die Integration mit migrierten Daten überschwemmt wird.

Ein weiterer Trick besteht darin, in jedem migrierten Objekt das Feld Legacy-ID oder Migrations-ID zu verwenden. Dafür gibt es zwei Gründe. Das erste liegt auf der Hand: Die ID aus dem alten System für die Rückverfolgung zu behalten; Nachdem sich die Daten im neuen System befinden, möchten die Benutzer möglicherweise immer noch ihre Konten mit den alten IDs durchsuchen, die an Orten wie E-Mails, Dokumenten und Fehlerverfolgungssystemen zu finden sind. Schlechte Angewohnheit? Vielleicht. Aber die Benutzer werden es Ihnen danken, wenn Sie ihre alten IDs beibehalten. Der zweite Grund ist technischer Natur und ergibt sich aus der Tatsache, dass Salesforce keine explizit bereitgestellten IDs für neue Datensätze akzeptiert (im Gegensatz zu Microsoft Dynamics), sondern diese während des Ladens generiert. Das Problem entsteht, wenn wir untergeordnete Objekte laden wollen, da wir ihnen IDs der übergeordneten Objekte zuweisen müssen. Da wir diese IDs erst nach dem Laden kennen, ist dies eine vergebliche Übung.

Verwenden wir zum Beispiel Konten und ihre Kontakte:

1. Generieren Sie Daten für Konten.
2. Laden Sie Konten in Salesforce und erhalten Sie generierte IDs.
3. Integrieren Sie neue Konto-IDs in die Kontaktdaten.
4. Generieren Sie Daten für Kontakte.
5. Kontakte in Salesforce laden.

Wir können dies einfacher tun, indem wir Konten mit ihren Legacy-IDs laden, die in einem speziellen externen Feld gespeichert sind. Dieses Feld kann als übergeordnete Referenz verwendet werden, sodass wir beim Laden von Kontakten einfach die Konto-Legacy-ID als Verweis auf das übergeordnete Konto verwenden:

1. Generieren Sie Daten für Konten, einschließlich Legacy-ID.
2. Generieren Sie Daten für Kontakte, einschließlich Konto-Legacy-ID.
3. Konten in Salesforce laden.
4. Laden Sie Kontakte in Salesforce und verwenden Sie die Legacy-Konto-ID als übergeordnete Referenz.

Das Schöne hier ist, dass wir eine Generierungs- und eine Ladephase getrennt haben, was eine bessere Parallelität ermöglicht, Ausfallzeiten verkürzt und so weiter.

8. Beachten Sie die Salesforce-spezifischen Funktionen

Wie jedes System hat Salesforce viele knifflige Teile, die wir kennen sollten, um unangenehme Überraschungen während der Datenmigration zu vermeiden. Hier sind einige Beispiele:

• Einige Änderungen an aktiven Benutzern generieren automatisch E-Mail-Benachrichtigungen an Benutzer-E-Mails. Wenn wir also mit Benutzerdaten spielen wollen, müssen wir Benutzer zuerst deaktivieren und aktivieren, nachdem die Änderungen abgeschlossen sind. In Testumgebungen verschlüsseln wir Benutzer-E-Mails, sodass überhaupt keine Benachrichtigungen ausgelöst werden. Da aktive Benutzer teure Lizenzen verbrauchen, können wir nicht alle Benutzer in allen Testumgebungen aktiv haben. Wir müssen beispielsweise Teilmengen aktiver Benutzer verwalten, um nur diese in einer Schulungsumgebung zu aktivieren.
• Inaktive Benutzer können für einige Standardobjekte wie Konto oder Fall nur zugewiesen werden, nachdem die Systemberechtigung „Datensätze mit inaktiven Eigentümern aktualisieren“ erteilt wurde, aber sie können beispielsweise Kontakten und allen benutzerdefinierten Objekten zugewiesen werden.
• Wenn der Kontakt deaktiviert ist, werden alle Opt-out-Felder stillschweigend aktiviert.
• Beim Laden eines doppelten Account Team Member- oder Account Share-Objekts wird der vorhandene Datensatz stillschweigend überschrieben. Beim Laden eines doppelten Opportunity-Partners wird der Datensatz jedoch einfach hinzugefügt, was zu einem Duplikat führt.
• Systemfelder wie Erstellungsdatum , Created Date Created By ID , Last Modified Date , Last Modified By ID , können nur explizit geschrieben werden, nachdem eine neue Systemberechtigung „Audit-Felder bei Datensatzerstellung festlegen“ erteilt wurde.
• Der Verlauf von Feldwertänderungen kann überhaupt nicht migriert werden.
• Eigentümer von Wissensartikeln können während des Ladevorgangs nicht angegeben, aber später aktualisiert werden.
• Der knifflige Teil ist das Speichern von Inhalten (Dokumente, Anhänge) in Salesforce. Es gibt mehrere Möglichkeiten, dies zu tun (mit Anhängen, Dateien, Feed-Anhängen, Dokumenten), und jede Methode hat ihre Vor- und Nachteile, einschließlich unterschiedlicher Dateigrößenbeschränkungen.
• Auswahllistenfelder zwingen Benutzer, einen der zulässigen Werte auszuwählen, beispielsweise einen Kontotyp. Aber wenn Daten mit der Salesforce-API (oder einem darauf aufbauenden Tool wie Apex Data Loader oder Informatica Salesforce Connector) geladen werden, wird jeder Wert übergeben.

Die Liste geht weiter, aber das Fazit lautet: Machen Sie sich mit dem System vertraut und lernen Sie, was es kann und was es nicht kann, bevor Sie Vermutungen anstellen. Gehen Sie nicht von Standardverhalten aus, insbesondere nicht für Kernobjekte. Immer recherchieren und testen.

9. Verwenden Sie Salesforce nicht als Datenmigrationsplattform

Es ist sehr verlockend, Salesforce als Plattform zum Erstellen einer Datenmigrationslösung zu verwenden, insbesondere für Salesforce-Entwickler. Es ist dieselbe Technologie für die Datenmigrationslösung wie für die Salesforce-Anwendungsanpassung, dieselbe GUI, dieselbe Apex-Programmiersprache, dieselbe Infrastruktur. Salesforce verfügt über Objekte, die als Tabellen fungieren können, und eine Art SQL-Sprache, Salesforce Object Query Language (SOQL). Bitte verwenden Sie es jedoch nicht; es wäre ein grundlegender architektonischer Fehler.

Salesforce ist eine ausgezeichnete SaaS-Anwendung mit vielen netten Funktionen wie erweiterter Zusammenarbeit und umfassender Anpassung, aber die Massenverarbeitung von Daten gehört nicht dazu. Die drei wichtigsten Gründe sind:

• Leistung – Die Verarbeitung von Daten in Salesforce ist mehrere Stufen langsamer als in RDBMS.
• Fehlende Analysefunktionen – Salesforce SOQL unterstützt keine komplexen Abfragen und Analysefunktionen, die von der Apex-Sprache unterstützt werden müssen, und würde die Leistung noch weiter beeinträchtigen.
• Architektur * – Es ist nicht sehr praktisch, eine Datenmigrationsplattform in eine bestimmte Salesforce-Umgebung zu integrieren. Normalerweise haben wir mehrere Umgebungen für bestimmte Zwecke, die oft ad hoc erstellt werden, damit wir viel Zeit für die Codesynchronisierung aufwenden können. Außerdem würden Sie sich auch auf die Konnektivität und Verfügbarkeit dieser speziellen Salesforce-Umgebung verlassen.

Erstellen Sie stattdessen mithilfe einer RDBMS- oder ETL-Plattform eine Datenmigrationslösung in einer separaten Instanz (es könnte sich um eine Cloud oder eine On-Premise-Instanz handeln). Verbinden Sie es mit Quellsystemen und zielen Sie auf die gewünschten Salesforce-Umgebungen ab, verschieben Sie die benötigten Daten in Ihren Staging-Bereich und verarbeiten Sie sie dort. Dadurch können Sie:

• Nutzen Sie die volle Leistung und die Möglichkeiten der SQL-Sprache oder der ETL-Funktionen.
• Haben Sie alle Codes und Daten an einem Ort, damit Sie Analysen über alle Systeme hinweg durchführen können.
  • Sie können beispielsweise die neueste Konfiguration aus der aktuellsten Salesforce-Testumgebung mit realen Daten aus der Salesforce-Produktionsumgebung kombinieren.
• Sie sind unabhängiger von der Technologie der Quell- und Zielsysteme und können Ihre Lösung für das nächste Projekt wiederverwenden.

10. Überwachung von Salesforce-Metadaten

Zu Beginn des Projekts holen wir uns normalerweise eine Liste mit Salesforce-Feldern und beginnen mit der Mapping-Übung. Während des Projekts kommt es häufig vor, dass das Anwendungsentwicklungsteam neue Felder in Salesforce hinzufügt oder dass einige Feldeigenschaften geändert werden. Wir können das Anwendungsteam bitten, das Datenmigrationsteam über jede Datenmodelländerung zu informieren, aber das funktioniert nicht immer. Sicherheitshalber müssen wir alle Datenmodelländerungen unter Aufsicht haben.

Eine gängige Methode hierfür besteht darin, regelmäßig migrationsrelevante Metadaten von Salesforce in ein Metadaten-Repository herunterzuladen. Sobald wir diese haben, können wir nicht nur Änderungen im Datenmodell erkennen, sondern auch Datenmodelle zweier Salesforce-Umgebungen vergleichen.

Welche Metadaten zum Herunterladen:

• Eine Liste von Objekten mit ihren Bezeichnungen und technischen Namen und Attributen wie creatable oder updatable .
• Eine Liste von Feldern mit ihren Attributen (besser alle).
• Eine Liste mit Auswahllistenwerten für Auswahllistenfelder. Wir benötigen sie, um Eingabedaten auf korrekte Werte abzubilden oder zu validieren.
• Eine Liste von Validierungen, um sicherzustellen, dass neue Validierungen keine Probleme für migrierte Daten verursachen.

Wie lade ich Metadaten von Salesforce herunter? Nun, es gibt keine Standardmethode für Metadaten, aber es gibt mehrere Optionen:

• Unternehmens-WSDL generieren – Navigieren Sie in der Salesforce-Webanwendung zum Setup / API -Menü und laden Sie die stark typisierte Unternehmens-WSDL herunter, die alle Objekte und Felder in Salesforce beschreibt (aber keine Auswahllistenwerte oder Validierungen).
• Rufen Sie den Salesforce- describeSObjects -Webdienst direkt oder mithilfe des Java- oder C#-Wrappers auf (siehe Salesforce-API). Auf diese Weise erhalten Sie, was Sie brauchen, und dies ist die empfohlene Methode zum Exportieren der Metadaten.
• Verwenden Sie eines der zahlreichen alternativen Tools, die im Internet verfügbar sind.

Bereiten Sie sich auf die nächste Datenmigration vor

Cloud-Lösungen wie Salesforce sind sofort einsatzbereit. Wenn Sie mit den integrierten Funktionen zufrieden sind, melden Sie sich einfach an und verwenden Sie sie. Salesforce bringt jedoch, wie jede andere Cloud-CRM-Lösung, spezifische Probleme mit sich, die bei Datenmigrationsthemen zu beachten sind, insbesondere in Bezug auf die Leistungs- und Ressourcengrenzen.

Das Verschieben von Altdaten in das neue System ist immer eine Reise, manchmal eine Reise in die Vergangenheit, die in Daten aus vergangenen Jahren verborgen ist. In diesem Artikel habe ich, basierend auf einem Dutzend Migrationsprojekten, zehn Tipps vorgestellt, wie Sie Altdaten migrieren und die meisten Fallstricke erfolgreich vermeiden können.

Der Schlüssel ist, zu verstehen, was die Daten offenbaren. Bevor Sie also mit der Datenmigration beginnen, stellen Sie sicher, dass Ihr Salesforce-Entwicklungsteam gut auf die potenziellen Probleme vorbereitet ist, die Ihre Daten möglicherweise enthalten.