CAFM: Migrationstooling/ETL-Pipelines aufbauen

Ein bewährtes Architekturprinzip ist ein mehrschichtiges Datenmodell (analoge „Medallion Architecture“): Daten durchlaufen typischerweise mindestens drei Ebenen – Rohdatenschicht (Bronze), Integrationsschicht (Silver) und Präsentationsschicht (Gold). In der Rohdatenschicht werden Daten aus verschiedenen Quellsystemen extrahiert und unverändert abgelegt. Anschließend erfolgt in der Staging- oder Integrationsschicht die Bereinigung, Harmonisierung und Historisierung der Daten. Hier kommt beispielsweise das Data-Vault-Modell zum Einsatz, das Daten stark normalisiert (mit Hubs, Links, Satellites) speichert und so hohe Flexibilität und Versionskontrolle bietet. In der obersten Präsentationsschicht werden die Daten letztlich für Berichte und Analysen aufbereitet – oft durch ein Sternschema, bei dem zentrale Faktentabellen von Dimensionstabellen umgeben sind.

Batch-ETL („Nightly Load“) ist im CAFM-Umfeld verbreitet, insbesondere für initiale Migrationsläufe. In modernen Szenarien können jedoch auch Streaming-Ansätze sinnvoll sein – etwa wenn Sensordaten aus Smart-Building-Systemen oder Echtzeit-Asset-Bewegungen kontinuierlich synchronisiert werden müssen. Hier eignen sich Tools wie Apache NiFi, das „echte Streaming-Szenarien“ unterstützt (IoT, Event-Logging) und extrem niedrige Latenzen ermöglicht. NiFi und ähnliche Plattformen bieten eine visuelle Flow-Steuerung sowie eingebaute Datenherkunft (Data Lineage) und Ende-zu-Ende-Sicherheit (zweiseitiges SSL, Verschlüsselung).

Im klassischen Batch-Prozess dominiert dagegen das sequenzielle ETL, häufig gesteuert durch Workflow-Orchestratoren (z.B. Airflow, Prefect). Ein orchestrierter Ansatz gibt Struktur: Er definiert Abhängigkeiten, kann Backfills und Retry-Strategien automatisch ausführen und liefert integriertes Monitoring sowie Audit-Trails für Pipeline-Läufe. Die Wahl der Architektur (Batch vs. Streaming, Data-Vault vs. Sternschema) hängt letztlich von den Projektanforderungen ab – etwa Datenvolumen, Aktualisierungsfrequenz und Nachvollziehbarkeit. Insbesondere in großen Projekten hat sich ein mehrschichtiger Daten-Warehousing-Ansatz bewährt: Die Trennung in Extraction-, Staging- und Präsentationsschicht erleichtert Pflege und Erweiterung der Pipeline.

• Extract (Datenextraktion): In dieser Phase werden Daten aus den Quellsystemen entnommen – z.B. aus Altsystem-Datenbanken, Excel-Dateien oder CSV-Exports. Typischerweise liest man Felder und Datensätze mittels Datenbankabfragen, ODBC/JDBC-Konnektoren oder Datei-Importkomponenten ein. Bei heterogenen Quellen ist eine vorausgehende Analyse sinnvoll, um Volumen, Formate und Qualität zu erfassen (Data Profiling).

• Staging (Temporäre Speicherung): Die rohen Quelldaten werden zunächst in einer Staging-Umgebung zwischengespeichert – meist eine dedizierte Datenbank oder Cloud-Storage. Dort beginnt die Datenbereinigung: Dubletten werden entfernt, fehlende Werte ergänzt oder standardisiert, Inkonsistenzen aufgedeckt. Ein Beispiel: Felder wie „Gebäudename“ oder „Raumnummer“ werden normiert, verschiedene Bezeichnungen in eine einheitliche Form überführt. Hier werden auch notwendige Metadaten-Strukturen erstellt (z.B. Tabellen für Neubegriffe). In dieser Phase erfolgt auch das Mapping zwischen Alt- und Neufeldern: Über ein Daten-Mapping wird für jedes Quellfeld bestimmt, in welches Ziel-Feld des CAFM-Systems es gehört. Ein typischer Ansatz ist ein Migrations-Template oder Mapping-Dokument, das die Feldzuordnungen zusammenfasst.

