jetzt Kontakt aufnehmenRufen Sie uns anzum Seitenanfang gehenRufen Sie uns an

Kosten einer Software-Migration

Was Sie beachten sollten und wie Sie Fallstricke leicht umgehen

Veröffentlicht am 28.03.2022 von Pierre Corell

Täglich strömen eine Fülle an Daten aus den unterschiedlichsten Formaten und Datenbanken in Ihr Shopsystem ein. Neben Produktdaten und dem Design, gehören dazu auch Kundendaten. Müssen der Speicher und die Verwaltungsfunktionen für das System erweitert werden, sollten diese Daten weiterhin verfügbar bleiben, sprich eine Software-Migration wird erforderlich. Durch die Migration können Sie die Daten in vollem Umfang nutzen und somit die Performance Ihres Unternehmens steigern und wettbewerbsfähig bleiben.


Eine Software-Migration kann mit dem Aufsetzen eines neuen E-Commerce Shopsystems verglichen werden. Da eine Migration im Gegensatz zu einem neuen Shopsystem jedoch auf allen Daten – Bestellungen, Kunden, Kundengruppen, Produkte, Corporate Design etc. – basiert, die bereits vorhanden sind, erhöhen sich die Kosten in der Regel im Vergleich zu einer Neu-Realisierung. Bisherige Kunden wollen sich auch nach der technischen Migration weiterhin erfolgreich einloggen, ihre komplette Bestellhistorie sichten können usw., was zusätzliche Aufwände in der Realisierung bedingt.


Dieser Fachbeitrag möchte das Verständnis durch Transparenz zum Kostenverhältnis und der Hintergründe der Kosten darlegen und insbesondere Fallstricke für Unternehmen aufgreifen. Darüber hinaus soll ein geeignetes Vorgehen bei einer Software Migration geschildert werden. Im 2. Teil zeigen wir Ihnen eine Beispiel-Berechnung, damit Sie die potenziellen, geschätzten Kosten für Ihr Unternehmen auch selbstständig kalkulieren können.

Kosten einer Software-Migration

Inhalt

Schritt für Schritt: Ein Migrationsleitfaden für die verschiedenen Kostenbereiche

Core / Kernbereiche

Der Kernbereich der Aufwände und Kosten bei einer Software-Migration umfasst bei den meisten Shopsystemen wie Magento oder Shopware:


  • Neu-Erstellung des Corporate Designs als Template im neuen Zielsystem
  • Daten-Migration: via MySQL oder mit Hilfe programmierter Skripte, insbesondere wenn sich die Datenstrukturen oder -inhalte ändern müssen, um mit der höheren Version kompatibel zu sein
  • Systemkomponenten Zuschaltung: Anforderungen sind mit dem (künftigen) Serversetup abzustimmen, ohne das aktive Produktivsystem zu beeinflussen, sodass es häufig zu einem Doppelbedarf an Server-Hardware oder -Speicherplatz kommt – erst wenn das neue System stabil läuft und ggf. released wurde, kann das bisherige Produktivsystem abgeschaltet und durch das neue ersetzt werden

Insbesondere die Daten-Migration sollte in einem ersten Schritt vorab im agilen Team intensiv betrachtet werden. Potenziell bereits existierende Hilfsskripte für diese Aufgabe wollen gut funktionieren, alle Daten sauber transferieren und vor allem auch skalierbar sein. Die Anforderungen an einen solchen Automatismus sollten also stets auch ein Logging beinhalten bzw. die Möglichkeit bieten, Teiltransfers durchzuführen – insbesondere dann, wenn der existierende Shop mit Tausenden von Produkten und/oder vielen existierenden Bestellungen übertragen werden will. Funktioniert ein solcher Transfer einmal nicht und dauert die Daten-Migration durch die enorme Menge mehr als 5 Stunden, kann dies im schlimmsten Fall einen Neustart und die Verschiebung des Live-Gangs nach sich ziehen, da hier auch zu bedenken ist, dass viele der vorbereiteten Arbeiten einer Software-Migration an dem “einen großen Tag des Live-Gangs”, also dem Wechsel vom bisherigen zum migrierten System, reibungslos funktionieren wollen – Gesellschafter, Kunden und ggf. auch Marketingkampagnen stehen häufig bereits bereit und warten auf ihren Einsatz nach der erfolgten Daten-Migration.

