Datenmigration - gefährlich oder unerlässlich?

Die Software-Entwicklungsabteilung meines Unternehmens hat das Problem, dass Datenmigrationen als potenziell gefährlich eingestuft werden, insbesondere für meine Manager.

Hintergrund ist, dass unsere Kunden eine große Datenmenge mit schlechter Qualität verwenden . Die Gründe dafür hängen nur teilweise mit unserer Softwarequalität zusammen , sondern vielmehr mit der Historie der Daten: Die meisten von ihnen wurden von Vorgängersystemen migriert , einige Fehler verursachten (meist geschäftliche) Inkonsistenzen in den Datensätzen oder fehlerhafte Eingaben auf der Kundenseite (was unsere Software aus Versehen erlaubt).

Die wichtigsten Gegenargumente meiner Manager sind, dass fehlerhafte Daten zu noch schlechteren Daten werden können , die Datenprobleme einige Manager beim Kunden wecken und einige Prozesse auf Kundenseite möglicherweise nicht mehr funktionieren, weil ihre Prozesse etwas an unser System angepasst sind.

Persönlich halte ich Datenmigrationen als integralen Bestandteil der Software - Entwicklung und dass die Datenmigration kann Daten gesehen , was Refactoring - Code ist. Ich denke, dass die Datenmigration eine wesentliche Voraussetzung für die Entwicklung von Software ist . Ohne sie müssten wir schmerzhafte Software erstellen, die eine schlechte Datenstruktur umgeht.

Ich frage dich:

• Was halten Sie von der Datenmigration, insbesondere für die realen Fälle und nicht nur aus Entwicklersicht?
• Haben Sie Argumente gegen die Meinung meines Managers?
• Wie geht Ihr Unternehmen mit Datenmigrationen und den damit verbundenen Schwierigkeiten um?
• Haben Sie noch weitere interessante Gedanken zu diesem Thema?

Datenmigrationen sind mein Brot und die Datenbereinigung ist in der Tat eine äußerst wichtige Angelegenheit. Eine Strategie, mit der wir 100% der Daten unserer Kunden migrieren, ist die Bereinigung asymptotischer Daten vor der Migration.

1. Dies bedeutet die Entwicklung von Dutzenden von Datenprüfungen (hauptsächlich SQL-Abfragen).

2. Austausch von Bereinigungswerkzeugen mit dem Kunden (da dies seine Daten sind, entwerfen wir die Patch-Dienstprogramme, er validiert sie und führt sie aus).

3. Verfeinern Sie das Tool über Iterationen hinweg und erreichen Sie so schnell wie möglich eine KPI-gestützte, messbare Qualität.

4. Überprüfen der Datenkonsistenz nach der Migration. Dies hilft, am D-Day eine Entscheidung für GO / NOGO zu treffen.

Am Ende ist eine Datenmigration eine äußerst nützliche Übung, die nach 3 bis 5 Jahren stattfinden muss.

1. Dies ermöglicht es, die Fähigkeit der Plattform zu verbessern, das Geschäft zu unterstützen.

2. Es ermöglicht die Rationalisierung der Datenbank.

3. Es bereitet die IT-Plattform für Business-Tools der nächsten Generation vor (ESB / EAI, Portale, Self-Care-Plattformen, Reporting und Data Mining, wie Sie es nennen).

4. Es reorganisiert den DIY-Datenfluss zwischen Plattformen, die sich im Laufe der Jahre angesammelt haben, auf schnelle und schmutzige "temporäre" Weise, um "dringende Anforderungen" zu erfüllen.

5. Dies stärkt vor allem das IT-Produktionsteam, das seine Plattform besser kennenlernt und die Einstellung zu möglichen Aktionen fördert. Diese Art von Nutzen ist schwer zu messen, aber wenn Sie viele Kunden kennenlernen, wird diese Überlegung offensichtlich. Unternehmen, die sich vor Migrationen scheuen, bleiben in der folgenden Kategorie, die kühnen sind führend.

Es ist ein bisschen so, als würde der Keller Ihres Hauses mit Holz vollgestopft. Eines Morgens musst du alles herausnehmen und nur die Dinge zurücklegen, die du brauchst, und den Rest wegwerfen. Danach kannst du deinen Keller wieder benutzen ;-)