• Transform (Datenumwandlung): Basierend auf dem Mapping werden die Rohdaten in das Zielformt gebracht. Das umfasst Formatkonvertierungen (z.B. Datumsformate, Einheiten), Berechnungen (z.B. Aufsummierung von Kosten), das Erzeugen von Surrogatschlüsseln oder die Anwendung von Geschäftsregeln (z.B. Statusumkodierungen). Je nach Modell (Data Vault oder Sternschema) können hier Hub- und Link-Tabellen befüllt oder Dimensionsspalten neu berechnet werden. Typischerweise aktualisiert man zuerst die Dimensionstabellen (z.B. Gebäude, Anlagenarten) und danach die Faktentabellen (z.B. Anlagen, Wartungsaufträge) für ein konsistentes Schema. Transformationstools wie Talend oder Pentaho bieten hierfür Drag-&-Drop-Komponenten (z.B. tMap, Merge, Lookup), in denen diese Logik abgebildet wird.

• Load (Laden in das Zielsystem): Die transformierten Daten werden in das neue CAFM-System eingespielt. Das kann über direkte Datenbankverbindungen (Insert/Update) oder über die vorgesehenen Import-Schnittstellen des CAFM erfolgen (z.B. CSV-/XML-Import oder REST-API). Viele CAFM-Anbieter stellen Vorlagen (z.B. CSV-Tabellen) oder Web-Services zur Verfügung, in die man die bereinigten Daten überträgt. Ein Audit-Trail zeichnet idealerweise jeden Importschritt auf (wann, wer, wie viele Datensätze).

• Post-Load-Checks (Kontrolle): Nach dem Laden prüft man automatisiert die Datenintegrität und Vollständigkeit. Hierzu zählen Zeilen- und Summenvergleiche (z.B. Anzahl importierter Datensätze vs. Quelldatei), Prüfungen auf „verwaiste“ Fremdschlüssel, sowie fachliche Plausibilitätschecks (z.B. hat jedes Gebäude einen gültigen Standort). Abweichungen werden in Reportings oder Issue-Tracker geschrieben. Gegebenenfalls folgt ein zweiter Ladezyklus, um erkannte Probleme zu beheben. In der Praxis wird daher oft eine Teilmenge (Pilotmigration) initial eingespielt und validiert, bevor man die Gesamtmigration durchführt.

ETL-Tools müssen hohe Ansprüche erfüllen, um in CAFM-Migrationen zuverlässig zu funktionieren.

• Skalierbarkeit: Die Werkzeuge müssen große Datenvolumina verarbeiten können. Parallelisierung (Multi-Core, Cluster-Betrieb) und Batch-Loads sind wichtig, damit Millionen von Datensätzen in akzeptabler Zeit umgezogen werden. Viele Plattformen (z.B. NiFi, Talend) unterstützen verteilte Verarbeitung und Aufteilung in Partitionen.

• Wiederholbarkeit/Idempotenz: Eine ETL-Pipeline sollte bei Wiederholung derselben Eingabedaten stets das gleiche Ergebnis produzieren. Idempotente Loads ermöglichen es, fehlgeschlagene Durchläufe einfach erneut zu starten, ohne Duplikate zu erzeugen. Ein bewährtes Muster ist z.B. „Partition-Overwrite“, bei dem ganze Datenpartitionen (z.B. ein Tageszeitraum) überschrieben werden.

• Logging und Monitoring: Das Tool muss umfassend protokollieren (erfolgreich geladene Datensätze, Warnungen, Fehler). Ebenso wichtig sind Metriken – Laufzeiten, Durchsatz (Rows/s), zuletzt geladener Zeitstempel – um Engpässe zu erkennen. Viele Werkzeuge bieten eingebaute Logging-Mechanismen und Metrik-Dashboards; ansonsten sollte man Zieltabellen für Protokolle und Dashboards (z.B. in Grafana) vorsehen.

• Fehlerbehandlung/Rollback: Der ETL-Prozess muss bei Fehlern sicher abbrechen oder rückgängig machen können. Techniken sind z.B. Datenbank-Transaktionen (die einen Lade-Satz zurücksetzen), oder Zwischenspeicherung fehlerhafter Datensätze in einer Dead-Letter-Queue. Automatische Retry-Mechanismen helfen, flüchtige Verbindungsabbrüche oder API-Limits zu überbrücken.