Software Migrationsleitfaden für die Kostenbereiche

Core-Hacks – Setzen, Sechs!

Betreffs der Kernarbeiten muss leider ein weiterer Punkt erwähnt werden: Nicht selten ist das Quellsystem durch verschiedene Unternehmen sowie Agenturen und Entwickler angepasst worden. Waren hier Professionalität, Wissen usw. ungenügend, ist zunächst zu prüfen, ob keine sogenannten “Core-Hacks” im System enthalten sind, Funktionen also, die das Entwicklerteam anstatt in Form von Patches sauber zu “überschreiben” direkt im Kernsystem implementierte oder änderte. Sollten Sie also die Daten-Migration von einer anderen Agentur als der bisherig betreuenden Agentur vornehmen lassen, wird die professionelle, neue Agentur stets zunächst auf eine Analyse des existierenden Cores bestehen. Nicht selten treten dabei “versteckt implementierte” Funktionen zutage, die erkannt, verstanden und neu programmiert werden müssen, sollten sie weiterhin eine Anforderung an das Projekt darstellen.

Eigener (Agentur-)Code

Werden Sie nach wie vor von der originalen Ersteller-Agentur betreut, sind Wissen und/oder Dokumentation so vollständig vorhanden, dass der Aufwand für die System-Migration von Ihrer betreuenden Agentur recht exakt bemessen werden kann. Andernfalls sind diese technischen Schulden zunächst zu evaluieren.


Je nach Menge der realisierten Code-Teile bzw. Module kann & sollte eine technische Migration auch der Verschlankung dienlich sein, nicht mehr verwendete, nicht mehr nachgefragte oder deaktivierte Funktionen sind ggf. gar nicht mehr zu übertragen oder können zusammengeführt werden. Um die entsprechenden Module zu identifizieren, ist eine Investition in das Projekt-Management notwendig, die über das Steuern von Aufgaben und Ressourcen hinaus geht: Analysen, Statistiken und technische Aufarbeitung müssen für eine erfolgreiche Reduktion der Komplexität Hand in Hand gehen.


Wollen Sie hinzukommend mit dem Migrieren gleichzeitig Verbesserungen vornehmen, kommen Aufwände für die Neuerungen ebenfalls in die Kostenplanung. Der Aufwand ist generell geringer, da die Entwicklung direkt auf Basis des neuen Systems geschehen kann. Eine Migration sollte jedoch grundsätzlich ohne zusätzliche funktionelle Änderungen durchgeführt werden. Wenn Änderungen mit der Migration ausgerollt werden, ergeben sich andernfalls unkalkulierbare Seiteneffekte durch Abhängigkeiten, weswegen es in der Praxis empfohlen ist, Änderungen, die erst mit der Migration in Angriff genommen werden wollen, nicht parallel, sondern separat im Nachgang zu realisieren.

Drittanbieter Code

Unter Drittanbietern versteht man in diesem Kontext Extensions, Module und Erweiterungen des Shopsystems, die nicht von Ihnen oder Ihrer Agentur realisiert worden sind. In der Regel handelt es sich um kostenpflichtige Anschaffungen, die einen bestimmten, gewünschten Prozess im Kontext des E-Commerce-Business abbilden und steuern.


Jede der verbauten Drittanbieter-Erweiterungen stellt ein gewisses Risiko bei einer Migration dar, da:


  • die Funktion ggf. unerlässlich ist,
  • Drittanbieter die neue Shop-Version nicht mehr unterstützen könnten,
  • Drittanbieter vom Markt komplett verschwunden sind.

In einem solchen Falle bedeutet das entweder Kosten für die Neuanschaffung sowie Migration der zugehörigen Daten und Anpassungen, oder die Re-Erstellung des Drittanbieter Codes, wobei auch hier die Migration der Daten berücksichtigt werden muss.


