KAISERSTADT Consulting
KAISERSTADTCONSULTING

Dynamics 365 Migration

Eine Migration ist keine Umzugsfahrt. Sie ist eine Entscheidung darüber, was bleibt.

Wenn die Wartung ausläuft, steht ein Termin — und der verführt dazu, das Datenmodell einfach mitzunehmen, weil für mehr keine Zeit sei. Genau dann kostet es hinterher am meisten: man hat dieselbe Umgebung, nur in der Cloud, und die Gründe, warum sie nicht trägt, sind alle mitgezogen.

Bestand aufnehmen lassenTermin nennen
Microsoft-Partner · Dynamics 365 CE

Vier Anlässe

Woraus eine Migration kommt.

Jede Lage hat einen anderen Zeitdruck, und der bestimmt, was möglich ist — nicht der Wunsch. Die erste ist die häufigste und die gefährlichste.

Die Wartung läuft aus

Ein Termin steht, und er ist nicht verhandelbar. Das ist die Lage, in der am häufigsten der Fehler passiert, das Datenmodell einfach mitzunehmen — weil dafür keine Zeit sei. Genau dann kostet es hinterher am meisten.

Die Umgebung trägt nicht mehr

Gewachsene Skripte, Dialoge aus einer früheren Version, Anpassungen ohne Dokumentation. Die Migration ist hier der Anlass, aber nicht die Aufgabe: die Aufgabe ist zu 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 Abfolge der Entscheidungen. Sie ist an den Arbeitspaketen der Fälle unten nachlesbar.

  1. 01

    Bestand aufnehmen, schriftlich

    Was ist konfiguriert, was ist entwickelt, was benutzt niemand. Bei einer Beteiligungsgesellschaft war ein Health-Check-Dokument die Grundlage, nach der das Datenmodell abgebildet wurde. Ohne dieses Dokument migriert man Vermutungen.

  2. 02

    Entscheiden, was NICHT mitkommt

    Der Schritt, der Geld spart und den niemand plant. Bei einer Ablösung im Großhandel haben wir ausgewertet, welche Felder tatsächlich benutzt werden, und gegen den Standard abgeglichen, bevor neue entstanden.

  3. 03

    Daten prüfen, bevor sie umziehen

    Dubletten, Verknüpfungen ohne Gegenstück, Pflichtfelder ohne Wert. Eine Migration verdoppelt jedes Datenproblem, weil sie es in ein System bringt, in dem es 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 Review und Nacharbeit final in die Produktion. Ein einziger Lauf ist keine Migration, sondern eine Wette.

  5. 05

    Nacharbeit einplanen, nicht hoffen

    Bei der Cloud-Migration der Beteiligungsgesellschaft gab es nach dem Go-live ein eigenes Rework-Paket, danach ein fortlaufendes Budget. Wer die Nacharbeit nicht einplant, plant sie trotzdem — nur unbezahlt und unter Druck.

Eigene Software

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

Wir haben sie gebaut, weil wir sie gebraucht haben. Sie sind in Ihrer eigenen Dynamics-Umgebung als Testversion bestellbar — und sie stehen hier an der Stelle im Ablauf, an der sie greifen, nicht als Produktkacheln.

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.

  • 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 · 40 Vorhaben

    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 · 108 Vorhaben

    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 · 219 Vorhaben

    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 · 5 Vorhaben

    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 · 105 Vorhaben

    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 · 14 Vorhaben

    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 ist die Datenübernahme keine Umzugsfahrt, sondern eine Übersetzung. 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

Schritt 01 ist bei uns ein Produkt.

Die Bestandsaufnahme, mit der eine Migration anfangen muss, ist unser Audit — mit öffentlichem Festpreis und ohne Bindung an einen Folgeauftrag. Bei einer der oben belegten Cloud-Migrationen war genau so ein Dokument die Grundlage, nach der das Datenmodell abgebildet wurde. Sie können es 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.