• Versionierung und Governance: ETL-Jobs und -Skripte gehören in eine Versionsverwaltung (z.B. Git). Moderne Tools bieten oft sogenannte „Metadata Injection“ oder Projekt-Repositories, um Versionierung und Veränderungsmanagement zu unterstützen. So behält man den Überblick über Änderungen an Mapping-Definitionen oder Transformations-Logiken.

• Benutzerfreundlichkeit: Eine visuelle Benutzeroberfläche mit Drag&Drop erleichtert die Zusammenarbeit im Team. Gleichzeitig sollte das Tool Möglichkeiten zur Automatisierung (CLI, Scheduler-API) und Integration (Java, Python-Skripte) bieten, um komplexe Anforderungen abzubilden.

• Datenbanken: Hinter CAFM-Systemen stehen meist relationale Datenbanken (SQL Server, Oracle, PostgreSQL o.ä.) oder spezialisierte Datenbanken. ETL-Tools nutzen gängige Konnektoren (ODBC/JDBC) oder System-APIs (z.B. OData/SOAP) zur Datenabfrage. Für den Zugriff auf CAFM-spezifische Objekte wird häufig auf das offizielle REST-API des Systems zurückgegriffen (in JSON- oder XML-Format) oder auf CSV/Excel-Importfunktionen.

• Austauschformate: Häufig genutzte Formate sind CSV (kommagetrennte Textdateien) und XML oder JSON, insbesondere bei Web-API-Integrationen. CAFM-Anbieter liefern oft Templates (Excel/CSV) für Stammdaten (Gebäude, Räume, Assets). Darüber hinaus spielt im FM-Umfeld das COBie-Format eine zentrale Rolle: COBie (Construction-Operations Building Information Exchange) organisiert Gebäude- und Anlagendaten standardisiert in Tabellen (Excel/CSV) bzw. als IFC-Datei. Mit COBie können Hersteller bzw. Planer dem CAFM vorgefertigte Assets übergeben. Ebenso wichtig ist das IFC-Format (Industry Foundation Classes), ein offener, internationaler Standard (ISO 16739) für den Austausch von Gebäudemodelldaten. IFC-Dateien enthalten komplexe Objekt- und Geometriemodelle (etwa Raumvolumina), die mit spezialisierter Software (BIM-Tools) ausgelesen und für CAFM-Aufgaben weiterverwendet werden. Insgesamt muss das Migrations-Framework flexibel sein, um sämtliche relevanten Schnittstellen abzudecken – von direkten DB-Connectors über Dateiformate bis hin zu CAFM-nativen Importmodulen oder BIM-Standards.

• Logging von Ausführungsmetriken: Jede Pipeline-Run protokolliert Start- und Endzeiten, verarbeitete Datensatzanzahlen (extrahiert, transformiert, geladen, verworfen) und Status (Erfolg/Fehler). Mit solchen Metriken lassen sich Rückfragen schnell beantworten (z.B. „Wurden alle 10.000 Datensätze importiert?“) und Engpässe (z.B. besonders langsame Tasks) erkennen.

• Error Handling: Für temporäre Fehler (Netzwerkabbrüche, API-Timeouts) sollte die Pipeline mit Retry-Loops versehen sein (z.B. exponentielles Backoff). Bei dauerhaften Fehlern von Datensätzen (z.B. ungültiges Format) werden diese in eine Dead-Letter-Queue überführt, damit der Rest der Pipeline weiterläuft. Diese defekten Datensätze können später gesichtet und korrigiert werden.

• Schema-Validierung: Bereits im Staging werden Daten formal geprüft. Zum Beispiel selektiert das Skript explizit erwartete Spalten und wirft bei fehlenden Spalten ab, statt unbemerkt mit fehlerhaften Ergebnissen fortzufahren. So werden Inkonsistenzen im Datenmodell früh erkannt.

• Datenintegritätstests: Nach jedem Ladezyklus vergleicht man Schlüsselwerte zwischen Alt- und Neusystem – z.B. über Prüfsummen oder Hash-Vergleiche ganzer Tabellen. Diese Abgleiche (Reconciliation Reports) liefern sehr verlässliche Sicherheit, dass kein Datensatz verloren ging. Bei großen Datenmengen reicht oft schon eine statistische Stichprobe oder Summenvergleich, um auffällige Abweichungen zu entdecken.

