KAISERSTADT Consulting
KAISERSTADTCONSULTING

Dynamics 365 Migration

Bei einer Migration entscheiden Sie zuerst, was nicht mitkommt.

Wenn die Wartung ausläuft, steht ein Termin – und die Versuchung ist groß, das Datenmodell einfach mitzunehmen. Genau das wird hinterher am teuersten, denn Sie haben dieselbe Umgebung wie vorher, nur in der Cloud, und alle Gründe, warum sie nicht trägt, ziehen mit.

Bestand aufnehmen lassenTermin nennen
Microsoft-Partner · Dynamics 365 CE

Vier Anlässe

Woraus eine Migration kommt.

Jede Lage hat ihren eigenen Zeitdruck – und der entscheidet, was machbar ist. Die erste kommt am häufigsten vor und ist zugleich die riskanteste.

Die Wartung läuft aus

Der Termin steht fest und lässt sich nicht verschieben. Genau dann ist die Versuchung am größten, das alte Datenmodell einfach mitzunehmen – und genau das wird hinterher am teuersten.

Die Umgebung trägt nicht mehr

Alte Skripte, Dialoge aus einer früheren Version, Anpassungen, die niemand dokumentiert hat. Der Umzug ist hier nur der Anlass. Die eigentliche Aufgabe: entscheiden, was mitkommt.

Ein Altsystem soll weichen

Kein Versionswechsel, sondern ein Ersatz. Navision, ein Eigenbau, eine Branchenlösung. Dann ist die Datenübernahme kein Nebenschritt, sondern das größte Arbeitspaket.

Zwei Systeme sollen eins werden

Nach einem Zukauf oder einer Umfirmierung. Der technische Teil ist überschaubar; die Arbeit liegt darin, zwei Datenbestände zusammenzuführen, die dieselben Kunden unterschiedlich kennen.

Der Ablauf

Fünf Schritte, und der zweite spart das Geld.

Nicht der technische Ablauf, sondern die Reihenfolge der Entscheidungen. Die Fälle weiter unten zeigen, wie das konkret aussah.

  1. 01

    Bestand aufnehmen, schriftlich

    Was ist konfiguriert, was ist entwickelt, was benutzt niemand mehr. Bei einer Beteiligungsgesellschaft war ein Health-Check-Dokument die Grundlage für das neue Datenmodell. Ohne so ein Dokument zieht man am Ende nur Vermutungen um.

  2. 02

    Entscheiden, was NICHT mitkommt

    Der Schritt, der Geld spart und trotzdem meist übersprungen wird. Bei einer Ablösung im Großhandel haben wir zuerst ausgewertet, welche Felder überhaupt benutzt werden, und mit dem Standard abgeglichen, bevor neue dazukamen.

  3. 03

    Daten prüfen, bevor sie umziehen

    Dubletten, Verknüpfungen ohne Gegenstück, Pflichtfelder ohne Wert. Jedes Datenproblem, das mit umzieht, wird im neuen System teurer – weil es dort länger bleibt.

  4. 04

    Mehrere Testläufe, erst dann die Produktion

    Bei einer Ablösung liefen eigene Migrationsdienste und mehrere Durchläufe: erst in die Testumgebung, dann nach Prüfung und Nacharbeit final in die Produktion. Ein einziger Durchlauf reicht dafür nicht.

  5. 05

    Nacharbeit einplanen, nicht hoffen

    Bei der Cloud-Migration der Beteiligungsgesellschaft gab es nach dem Go-live ein eigenes Nacharbeits-Paket, danach ein laufendes Budget. Nacharbeit kommt so oder so – besser eingeplant als später unter Druck nachgeschoben.

Eigene Software

Für die zwei Schritte, an denen Migrationen scheitern.

Beide Werkzeuge haben wir für unsere eigenen Migrationen gebaut. Sie können sie als Testversion in Ihrer Dynamics-Umgebung ausprobieren.

Bei Schritt 04

Import Studio

Mehrere Blätter und Zielentitäten in einem Durchgang, Spaltenzuordnung, Werte-Zuordnung, Simulationslauf und eine Bilanz je Blatt. Der Simulationslauf ist der Punkt: er zeigt, was passieren WÜRDE, bevor etwas passiert.