Eine weitere grundlegende Überlegung ist, dass die Kundenerwartungen heutzutage immer in Bewegung sind, wie in "Kunden sind immer anspruchsvoller". Damit immer ein erheblicher Teil der Wettbewerber eines Unternehmens nach diesen neuen Trends Ausschau hält, mit der offensichtlichen Absicht, ihren Marktanteil zu erhöhen. Dazu müssen sie ihr Angebot anpassen, um sich an den Trend zu halten oder ihn sogar voranzutreiben. Dies erfordert ein ständiges Business-Re-Engineering. Wenn Ihre IT-Plattform zu starr ist, ist es ein Hindernis für Ihre eigene Neigung, den Markttrends auf Ihrer eigenen Seite voranzugehen und letztendlich Ihren eigenen Marktanteil zu halten. Mit anderen Worten, in einem sich bewegenden Markt ist Trägheit ein Rezept für Irrelevanz.

Im Gegensatz dazu wird eine Datenmigration auf ein neueres System ein moderneres und vielseitigeres Produktivitätswerkzeug einführen, wobei das Beste aus neueren Technologien für die Mitarbeiter attraktiver wird und dies wiederum dazu beiträgt, den internen Innovationsprozess des Unternehmens zu unterstützen oder sogar zu leiten und damit seinen relativen Marktanteil zu sichern oder zu erhöhen.

Die obigen Überlegungen beantworten tatsächlich nur die Hälfte der im Titel "Datenmigration - gefährlich oder wesentlich" gestellten Fragen. Ja, Datenmigrationen sind unerlässlich, aber auch gefährlich. Aus diesem Grund sind viele Dinge in der IT dann gefährlich. Per Definition ist alles, wo viel auf dem Spiel steht, gefährlich. vor allem, wenn Sie die Angelegenheit nicht ernst nehmen. Dies ist jedoch das häufigste Muster in der IT. Rechenzentren, Hochverfügbarkeit oder Katastrophenvorsorge nicht ernst zu nehmen ist gefährlich.
Bedeutet das, dass sich die heutigen Unternehmen von diesen Säulen der heutigen Informationstechnologielandschaft abwenden sollten? Sicher nicht !

Scherzhaft könnte man sagen: "Fliegen ist gefährlich, wenn man kein Flugzeug benutzt, das von Profis gebaut wurde." Dies gilt auch für Datenmigrationen. Wenn es von Profis ausgeführt und durchgeführt wird, ist es nicht gefährlicher als das Fliegen in einem gut gestalteten und gut betriebenen Flugzeug. Der ROI ist im Vergleich zu terrestrischen Transportmitteln im gleichen Verhältnis.
Die meisten Migrationen sind gut kontrollierte Erfolge, wenn sie Fachleuten anvertraut werden, und die Misserfolgs- und Abbruchrate ist extrem niedrig.

Ihre Manager sollten sich die Frage stellen: "Während die meisten Unternehmen Datenmigrationsprojekte erfolgreich durchlaufen, was würde unser Unternehmen so anders machen, dass es stattdessen einen Fehler erleiden würde? Und kann es auch ohne einen Erfolg auskommen?"

Alain gab eine großartige Antwort in Bezug auf die Wichtigkeit der Datenbereinigung für ein erfolgreiches Datenmigrationsprojekt und die Gründe für die Durchführung der Datenmigration. Ich möchte nur auf bestimmte Anliegen Ihres Managers eingehen.

Meiner Meinung nach geht es nicht darum, ob eine Datenmigration durchgeführt werden soll oder nicht, sondern wann. Ihr Vorgesetzter hat absolut Recht, wenn er sagt, dass Ihre Daten nicht mehr nur Ihre sind und dass Endkunden ihre Verfahren bereits darauf aufbauen. Dieser Zustand wird sich jedoch in Zukunft nicht ändern . Früher oder später wird eine schlechte Datenqualität zu einem unvermeidlichen Faktor für die Verlangsamung Ihres Geschäfts und Sie werden gezwungen sein, eine Migration durchzuführen. Dies unter Druck und mit knappen Fristen zu tun, kann zu suboptimalen Entscheidungen führen. Denken Sie außerdem an das Fachwissen, das Sie jetzt haben und in 2-3 Jahren haben werden. Was passiert, wenn Personen, die Ihre Daten verstehen, das Unternehmen verlassen? Sind Sie sicher, dass Ihre Unterlagen ausreichend sind?