• Idempotenz: Ein wesentlicher Qualitätsaspekt ist, dass ein fehlgeschlagener Lauf durch einen einfachen Re-Run korrigiert werden kann – ohne doppelte Inserts oder verlorene Daten. Hierzu wird z.B. vor dem Laden ein Cleanup in der Zielpartition vorgenommen, statt blind zu appendieren. Dadurch kann ein Teil-Lauf (z.B. für ein Wochenende) problemlos wiederholt werden, wenn ein Fehler auftrat.

Durch diese Maßnahmen kann die Migration weitgehend automatisiert ablaufen, ohne dass „stille Fehler“ erst nach Go-Live auffallen. Zur Qualitätssicherung gehören auch Regressionstests der Zielanwendung: Funktioniert nach Datenimport noch alles? Berichte und Workflows werden mit Testdatensätzen validiert. Insgesamt entsteht so eine „bulletproof“ Pipeline, die bei Problemen entweder automatisch reagiert oder ein klares Warnsignal sendet.

Ohne Monitoring droht ein stiller Ausfall der Pipeline. Daher werden Dashboards eingesetzt, die wesentliche Kennzahlen visualisieren: Abarbeitungsgeschwindigkeit (Durchsatz), Fehlerraten, Latenzzeiten und Daten-Freshness. Moderne ETL-Tools oder Orchestratoren bieten meist eine Weboberfläche mit Statusreports und Alarmierungsfunktionen (z.B. E-Mail-Alerts bei abgebrochenen Jobs). Zusätzlich kann man eigene Überwachungsskripte einsetzen, etwa SQL-Abfragen, die prüfen, ob neue Daten frischer als ein definierter Schwellenwert sind.

Performance-Tuning erfolgt auf mehreren Ebenen. In der Datenbank legt man etwa Indexe oder Partitionen an, um Lade- und Abfragezeiten zu beschleunigen. Im ETL-Tool konfiguriert man Parallelität (z.B. Multi-Threading von Tasks) und Batch-Größen. Beim Echtzeit-Streaming kann man NiFi-Cluster skalieren – jeder neue Node erhöht den Durchsatz nahezu linear. Oft verbessert auch eine Zwischenspeicherung (Caching) die Geschwindigkeit, z.B. wenn dieselben Referenzdaten mehrfach abgerufen werden. In der Praxis zeigt sich, dass sich schrittweises „Profiling“ (Pipelines einmal im Profiling-Modus laufen lassen) lohnt, um Engpass-Stationen zu identifizieren und gezielt zu optimieren.

Für den Betrieb wird häufig ein dediziertes Betriebsteam vorgesehen, das den täglichen ETL-Kalender verwaltet. Dazu gehören auch regelmäßige Backups der Staging- und Ziel-DBs sowie Notfall-Tests (Simulation eines Datenverlusts und Wiederherstellung). All diese Betriebsinformationen werden in einem zentralen Dokument oder Wiki festgehalten – von Benutzernamen und Passwörtern (die natürlich sicher verwahrt sind) bis zu Eskalationspfaden bei Problemen.

• Zugriffssteuerung: Nur berechtigte Nutzer dürfen ETL-Jobs editieren oder ausführen. Enterprise-ETL-Tools bieten Role-Based Access Control – Talend beispielsweise verfügt über Benutzer- und Rechteschemata für Entwickler und Admins. Auch NiFi kann Nutzerrollen definieren und Datenflüsse pro User einschränken. Auf Datenbankebene nutzt man ebenfalls sichere SQL-Login-Accounts mit minimalen Rechten (Prinzip der „least privilege“).

• Verschlüsselung: Daten in Bewegung (Data-in-Transit) müssen über TLS/SSL geschützt werden, etwa beim Abruf aus Web-APIs oder beim Schreiben in Cloud-Storage. Ebenfalls wichtig ist Verschlüsselung im Ruhezustand (Data-at-Rest) – beispielsweise können Staging-Datenbanken oder Extract-Dateien mit Verschlüsselung (Transparent Data Encryption oder GPG) gesichert werden. Viele Tools unterstützen automatisch HTTPS/SSL für alle Schnittstellen.

• Audit Trails: Jede Pipeline-Ausführung wird mit einem vollständigen Audit-Log dokumentiert – welche Daten wohin geladen wurden und von wem. So lässt sich im Nachhinein nachvollziehen, welcher Benutzer wann welchen Job ausgelöst hat und welche Daten betroffen waren. Das ist nicht nur für Compliance wichtig (z.B. ISO-Zertifizierungen), sondern auch für Debugging.

