Migration ist teuer, lang und riskant. Weil sie so verkauft wird.

Zwei Ozeane. Ein Ziel. 14.000 Meilen.

Bis 1914 gab es zwischen Atlantik und Pazifik keine Abkürzung. Ein Frachter von New York nach San Francisco fuhr die gesamte Länge Südamerikas hinab, um Kap Hoorn herum und auf der anderen Seite wieder hinauf: rund 14.000 Meilen durch eine der gefürchtetsten Passagen der Seefahrt.

Das Ziel war nie das Problem. Der etablierte Weg dorthin war es.

Am 15. August 1914 fuhr der Frachter Ancon als erstes Schiff durch den Panamakanal. Dieselbe Route maß danach rund 6.000 Meilen. Die Schiffe waren nicht schneller geworden, die Besatzungen arbeiteten nicht härter, das Ziel hatte sich nicht verändert. Es war nur der Umweg verschwunden.

Die Wahrheit über Migrationen

Fragen Sie zehn Microsoft-Partner nach einem Angebot für Ihre NAV-Migration, bekommen Sie zehn Angebote. Was Sie nicht bekommen, sind zehn echte Alternativen.

Denn ein großer Teil des Marktes lässt die eigentliche Migration meist als Whitelabel-Leistung durchführen. Zwei Unternehmen dominieren im Hintergrund praktisch den gesamten Migrationsmarkt. Sie erbringen die Leistung für Microsoft-Partner, treten gegenüber dem Endkunden aber nicht in Erscheinung: Das Projekt läuft unter dem Namen Ihres Partners. Der legt seine Marge darauf und liefert aus. Und wer nicht mit ihnen arbeitet, rät auffallend oft zur grünen Wiese, weil im eigenen Haus schlicht die Kapazität oder die Erfahrung für ein Migrationsprojekt fehlt.

Arbeitsteilung ist normal, daran ist nichts verwerflich. Verwerflich ist der Eindruck, der dabei entsteht: dass Sie die Wahl hätten. Tatsächlich vergleichen Sie Angebotsschreiben, keine Verfahren. Der Motor darunter ist derselbe, und mit ihm sind es die Grenzen, die Laufzeiten und die Preise.

Das ist der eigentliche Grund, warum so viele Unternehmen heute noch auf alten NAV- und BC-Versionen festhängen. Nicht Bequemlichkeit. Nicht fehlende Einsicht. Sondern ein Markt, der sechsstellige Summen für die Lösung eines Problems aufruft, das er selbst geschaffen hat. Für einen Betrieb mit 40 Mitarbeitern ist das keine Investitionsentscheidung mehr, das ist ein Ausschlusskriterium.

Genau das ändern wir. Wir machen Migrationen für den Mittelstand wieder bezahlbar, und wir sagen offen, wie in dieser Branche gearbeitet wird.

Was die Software übernimmt – und was nicht

DataMigrate Pro ist dafür gebaut, Daten und Strukturen aus alten Navision- und Dynamics-NAV-Installationen zu lesen, zu analysieren und für Business Central aufzubereiten, ohne den Umweg über Zwischenversionen: Tabellen, Felder, Beziehungen, gebuchte Belege, historische Bestände, eigene Tabellen.

Automatisiert ist der wiederholbare Teil. Auslesen, Strukturen auf das Zielmodell abbilden, transformieren, nach Korrekturen erneut durchlaufen, Datenstände zwischen Alt- und Neusystem abgleichen. Ein Migrationslauf ist bei uns kein einmaliges Ereignis, sondern ein Vorgang, den man so oft wiederholen kann, bis das Ergebnis stimmt.

Nicht automatisiert ist alles, was eine Entscheidung verlangt:

Die Arbeitsteilung ist der Punkt. Werkzeuge sind gut in Wiederholung, Menschen sind gut in Entscheidungen. Ein Migrationsprojekt, in dem Menschen wiederholen und Werkzeuge entscheiden, ist falsch herum aufgestellt.

Von Tante Emma bis Enterprise

Wir suchen uns unsere Kunden nicht aus. Große Partner tun das, und zwar häufig nach Umsatz. Wer zu klein ist, bekommt kein Nein, sondern einen Platz weit hinten in der Warteschlange.

Unter jedem Projekt liegt derselbe Unterbau: DataMigrate Pro. Was sich unterscheidet, sind die Go-live-Szenarien. Je größer die Organisation, desto mehr Beteiligte, Standorte und Abhängigkeiten. Das Verfahren bleibt dasselbe.

Möglich ist das, weil wir Migrationen als das behandeln, was sie im Kern sind: technische Projekte. Zahlen, Tabellen, Beziehungen. Dafür steht schon unser Name. Das IO in IO Integrated kommt von Input/Output. Wir sind Datenleute.

Ob der direkte Weg in Ihrem Fall trägt, entscheidet sich deshalb nicht an Ihrer Unternehmensgröße, sondern an konkreten Dingen:

• Ausgangsversion und technischer Zustand der Datenbank
• Umfang und Art der Individualanpassungen
• Add-ons und Fremdlösungen im Altsystem
• Datenqualität und Tiefe der Historie
• Zielarchitektur: Cloud, On-Premises oder gemischt
• Anforderungen an Nachvollziehbarkeit und Aufbewahrung

Die drei Projekte oben sind einzelne Referenzfälle und keine Garantie. Was in Ihrem Fall möglich ist, sagt Ihnen der Upgrade-Check. Und wenn die Analyse ergibt, dass ein Zwischenschritt der sichere Weg ist, sagen wir das.