Möglicherweise ist eine Migration jetzt nicht erforderlich, aber Ihr Manager muss zumindest eine Vorstellung davon haben, wann genau die Migration durchgeführt wird.

Ich war für eine Versicherungsgesellschaft tätig und an der Datenmigration für das Kernsystem beteiligt. Naja, es waren insgesamt 4 mal. Also hier meine Kommentare:

In meinem Fall ist die Datenmigration ein Muss, da wir die Daten laut Verordnung mindestens 10 Jahre lang aufbewahren müssen und es uns nicht leisten können, das duale System langfristig zu unterstützen. Der andere Grund ist, dass Benutzer erwarten, dass sie ihre Arbeit mit der neuen Anwendung fortsetzen können. Wenn sie das Objekt, an dem sie arbeiten, nicht finden können, ist Ihre Bewerbung schlecht, und es ist noch schlimmer, wenn die Daten nicht korrekt sind.

Nun, Datenmigration ist ein schreckliches Biest und es ist real, also sei ehrlich. Es ist riskant, kann aber minimiert werden, indem es früher und sorgfältiger angegangen wird. Als Leitfaden gibt es vier große Prozesse, die bei der Datenmigration berücksichtigt werden sollten:

1. Datenzuordnung. Karten des Masters (und ihrer Kombination) auf das neue System
2. Daten bereinigen. Ausnahmekarten in den Daten, dh Daten, deren Kombination auf dem neuen System als ungültig angesehen wird. Wenden Sie sich nach Möglichkeit an das Geschäft, um Daten auszuschließen, die nicht zugeordnet werden können, und um das neue System möglicherweise zu beschädigen. Bereiten Sie eine Problemumgehung vor
3. Tatsächliche Datenmigration. Es gibt viele Strategien, um eine Datenmigration durchzuführen. Zum Beispiel: Urknall, inkrementell
4. Konsolidierung melden. Sollten beide Systeme parallel laufen, wie kann ein korrekter und konsistenter Bericht erstellt werden?

Event mit vorsichtigem Plan, Scheiße passiert! Eine spezielle Task Force sollte bereit sein, sich mit Problemen im Zusammenhang mit der Migration zu befassen.

1) Was halten Sie von der Datenmigration, insbesondere für die realen Fälle und nicht nur aus Entwicklersicht ?:

Migration ist ein wesentlicher Bestandteil der Systementwicklung. Wenn Sie alte Systeme ganz oder teilweise ersetzen, ist Migration eine Tatsache, unabhängig davon, ob das Management dies wünscht oder nicht. Wenn vorhandene Daten schlecht sind, werden sie auf Ihrem neuen System schlecht wiedergegeben. Daher ist eine gute Migrationsstrategie von großer Bedeutung.

2) Haben Sie Argumente gegen die Meinung meines Managers?

Ja, Migration ist riskant, aber es ist auch eine Tatsache des Lebens. Und so früh wie möglich damit umgehen.

3) Wie geht Ihr Unternehmen mit Datenmigrationen und den damit verbundenen Schwierigkeiten um?

Mein Unternehmen hat - mit zunehmendem Erfolg - die Kunden aktiv in den Migrationsprozess einbezogen. Wir überprüfen die vorhandenen Daten so gut wie möglich in den ersten Projektschritten und ermutigen den Kunden, die Datenqualität zu verbessern, bevor wir mit der Migration beginnen. Manchmal fordern wir es tatsächlich.

4: Alle anderen interessanten Gedanken, die zu diesen Themen gehören

Mein Rat ist, den Migrationsprozess in zwei Schritte zu unterteilen: Konvertierung und Datenbereinigung. Die Konvertierung ist ziemlich einfach - es geht darum, alte Systemobjekte dem neuen System zuzuordnen. Die Datenbereinigung kann dagegen (wie oben erwähnt) sehr schwierig sein. Binden Sie den Kunden so weit wie möglich ein und starten Sie den Prozess so früh wie möglich. Denken Sie daran, dass schlechte Daten auf Ihrem neuen System schlecht wiedergegeben werden - manchmal völlig ohne Grund. Wenn ein neues System nicht funktioniert, beschuldigt ein Kunde selten Daten, die im alten System einwandfrei zu funktionieren schienen.

Wenn die zu migrierenden Daten derzeit fehlerhaft sind, muss behoben werden, ob Sie eine Migration durchführen oder nicht. Schlechte Daten = unbrauchbare Daten.