• Benutzerrollen: Im Migrationsteam sollten klare Rollen und Berechtigungen definiert sein. Nur ausgewählte Dateningenieure erhalten Vollzugriff auf Quellen und Ziele; andere Teammitglieder (z.B. QA) bekommen eine Lese- oder Validierungsrolle. Dieses Prinzip gilt auch innerhalb des CAFM-Tools nach der Migration: Datenbank-Accounts, Web-Login und API-Schlüssel müssen restriktiv vergeben und in Entwurfs-Logs festgehalten werden.

• Netzwerksicherheit: Zugehörige Infrastruktur wie VPNs oder Firewalls wird entsprechend konfiguriert. Beispielsweise sind Datenbank-Ports nur im internen Netz offen, und wenn man in die Cloud migriert, wird auf VPC-Subnetze geachtet. Solche Überlegungen liegen meist beim Security Engineer (siehe Rollenmodell).

Insgesamt wird Sicherheit nicht erst im letzten Schritt angeschaltet, sondern von Anfang an in die Pipeline-Planung integriert. So stellt man sicher, dass regulatorische Anforderungen (GDPR, ISO 27001, ggf. branchenspezifische Normen) während der gesamten Migration erfüllt bleiben.

• Projektleitung: Koordiniert das Gesamtprojekt (Zeitplan, Meilensteine, Budget). Sie legt die Struktur fest, stimmt Termine für Downtimes ab und kommuniziert mit Stakeholdern. Ein starker PM hält das Projekt synchron.

• Datenarchitekt / Datenmodelleur: Analysiert Quell- und Zielschema, erstellt das Mappings-Dokument und definiert Transformationsregeln. Er identifiziert Diskrepanzen (z.B. Datentypen, fehlende Felder) und legt fest, wie sie gelöst werden. Diese Rolle arbeitet eng mit dem Fachbereich zusammen, um sicherzustellen, dass keine wichtigen Daten verloren gehen.

• ETL-Entwickler / Data Engineer: Implementiert die Pipelines im gewählten Tool. Er setzt die vom Datenarchitekten definierten Mappings um, schreibt notwendige Skripte und sorgt dafür, dass die Jobs automatisiert lauffähig sind. Im Fehlerfall führt er Debugging durch und erweitert die Pipelines mit Logging und Retry-Mechanismen.

• CAFM-Fachberater (Business Analyst): Bringt das Domänenwissen ein. Er weiß, welche Daten geschäftskritisch sind, validiert die Feldzuordnungen (z.B. dass Raum-IDs korrekt übernommen werden) und prüft nach Abschluss der Migration, ob alle Geschäftsprozesse funktionieren (Berichte, Freigaben, Workflows). Dieser Stakeholder liefert Testfälle und akzeptiert am Ende die Migrationsergebnisse.

• QA/Test Engineer: Plant und führt Datenvalidierungen durch. Er entwickelt Testpläne, vergibt Prüfungen (z.B. Hash-Konsistenz, Datensatz-Vergleich) und erstellt automatisierte Tests, die nach jedem Lauf laufen. Sein Augenmerk gilt der Datenvollständigkeit und -integrität; er flaggt Abweichungen. Unternehmen mit eigenem QA-Team berichten von deutlich weniger Nachbesserungen dank intensiven Vorab-Tests.

• Security Engineer: Verifiziert Benutzerrechte und Verschlüsselungseinstellungen. Er prüft, dass in der neuen Umgebung keine übermäßigen Zugriffsrechte geschaffen wurden und dass Kommunikationskanäle sicher sind. Bei Cloud-Migration kontrolliert er Netzwerk-Regeln und stellt Compliance sicher (z.B. GDPR-konforme Datenspeicherung).

• Infrastruktur/DBA: Betreut die Zielplattform (Server, Datenbanken). Vor der Migration koordiniert er Backup-Strategien und stellt Rechenressourcen bereit. Während der Migration überwacht er Systemauslastung (Speicher, CPU) und kann bei Engpässen optimieren (z.B. Index erstellen).