Das Risiko der Nichtverfügbarkeit einer existierenden Extension für die Migration in das Zielsystem ist bei im Altsystem implementierten, lizenzfreien oder kostenfreien Erweiterungen dabei ungleich höher.

Die Kostenbereiche im Einzelnen zusammengefasst

Diese und ähnliche Bereiche werden Sie in einem Angebot zur Migration finden:

Server und Einrichtung


Magento 2 hat andere Anforderungen an den Server als Magento 1, weswegen ein Parallelbetrieb zweier verschiedener Systeme während der Entwicklung notwendig ist. Das Einrichten des neuen Servers, die Prozesse der CI/CD (Continuous Integration / Continuous Delivery) sind für das neue System neu aufzusetzen.

 

Analysen und Planung


Abhängig von der Komplexität des Systems, der Existenz von Dokumentation und Wissen entscheidet die Analyse über das optimale Vorgehen bzw. den technischen Migrationsplan, und sind im Kostenplan als separater Posten zu berücksichtigen.

Core-Migration


Die eigentliche Migration des Kernsystems, inklusive Neuerstellung des existierenden Designs.

Eigene & Dritt-Erweiterungen


Funktionsübernahme durch Neuerstellung bzw. Refaktorierung. / Je nach Verfügbarkeit Neukauf für das Migrations-Zielsystem oder Nachbau der Funktionalität.

Daten-Migration


In vorangestellten Kostenbereichen bereits teilweise benötigt, wird diese nicht nur einmal, sondern mehrfach vorgenommen werden müssen – und kann daher abhängig von der Größe Ihres Systems mit einem entscheidenden Risiko versehen sein.

Dokumentation & Schulungen


Damit keine technischen Schulden entstehen und der Shopadmin mit dem neuen System ebenso effizient wie bisher hantieren möchte, sollte dieser Teil ebenfalls nicht unberücksichtigt bleiben.

Professionelles Testing ist natürlich nicht zu vernachlässigen, da eine Qualitätssicherung in jedem Prozess Teilbereich der Migration involviert ist, wird in unserem Beispiel jedoch agil in den Schätzungen direkt berücksichtigt und ist sehr häufig kein separater Kostenpunkt, sondern integraler Bestandteil. Außerdem müssen gegebenenfalls weitere Spezial-Anforderungen oder Umstände einbezogen werden. Was ist, wenn ich mir mit der Migration noch Zeit lassen möchte? Was ist die beste Lösung für mein Shopsystem und mit welchen Wartungskosten muss ich rechnen?

Über die Herausforderungen einer technischen Software-Migration

Nicht alle älteren Shops sind ein Legacy-System, also veraltet und nur noch teilweise unterstützt. Einige Legacy-Systeme lassen sich auf eine höhere Version migrieren, auch wenn vom Hersteller (noch) nicht zwingend verlangt. Das betrifft zum Beispiel den Magento 1 Open Source Nachfolger OpenMage.


Die Aufwände und Kosten der Wartung eines solchen Systems sind durch verschiedene Kriterien beeinflusst:

Technische Schuld

Bedingt durch das Alter laufen mehr oder weniger technische Schulden im Verlauf eines Software-Lebenszyklus an. Die sogenannten „Technical Debts“ entstehen durch nicht dokumentierten Code, nicht erledigte oder nicht fertiggestellte Arbeit und untestbaren Code. Technische Schuld entsteht vor allem durch unzureichenden Fokus auf die Stabilität der Applikation, Ressourcenmangel und dem Wissensstand der Entscheider. Technische Schulden werden in der Regel von Entwicklern nicht dokumentiert, sodass keine klare Kennzahl definiert werden kann, wie viele Klassen oder Codeteile einer Applikation Erneuerungsbedarf aufweisen.


Hat der Unternehmer die Agentur zudem während des Shopsystem-Lebenszyklus gewechselt, ist häufig auch der Versionierungsstand bzw. die Historie aller Codeänderungen nicht verfügbar und damit intransparent. Im Laufe der Zeit werden die Ergebnisse der technischen Schuld vor allem in Bugs / Fehlermeldungen seitens der Kunden und des Shop-Betreibers sicht- und messbar. Insbesondere in einem IT-Sanierungs-Modell bzw. Software-Re-Engineering-Prozess sollten diese technischen Schulden aufgearbeitet, dokumentiert und nachgebessert werden, um das notwendige Budget für die Behebung von Fehlern, Tests und Kompatibilität, z.B. von Schnittstellen an ERP-Systeme, und damit die Wartungskosten generell zu minimieren.