Migrationen sind riskant, das stimmt. Aber auch jedes größere IT-Projekt. Es gibt Möglichkeiten zur Risikominimierung und sie sollten im Vorfeld einer Migration unbedingt geplant werden.

Erstens sollten Sie immer die Möglichkeit haben, zum aktuellen System zurückzukehren. Zweite Migrationen sollten auf Testservern durchgeführt werden, die nur für die Migration eingerichtet wurden. Es ist töricht, eine Migration durchzuführen, ohne sie zuerst testen zu können. Drittens sollte sich der gesamte Code für die Migration in der Quellcodeverwaltung befinden.

Viertens benötigen Sie Anforderungen und Testpläne, bevor Sie mit der Migration beginnen. Sie müssen wissen, dass wenn Sie im alten System 1.293.687 Datensätze hatten, dass Sie dieselben im neuen System haben oder wissen, wohin sie gegangen sind (vielleicht zu einer Ausnahmetabelle). Wenn Sie ein denormalisiertes Schema normalisieren, müssen Sie berechnen, mit wie vielen Datensätzen Sie enden sollen, bevor Sie beginnen, und dies dann überprüfen. Sie benötigen eine Dokumentation, die angibt, wie die Zuordnungen von einem System zum anderen aussehen. Auf diese Weise können Ihre QA-Mitarbeiter überprüfen, ob die Daten an der richtigen Stelle eingegangen sind.

Sie müssen festlegen, wie mit den aktuellen fehlerhaften Daten umgegangen werden soll. Was kann bereinigt werden, was muss in einem erforderlichen Feld mit der Aufschrift "Unbekannt" angegeben werden, was muss in eine Ausnahmetabelle verschoben werden, was muss manuell von einer Benutzergruppe eingegriffen werden (um zu entscheiden, ob es sich bei diesen beiden Personen wirklich um einen Betrüger handelt oder nicht) Gibt es in dieser Praxis zwei Ärzte mit demselben Namen, und wenn es sich um ein Dup handelt, welche Daten zu wählen sind, wenn sich die beiden Aufzeichnungen unterscheiden, usw.)?

Der Schlüssel zu einer erfolgreichen Migration liegt in der Planung. Ich habe festgestellt, dass die Planung (einschließlich des Schreibens der Testfälle und der Komponententests) in der Regel mehr Zeit in Anspruch nimmt als die eigentliche Entwicklung.

Der nächste Schlüssel für eine erfolgreiche Datenmigration ist die Qualitätssicherung. Dies ist kein Projekt, das Sie dem QA-Team am Tag vor dem Start vorwerfen sollten. Dies ist kein Projekt, das gestartet werden soll, wenn QA angibt, dass ein Problem vorliegt.

Ein weiterer Schlüssel für eine erfolgreiche Migration besteht darin, den Großteil der Daten bereitzustellen und zu testen, während das ursprüngliche System noch ausgeführt wird. Wenn Sie viele Datensätze verschieben, ist dies möglicherweise zeitaufwändig und es werden neue Änderungen vorgenommen. Daher muss Ihr Prozess in der Lage sein, die Datenänderungen auch nach dem Start der Migration abzurufen. SQL Server hat zum Beispiel etwas, das sich Change Data Capture nennt und das dabei helfen kann. Sie können eine Sicherungskopie des Orginalsystems erstellen und gleichzeitig die Erfassung von Änderungsdaten aktivieren. Anschließend können Sie die Sicherung erneut auf Ihren Migrationsserver übertragen, die Migration testen, den Großteil der Daten laden und anschließend nur die geänderten Datensätze laden. Wenn Sie die endgültigen Datensätze migrieren, deaktivieren Sie das Quellsystem, bis die Migration abgeschlossen ist. Dies ist ein Grund, einen Großteil der Datensätze vorzeitig zu migrieren. Daher ist die Anwendung in der kürzesten Zeit nicht verfügbar. Wählen Sie Ihre Migrationszeit gut aus, schließen Sie die Personalabrechnung nicht an dem Tag, an dem sie die Personalabrechnung bearbeiten oder W2s versenden soll. Und das während der geringen Nutzungsdauer. Wenn Sie mehrere Clients haben, können Sie einen zuerst migrieren und sicherstellen, dass alles in Ordnung ist, bevor Sie die anderen Clients ausführen. Es ist viel einfacher, die Daten eines Kunden zurückzusetzen als 10000, wenn es ein Problem gibt. Aber planen Sie dies sorgfältig, wenn Sie es tun. s Daten als 10000, wenn ein Problem vorliegt. Aber planen Sie dies sorgfältig, wenn Sie es tun. s Daten als 10000, wenn ein Problem vorliegt. Aber planen Sie dies sorgfältig, wenn Sie es tun.