• Fachbereichsstakeholder (Fachspezialisten): Aus den betroffenen Abteilungen kommt unterstützendes Wissen. Sie stellen Quelldaten bereit, kommentieren Migrationsproben und entscheiden über Datenbereinigungskriterien (z.B. ob alte Objekte archiviert werden). Diese „Key User“ und „Daten-Champions“ helfen, Akzeptanz zu sichern und benötigen später Schulungen.

Jede dieser Rollen trägt spezifische Verantwortung für die Qualitätssicherung und Governance der Migration. Klare Verantwortlichkeiten verhindern Verzögerungen und Kompetenzstreitigkeiten. Wie Studien zeigen, liegen 80 % der Verzögerungen bei Datenmigrationen in mangelhafter Planung und unklarer Aufgabenteilung begründet.

• Datenbereinigung vor der Migration: Identifizieren und Bereinigen von Dubletten, „leeren“ Datensätzen oder fehlerhaften Einträgen. Die Migration ist eine Gelegenheit, Altlasten zu entfernen. Beispiel: Raumdatensätze mit fehlender Stockwerksangabe ergänzen, ungültige Anlagennummern korrigieren.

• Pilotmigration durchführen: Wie empfohlen, sollte zuerst ein Teil der Daten (z.B. ein Geschäftsbereich oder 10 % der Datensätze) migriert werden. Dieser Testlauf legt Problemstellen offen – etwa falsche Zeichensätze oder ungeplante Sonderfälle – die man vor der Großmigration korrigieren kann.

• Staging-Umgebung nutzen: Führen Sie alle Transformationen zunächst in einem Test- oder Staging-System durch. So bleiben Produktionsdaten unberührt, und es existiert immer eine saubere Kopie für Versuche. In dieser Umgebung kann man Beladungsläufe beliebig oft wiederholen, bis alles sitzt.

• Umfassende Datenvalidierung: Validierung beginnt nicht erst am Ende, sondern von Anfang an. Prüfen Sie Schema-Kompatibilität („Passt jedes Feld in den Zieltyp?“) sowie stichprobenhaft Feldinhalte. Automatisierte Vergleichsreports (Zeilensummen, Schlüsselstatistiken) sollten nach jeder Pipeline-Ausführung laufen. Nach der Live-Migration muss ein 100%-Abgleich des Datenbestands stehen – keine Daten sollen verloren sein.

• Backup und Rollback-Plan: Vor jeder Migration unbedingt vollständige Backups aller Quellsysteme erstellen. Führen Sie einen klaren Rollback-Plan ein: Z.B. Scripts, um bei Totalabbruch die Systeme in den Ursprungszustand zurückzuversetzen. Geplante Downtimes sollten als Notfallfenster dienen, falls unerwartet Daten korrigiert werden müssen.

• Schulung und Kommunikation: Praktisch alle Projekte betonen, wie wichtig Schulungen sind. Endanwender müssen wissen, wie sie mit dem neuen System arbeiten und wie sie Änderungen erkennen. Bitten Sie Key-User und „Champions“ um aktives Feedback. Klären Sie frühzeitig, wie Stakeholder über den Fortschritt informiert werden, um Widerstand zu vermeiden.

• Dokumentation: Jede Datenquelle, jedes Mapping und jeder Transformationsschritt wird dokumentiert. So lassen sich bei späteren Erweiterungen oder Bugfixes Ursachen nachvollziehen. Das umfasst auch das Dokumentieren der Pipeline-Logik (z.B. Kommentare in ETL-Jobs) und das Festhalten von Lessons Learned für zukünftige Migrationen.

• Governance einbinden: Stellen Sie von Anfang sicher, dass die Migrationsregeln von den verantwortlichen Fachbereichen abgesegnet werden (z.B. welcher Datenverfall akzeptabel ist, welche Daten gelöscht werden dürfen). Integrieren Sie Sicherheitsexperten bereits in die Planungsphase, um Compliance-Risiken (z.B. Überschreitung von Speicherorten) früh zu erkennen.

Pilotläufe und Validierungen fangen Fehler auf, Dokumentation schafft Transparenz, und die richtige Teamzusammensetzung sorgt dafür, dass jeder Aspekt – technisch und fachlich – abgedeckt ist. Schließlich gilt: Eine gut geplante und automatisierte Migration beschleunigt die Einführung des CAFM-Systems und liefert den Fachanwendern direkt nach Go-Live vertrauenswürdige Daten – statt einer „Datenleiche“.