Zur Produktseite

Bei Schritt 03

Duplikat-Bereinigung

Dubletten finden und zusammenführen, bevor sie in die neue Umgebung wandern. Nach der Migration ist dieselbe Arbeit teurer, weil dann Verknüpfungen daran hängen.

Zur Produktseite

Sechs dokumentierte Fälle

Was in diesen Migrationen tatsächlich passiert ist.

Cloud-Umzüge, Altsystem-Ablösungen und ein Fall, in dem die Vorarbeit das ganze Vorhaben getragen hat. Je Fall die Ausgangslage, die Arbeit und die Laufzeit.

Bei einer Ablösung ist der Umzug nur die eine Hälfte. Wie die andere abläuft, von der Klärung der Abläufe bis zur Schulung, steht auf der Seite zur Einführung.

  • Eine Beteiligungsgesellschaft

    On-Premises in die Cloud

    Datenmodell nach Health-Check-Dokument abgebildet, dann Vorbereitung, Testung und finale Datenmigration als größtes Paket. Gewachsene Skripte und Dialoge angepasst, Umsysteme angebunden. Nach dem Go-live ein eigenes Rework-Paket.

    August 2021 bis September 2024

    Ohne Kundennamen

  • UniElektro

    Altsystem im Vertrieb abgelöst

    Altdatenübernahme samt Verknüpfungen, mit eigenen Migrationsdiensten und mehreren Testläufen, erst Testumgebung, dann nach Review in die Produktion. Vorher ausgewertet, welche Felder überhaupt benutzt werden.

    seit September 2023

    Zur Fallstudie

  • PromoCell

    Navision im Vertrieb abgelöst

    Der Vertrieb lief auf einem System, das dafür nicht gedacht war. Aus der Ablösung ist über acht Jahre ein durchgängiger Prozess geworden, mit Middleware zum ERP, E-Rechnung und einem vollständigen QM-Prozess.

    seit Juli 2018

    Zur Fallstudie

  • Ein Branchenverband der Industrie

    Migration mit Vorarbeit

    Ein Migrationsworkshop mit vorbereitetem Anforderungsworkshop, ein eigenes Anforderungsdokument und ein Beziehungsdiagramm, das das CRM erklärt. Danach Schulung und eine Support-Hotline.

    März 2022 bis Mai 2023

    Ohne Kundennamen

  • Communardo Gruppe

    Eigenes Lizenzsystem abgelöst

    Lizenz- und Rechnungsdaten aus einem Herstellersystem über eigene Plugins übernommen, über mehrere Gesellschaften hinweg. Die Ablösung war Teil einer Weiterentwicklung, die seit vier Jahren läuft.

    seit November 2021

    Zur Fallstudie

  • Ein Verband mit eigener Geschäftsstelle

    On-Premises in die Cloud

    Eine Cloud-Migration mit eigener Presales-Phase und Konzeption, koordiniert vor Ort, mit Anwenderschulung zum Abschluss. Zehn Monate von der Konzeption bis zur Schulung.

    August 2021 bis Mai 2022

    Ohne Kundennamen

Häufige Fragen

Was vor einer Migration gefragt wird.