Wenn die Migration eine neue Benutzeroberfläche umfasst, bitten Sie die tatsächlichen Benutzer, diese im Rahmen des Migrationstests zu verwenden. Trainieren Sie dann die anderen Benutzer, bevor Sie live gehen (aber weniger als eine Woche, bevor Sie live gehen, sonst werden sie es vergessen). Lassen Sie die an den Tests beteiligten Benutzer das Training mitgestalten, sie wissen, welche Fragen sie hatten und was die Benutzer in welcher Reihenfolge wissen müssen. Holen Sie sich Ihre Eingabe, indem Sie ein Feld erforderlich machen, da Sie der Meinung sind, dass es nicht hilfreich sein sollte, wenn die Benutzer diese Daten normalerweise nicht haben, wenn sie die Datensätze eingeben. Sie werden nur Junk in das neu erforderliche Feld einfügen, da sie die Daten sonst nicht abrufen können.

Sehen Sie sich an, was mit den aktuellen Daten nicht stimmt. Können Sie in der Anwendung Fremdschlüssel, Einschränkungen, Trigger, Geschäftsregeln, Standardwerte usw. hinzufügen, um dies in Zukunft zu vermeiden? Wenn Sie fehlerhafte Daten bereinigen, müssen Sie auch eine Möglichkeit schaffen, um zu verhindern, dass in Zukunft ähnlich fehlerhafte Daten eingehen. Analysieren Sie, warum die fehlerhaften Daten zugeordnet wurden, und korrigieren Sie die Löcher im Design.

Datenmigration ist eine Notwendigkeit. Ohne Datenmigration können Sie oft nicht weitermachen. Viele Systeme, mit denen ich gearbeitet habe, sind nur auf früheren Systemen verfügbar. Migration ist die einzig praktikable Methode. Datenqualität ist oft ein Problem. Im Allgemeinen sollte dies im vorherigen System behandelt werden. Dies erfordert möglicherweise Änderungen an den Daten, um die Qualität wiederherzustellen.

Andere Systeme, mit denen ich gearbeitet habe, hingen von Daten anderer Systeme ab. Dies ist ein anderes, aber wichtiges Problem. In einigen Fällen können die Daten vollständig ersetzt werden. In anderen Fällen können die in den neuen Daten enthaltenen Änderungen möglicherweise besser in der vorhandenen Gruppe zusammengefasst werden. Diese Migrationsarten sollten Gültigkeitsprüfungen für den eingehenden Feed enthalten.

Die Möglichkeit, vorhandene Daten zu validieren und zu bereinigen, kann ein wichtiges Merkmal eines Systems sein. Dies ist unabhängig von der Migration. Es gibt häufig Mechanismen zum Ändern von Daten, die außerhalb der Kontrolle des Systems liegen. Dies kann dazu führen, dass Daten ungültig werden. Andere Datenprobleme resultieren aus Fehlern in der Anwendung. Wenn Sie die Validierungsroutinen regelmäßig ausführen, können Sie das Problem leichter identifizieren und die Daten bereinigen, bevor es Zeit für die Migration ist. Wie bereits erwähnt, kann eine frühzeitige Bereinigung der Daten die Migration erleichtern.

Einige Validierungen sind zeitkritisch und sollten nicht auf Daten angewendet werden, die nicht geändert wurden. Dies ist häufig bei codierten Werten der Fall, bei denen Codes zurückgezogen wurden. Es sollte möglich sein, andere Felder im Datensatz zu ändern, ohne Validierungsfehler auszulösen. Dies kann die Update-Validierung komplexer machen, da festgestellt werden muss, welche Felder vor der Validierung geändert wurden. Die feldübergreifende Validierung kann auch komplexer sein. Die Möglichkeit, einige Datensätze als schreibgeschützt zu behandeln, kann in diesem Fall hilfreich sein, da die Validierung vermieden werden kann.

