CMS-Migration – Das Projekt planen

Content-Freeze und Code-Freeze

Wie bei den meisten IT Projekten bestehen bei einem Migrationsprojekt ebenfalls viele Abhängigkeiten und Rahmenbedingungen, die eine sorgfältige Planung erfordern. Hinzu kommt jedoch, dass bei Live-Gang des neuen Systems ein Zeitraum entsteht, in welchem keine Änderungen an den Inhalten vorgenommen werden können (Content-Freeze). Dies kann unternehmenskritisch sein, wenn zeitkritische Änderungen in diesem Zeitraum durchgeführt werden müssen, wie z.B. Marketing-Aktionen, Preisänderungen oder stichtagsbezogene Inhaltsänderungen aufgrund gesetzlicher Änderungen. Gibt es neben inhaltlichen Änderungen auch einen Bedarf für zeitkritische, funktionale Änderungen, so gewinnt der Zeitraum, in welchem keine Änderungen am Quelltext des Systems vorgenommen werden dürfen, an Bedeutung (Code-Freeze).

Rollout-Strategien

Es gibt nun verschiedene Rollout-Strategien, um mit dieser Herausforderung umzugehen. Die klassische Strategie ist ein Big Bang, bei welchem die Schritte Code-Migration, Content-Migration, Test und GoLive sequentiell durchlaufen werden. Sollten resultierende Zeiträume für Code- und Content-Freeze zu hoch sein, so bieten sich Varianten an. So kann zur Verkürzung des Content-Freeze eine zweistufige Migration durchgeführt werden, wie unten dargestellt.

Rollout-Strategie Big Bang, zweistufig

Dabei erfolgen die Content-Migration und das Testen zweistufig. In der ersten Stufe geschieht dies einmal vollständig, jedoch ohne Content-Freeze. Man hat somit mehr Zeit, da der Produktivbetrieb nicht beeinträchtigt wird, allerdings müssen die zwischenzeitlich anfallenden Änderungen nachgepflegt werden in einer Stufe 2 (Delta-Migration). Es muss von Fall zu Fall geprüft werden, ob diese Nachpflege manuell oder automatisiert erfolgen soll. Eine weitere Reduktion kann erfolgen, indem der Content in Segmente unterteilt wird. Idealerweise so, dass jede Autorengruppe nur von einem oder wenigen der Content-Freezes betroffen ist (siehe unten).

Rollout-Strategie Segmentweise mit Parallelentwicklung

Um den Code-Freeze zu entschärfen kann eine Parallelentwicklung erfolgen. Dabei werden Quelltexte für altes und neues System parallel weiterentwickelt.
Bei Systemen mit hoher Ausfallsicherheit sollte das neue System parallel auf neuer Hardware aufgebaut werden, um jederzeit in der Lage zu sein, auf das Altsystem zurückschalten zu können. Zudem sollte mindestens eine Generalprobe für den GoLive eingeplant werden, um die Umstellung in dem oftmals engen Zeitfenster ohne Verzug vollziehen zu können.

Schließlich ist die Wahl der jeweils passenden Rollout-Strategie so individuell wie deren Anpassung an die konkreten Rahmenbedingungen. Oftmals ergeben sich hinreichende Fakten für die Planung des Rollouts auch erst im Projektverlauf, wie z.B. die Dauer der jeweiligen Vorgänge.

Weitere Artikel dieser Blog-Serie

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>