Wie lange dauert eine Migration von On-Premises in die Cloud?
Das hängt am Zustand der Altumgebung, nicht an ihrer Größe. Aus den dokumentierten Fällen: bei einem Verband mit überschaubarer Umgebung lagen zehn Monate zwischen Konzeption und Anwenderschulung; bei einer Beteiligungsgesellschaft mit gewachsenen Skripten und angebundenen Umsystemen zog sich das Vorhaben über drei Jahre, weil nach dem Go-live ein eigenes Rework-Paket folgte. Eine allgemeine Zusage wäre geraten, belastbar wird die Schätzung erst nach der Bestandsaufnahme.
Können wir unsere Anpassungen mitnehmen?
Technisch oft ja, wirtschaftlich selten sinnvoll. Gewachsene Skripte und Dialoge aus einer früheren Version funktionieren in der Cloud nicht unverändert weiter, und was heute Aufwand ist, ist morgen Wartungslast. Wir werten deshalb vorher aus, welche Felder und Funktionen tatsächlich benutzt werden, und gleichen gegen den Standard ab, bei einer Ablösung im Großhandel war genau das ein eigenes Arbeitspaket, bevor neue Felder entstanden.
Was passiert mit den Altdaten?
Die Übernahme ist ein eigenes Vorhaben und meistens das größte Paket. Bei einer Ablösung im Großhandel liefen dafür eigene Migrationsdienste und mehrere Testläufe: erst in die Testumgebung, dann nach Review und Nacharbeit final in die Produktion. Verknüpfungen sind dabei der schwierige Teil, nicht die Datensätze selbst, ein Kontakt ohne sein Unternehmen ist kein migrierter Kontakt.
Müssen wir vorher unsere Daten aufräumen?
Ja, und zwar vorher und nicht nachher. Eine Migration verdoppelt jedes Datenproblem, weil sie es in ein System bringt, in dem es länger bleibt und an dem dann Verknüpfungen hängen. Für Dubletten haben wir eigene Software gebaut, weil wir sie selbst gebraucht haben, sie greift vor der Migration, nicht danach.
Läuft der Betrieb während der Migration weiter?
Bei den dokumentierten Fällen ja. Bei einer Ablösung im Großhandel stand der Vertrieb während der Übernahme nicht still, und bei einem Energiedienstleister wurde am Stichtag umgestellt, für die gesamte Organisation gleichzeitig. Welcher der beiden Wege passt, ist eine Risikoentscheidung: eine Stichtagsumstellung ist billiger und hat keine Rückfallebene.
Was kostet uns die Bestandsaufnahme?
Sie ist unser Audit und hat einen öffentlichen Festpreis. Der Bericht gehört Ihnen und bleibt brauchbar, wenn Sie ihn weitergeben, an einen anderen Dienstleister oder an Ihre Geschäftsführung. Bei einer Beteiligungsgesellschaft war ein solches Dokument die Grundlage, nach der das Datenmodell in der Cloud abgebildet wurde.
Kann eine Migration scheitern?
Sie kann teurer werden als geplant, und der häufigste Grund ist immer derselbe: ein einziger Migrationslauf, direkt in die Produktion, unter Termindruck. Deshalb sind mehrere Testläufe bei uns kein Vorschlag, sondern Teil des Ablaufs und die Nacharbeit nach dem Go-live ein eingeplantes Paket, kein Notfall.
Wir wollen ein Altsystem ablösen, nicht die Version wechseln. Ist das dasselbe?
Nein, und der Unterschied ist groß. Bei einem Versionswechsel kennen Sie das Zielmodell, weil es Ihr eigenes ist. Bei einer Ablösung muss es erst entstehen und dann muss die Datenübernahme das alte Modell in das neue übersetzen. Wir haben das bei einer Navision-Ablösung im Vertrieb und bei der Ablösung eines eigenen Lizenzsystems gemacht; in beiden Fällen war die Konzeption des Zielmodells der Teil, der über das Ergebnis entschieden hat.

Falls die Lage eine andere ist

Ein Migrationstermin ist oft der Anlass, bei dem auffällt, dass noch etwas anderes klemmt. Dann ist die Frage, ob die Migration überhaupt das erste Thema ist.

Nächster Schritt

Der erste Schritt ist bei uns ein festes Angebot.

Die Bestandsaufnahme, mit der jede Migration anfängt, ist unser Audit – mit öffentlichem Festpreis und ohne Bindung an einen Folgeauftrag. Bei einer der Cloud-Migrationen oben war genau so ein Dokument die Grundlage für das neue Datenmodell. Sie können das Ergebnis auch ohne uns weiterverwenden.

Audit mit FestpreisTermin nennen
Microsoft-Partner · Dynamics 365 CE

Stand · Verantwortlich: Pascal Peters, Senior Dynamics 365 CE Architect & Inhaber

Zuletzt geprüft: die sechs Fälle gegen den Referenz-Datensatz. Ausgangslage, Laufzeit und Umfang.