Für eine potenzielle Software-Migration gilt hierbei: Je mehr technische Schulden Sie in die System-Migration mitnehmen, desto höher ist das Risiko, dass realistische Schätzungen durch das agile Entwicklungs-Team nicht möglich sind oder überschritten werden. Zu viele unbekannte Faktoren sind vorhanden, und sehr wahrscheinlich wird spätestens die Qualitätssicherung bzw. Testabteilung Funde vermelden, die weitere Aufwände des Entwickler-Teams erfordern.

Technische Schuld einer Software Migration

Bug- & Fehler-Behebungen

Bugs bzw. Fehler entstehen aus technischer Schuld oder nicht erwarteter Verwendung der Applikation. Bugs stellen zumeist die höchsten Kosten der Wartung dar, da sie:


  • behoben werden müssen, damit das Shopsystem stabil läuft,
  • die Ursache durch den Entwickler zunächst gefunden werden muss,
  • und damit der benötigte Zeitaufwand zur Behebung im vorab unschätzbar ist.

Eine weitsichtige Abhilfe zur Reduktion von Fehlern gelingt durch kontinuierliche Überwachung und Tests, Dokumentation und Priorisierung aller Prozesse des Shopsystems und damit verbundener Infrastruktur und eine automatische Testabdeckung von 30-70% aller kritischen oder als zumindest wichtig deklarierten Prozesse.

Feature Requests & Marktsituation

Natürlich möchte der Betreiber eines Shopsystems mit der Zeit gehen, seiner Konkurrenz einen Schritt voraus sein oder der spezifischen Kundschaft den bestmöglichen Komfort beim Shoppen bieten. All dies sind valide und übliche Gründe von Erweiterungen des Codes und der Funktionalität.


Bei jedem der Feature Requests sind Voraussetzungen und damit etwaig verbundene zusätzliche Maßnahmen genauso in die Schätzung zu integrieren wie der eigentliche Software-Development-Cycle und dessen Entscheidungskriterien:


  • Drittanbieter Modul kaufen und anpassen oder selbst erstellen (lassen),
  • Unit Tests und/oder Akzeptanztests bzw. regelmäßige Maßnahmen zur Gewährleistung der Stabilität & Funktionalität,
  • regelmäßige Updates auf aktuellere Versionen von Kernsystem und Erweiterungen.

Insbesondere, wenn sich der Unternehmer an dieser Stelle häufiger für kostenpflichtigen Drittanbieter-Code entscheidet, wird zudem das potenzielle Risiko an Mehrkosten einer künftigen Migration erhöht (s.a. Drittanbieter Code). Manchmal ist es Zeit für einen Wechsel, oder doch noch nicht? Wir zeigen im nächsten Beitrag „Shop-Migration: Besser jetzt oder in 3 Jahren?“ auf, wo Chancen und Risiken der Software-Migration liegen und erklären Ihnen, wie Sie die potentiell auftretenden Kosten im Prozess selbst abschätzen können.

Pierre Corell

Über den Autor

Pierre Corell

Pierre stieß 2019 nach 15-jähriger Selbstständigkeit als IT- und Cybersecurity-Spezialist, Programmierer, Consultant, Projektmanager und Dozent zur igniti. Zu Beginn als Senior Software Developer (PHP) für Magento-Projekte zuständig, erweiterte sich sein Aufgabenbereich aufgrund seiner Vorerfahrung schnell. Nun ist er zudem Projektleiter für verschiedene E-Commerce-Projekte und leitet das Team der Testautomatisierung.

Weitere Beiträge

Lassen Sie uns starten!



    captcha

    *Pflichtfelder

    Google Maps

    Mit dem Laden der Karte akzeptieren Sie die Datenschutzerklärung von Google.
    Mehr erfahren

    Karte laden