Auf einem I-System, an dem ich gearbeitet habe, wurde das neue System vom Kunden teilweise abgelehnt. Sie lehnten es ab, die neuen Dateneingabemodule zu verwenden. Sie wollten jedoch die Stapelverarbeitung aus dem neuen System. Die Lösung bestand darin, die Daten jede Nacht vor dem Batch-Lauf zu migrieren.

Es ist ein notwendiges Übel. Ich war an beiden Enden dabei und dies sind einige der anderen Probleme, die das Problem verschärfen.

1. Insbesondere im Unternehmen möchten Unternehmen, die auf ein neues System umsteigen, alles, was das alte System getan hat. Sie überprüfen ihre Verfahren nicht. Sie sind so überwältigt, dass sie einfach alles genauso machen wollen. Das ist für sie sicher.
2. Sie nehmen sich nicht die Zeit, das neue System kennenzulernen oder Fachleute einzustellen.
3. Sie möchten das neue System so anpassen, dass es entweder Platz 1 bietet oder einen neuen Aspekt ihres Geschäfts abdeckt. Neue System X-Anpassungen X Konvertierte Daten = Zusammengesetzte Komplikationen
4. Dem Testen wird nicht genügend Zeit gewidmet.
5. Kunden hassen es, parallel zu laufen und Dinge zweimal zu tun. Ich kann den Benutzern keine Vorwürfe machen, da sie nicht die Zeit haben, dies zu tun, da alle anderen Aufgaben auf Hochtouren ausgeführt werden.

Wenn Ihre Manager den Umsatzverlust dadurch rechtfertigen können, dass sie keine Daten konvertieren, erhalten sie mehr Leistung. Ihren Kunden mitzuteilen, dass alle Datenkonvertierungen fehlschlagen, wird nicht funktionieren, da ihnen immer jemand anderes mitteilt, dass dies der Fall ist (normalerweise Ihre Konkurrenz).

Was halten Sie von der Datenmigration, insbesondere für die realen Fälle und nicht nur aus Entwicklersicht?

Software muss regelmäßig aktualisiert werden. Um sicherzustellen, dass die Migration gesichert ist, müssen Sie eine Sicherungskopie erstellen und testen.

Haben Sie Argumente gegen die Meinung meines Managers?

er hat recht, dass es riskant ist. Sie können jedoch Techniken anpassen, um das Risiko zu verringern.

Wie geht Ihr Unternehmen mit Datenmigrationen und den damit verbundenen Schwierigkeiten um?

Wir haben tägliche Backups, inkrementelle Backups und Backups vor jeder Bereitstellung in der Produktion. Damit können Sie zumindest einen Rollback durchführen, wenn etwas Schlimmes passiert.

Wir haben eine Testumgebung, automatisierte Tests und einen täglichen Build-Server. Außerdem wird ein Rauchtest durchgeführt, um sicherzustellen, dass wichtige Vorgänge und Funktionen ordnungsgemäß funktionieren. Wir beziehen Entwickler, QS und Benutzer ein, um den Build (der Daten migriert hat) zu testen.

Wir verwenden Ruby on Rails, das die Versionierung von Datenmigration, -Upgrade und -Rollback ermöglicht. das macht unser leben leichter.

Wir verwenden Capistrano, um das Code-Update und die Datenmigration durchzuführen. Die Automatisierung und Vereinfachung der Migration ist einer der Schlüssel, um sicherzustellen, dass das Produktionssystem funktioniert.

Haben Sie noch weitere interessante Gedanken zu diesem Thema?

Ein weiteres Anliegen in Bezug auf die Datenmigration ist für mich die Konsistenz von Code-Upgrade und Datenmigration. Auch in meinem Fall verwenden wir automatisierte Methoden, um damit umzugehen. und immer bereit zum Rollback.

Wenn Sie die Datenmigration manuell ausführen, wird die Datenbank möglicherweise in einen unbekannten Status versetzt. und es ist schwierig, die Datenmigrationsversion zwischen verschiedenen Serverumgebungen zu vergleichen.

ich hoffe es hilft.

Wir verschwenden keine Zeit damit, Daten aus alten Altsystemen zu migrieren, da Zeit, Investitionen und Risiken allzu hoch sind. Wir arbeiten einfach an neueren Systemen und integrieren sie bei Bedarf.

Jedes Unternehmen verfügt über eine Art Legacy-System, das es unterstützen muss, und dies ist nur ein normaler Geschäftsaufwand.

Die von Ihren Managern erhoffte Belohnung wäre angesichts der Migrationskosten sehr hoch.