Aktuelle Themen

Data Migration – From A To B and everything in-between

Any ’normal‘ person could be forgiven for thinking ‚Data-Migration‘ is just a fancy jargon for ‚copy-and-paste‘. By ’normal‘, I mean people without programming-superpowers.

And to be honest, it is. Shift data from A to B.

However, it is not as straight-forward as one might think. This blog is just a quick insight into „Data-Migration“ without all its technicalities.

A successful migration of data implies that the legacy system – the old system – can be cut off completely so that the new system can give better response times. If the old system cannot be switched off, that means neither the benefit of new system – nor the legacy system – can be utilized to its full potential and hence the project can be considered failed. Data-Migration in large scale is a significant project, or at least should be treated as such – specially considering 83% of data-migration projects either fail or exceed their budgets and schedules.

And that begs the question: WHY ?!

Why migration-projects could fail

Most of the data migration projects, like any other projects, are expected to succeed at their inception. A significant part of the blame for failures lies on misconceptions and inaccurate assumptions about the effort required. For example, an assumption that the data in current system is complete and accurate could lead to complications at later part of the project. Or thinking that an in-house IT department can migrate the whole database clean may result in having to perform data-migration a second time properly. (No offense IT Abteilung. Ihr seid Zuper! <3 )

Most of the complications in migration projects surface during the last quarter of project where millions of data units are being transferred into a new system. All the ‚perfect‘ data may get transferred without a hitch, but with the data units in millions, the probability of everything running smoothly is much more closer to zero than one would like. New adjustments will have to be made. And we cannot tell if next run will be without errors. run-fix-repeat. It takes (unexpected) time. Hello Ms. Over-budget and Mr. Behind-schedule.

Or an unexpected hardware failure. Or maybe database server is down. Or a nuclear war… Okay! I guess you get the point… Data-migration. Not as simple as it first sounds. A lot of things that could go wrong.

So the next questions: What could be done? Is there a happy ending?

Yes, there is!

What are the secret ingredients?


First things first. Business stakeholders (and not only the people with programming-superpowers) must get involved enough in the project to understand the amount of resources that must be invested in order to achieve the expected quality. It is not just about migrating data from A to B but making data fit to the new system. In large scale data migration, it is almost never the case that data units exist independently. They are always interconnected to each other. And the network may look very different in the target system than in the legacy.

Short story shorter, business stakeholders need to understand that it is not an IT Problem. Now to the secret ingredients.

Extract.    Transform.    Load.

Extract. Data extraction is not about legacyDatabase.getEverything(). Understanding what (and why) is also very important. What can the new system do that the legacy could not? Practical discussions need to be held on what to migrate and what to leave behind, the true state or consistency of data in legacy compared to what has been documented and the expected quality of data in target system. Data-profiling approach helps in truly understanding the data and expose many risks early in the project. It also helps make an informed estimation of time and effort needed to successfully migrate the data.

Transform. The target system most probably has different system structure than the legacy. A square peg cannot fit in a round hole. And hence the migration. Data need to be cleaned, enriched, modified – in short, transformed. Transformation of data involves making it fit the new system purposefully. More questions will crop up once the implementation starts. What, why, why not, who, how – most likely way to get answers is by asking questions. Just make sure they are asked early enough.

Load. The only thing left now is to load (or store) data in the target system. All the low hanging fruits will have been harvested. Even after doing everything as correctly as possible, it is a valid presumption that a small percentage of data will cause unforeseeable problems that might not have simple solutions. Programming-superpowers must be used. Brains must be stormed. Time must be invested. It is inevitable. However, if the project was well thought through, time, resources and plan to address this very situation would have been built into the project. That means: Hello Mr. Still-on-time and Ms. Calculated.


Last words.

To the business-stakeholders – it is serious.

To the people with superpowers – it is fun.*

*Ohne Gewähr

There are many number of other factors that influence the success or failure of a data-migration – or any – project. Large system upgrades, system implementations, new management, new regulations, mergers or whatever the reasons for the need to migrate data in an enterprise scale, it is important to treat data migration as a long process – a crucial Project and not an one-time event.

Undervalued, underestimated complexity, underestimated risk, underestimated effort, insufficient preparation, misconception. Those are the thoughts that come to my mind when I think about someone’s thought who is thinking about data-migration. One might think I am getting a little emotional about data-migration.

Very likely. As I might end up writing a thesis around this topic.  :)

Thanks for reading.


Vue.js und die Vue CLI 3 für Beginner

Im JavaScript-Universum tummeln sich so einige Frameworks, einige überwinden nie den Newcomer-Status andere hingegen etablieren sich als feste Größe unter den JavaScript-Frameworks. Ein Framework, das sich in den letzten Monaten bewiesen hat ist Vue.js, es gehört inzwischen zu den festen Größe unter den JavaScript-Frameworks. In diesem Blogpost wird Vue.js vorgestellt und erste Einblicke in die Frontendentwicklung mit Vue.js gegeben.

Unter den Frontend-Entwicklern hört man häufig denselben Satz –schon wieder ein neues Framework, lohnt sich die Betrachtung überhaupt?

Ja, eine Betrachtung lohnt sich definitiv. Denn schließlich gehört Vue.js laut Google-Trends zu den drei größten JavaScript-Frameworks mit wachsender Beliebtheit.


Code Reviews

Warum es sich lohnt, Gedanken über Code Reviews zu machen

Bis vor kurzem dachte ich eine Code Review sei keine komplizierte Sache. Ein Kollege setzt sich zu mir an den Arbeitsplatz, wir gehen gemeinsam meinen Code durch und ich notiere mir, was ihm dabei auffällt. Anschließend beseitige ich sämtliche Fehler und Missstände, benenne Variablen um, führe Refactoring durch und füge weitere Tests hinzu. Was sich in der Theorie so einfach liest, scheint in der Praxis nicht so leicht umsetzbar zu sein. Mit dem Webinar „Code Review Best Practices“ von Trisha Gee ist mir erst aufgefallen, wie umfangreich das Thema ist und was man dabei alles falsch machen kann. Was sie als Anti Pattern bezeichnet, habe ich ehrlicherweise selbst schon erlebt, aber nicht erkannt.

Wie sollte eine Code Review aussehen?


OpenShift Deployment mit dem fabric8-maven-plugin

Das Thema DevOps ist allgegenwärtig und viele Entwicklerteams sehen sich mit der Tatsache konfrontiert, dass sie ihre Anwendungen nicht nur bauen, sondern auch selbst betreiben müssen. Äußerst beliebt ist dabei derzeit natürlich Kubernetes oder auch OpenShift als Plattform. Doch die händische Pflege von Deploymentkonfigurationen kann mühsam sein. Hier kommt fabric8 ins Spiel: mit dem fabric8-maven-plugin lässt sich das Deployment nahtlos in den Buildprozess integrieren.

Sinnvolle Basiswerte werden durch die bereits bestehenden Einstellungen aus der POM ergänzt und können bei Bedarf gezielt überschrieben werden. Aber auch schon vor dem Deployment hilft das Plugin, denn es unterstützt auch bei der Erstellung eines Docker-Images. Je nach Umgebung ist es aber bei OpenShift nicht möglich, direkt mit Docker zu kommunizieren. Stattdessen gibt es hier die Variante des Source2Image Builds, welcher ebenfalls von fabric8 unterstützt wird.

Da die Dokumentation ( nicht unbedingt den leichtesten Einstieg bietet, gibt es hier eine kleine Hilfestellung.


Zuerst binden wir das Plugin ein:

Jetzt greift bereits der „Zero-Config“ Modus von fabric8. Mit den Voreinstellungen erarbeitet das Plugin selbstständig einen Plan für das zu bauende Image. Rufen wir also nun mvn package fabric8:build auf, wird unser Jarfile mit dem fabric8-Basisimage zu einem Dockerimage gebaut. Da wir aber davon ausgehen, keinen Zugriff auf Docker zu haben, müssen wir die erste Konfiguration vornehmen:

Image bauen

Mit diesen Properties wechselt fabric8 in den OpenShift-Modus. Diesmal führt der Aufruf von mvn package fabric8:build zu einem OpenShift Binary Build. Das bedingt, dass die OC Tools installiert und mit dem Zielcluster verbunden sind. Ist der Buildvorgang erfolgreich, dann existiert nun ein ImageStream mit der artifactId im gewählten Namespace (dieser lässt sich mit auch mit -Dfabric8.namespace beim Aufruf ändern). Als Basisimage wird bei der S2I-Strategy standardmäßig fabric8/s2i-java:latest verwendet. Möchte man das ändern, lässt sich das in der Pluginkonfiguration bewerkstelligen:


Im nächsten Schritt kümmern wir uns um die Deploymentkonfiguration. Mit mvn fabric8:resource generiert uns das Plugin eine Reihe von YAML Dateien unter target/classes/META-INF/fabric8/openshift für das Deployment, den Service und die externe Route.

Auch wenn viele der hinterlegten Werte eine gute Ausgangsbasis sind, wollen wir doch meistens die ein oder andere Anpassung vornehmen. Bei uns hat sich im Realfall die Kombination aus einzelnen Definitionen in einer YAML-Datei und dem maven-resources-plugin bewährt. Dabei legen wir beispielsweise folgende Anpassungen fest (unter src/main/fabric8/deployment.yaml):

Wir wollen also das Speicherlimit des Containers festlegen. Dank des maven-resources-plugin können wir dafür dann eigene Properties oder auch die bereits vorhandenen (wie z.B. artifactId) verwenden. Das schaffen wir mit folgender Anpassung der POM:

Fabric8 fügt dann unsere konkreten Einstellungen und die Standardkonfiguration zum Endergebnis zusammen. Auf diese Weise lässt sich gezielt nach gewohntem Muster alles so konfigurieren, wie man möchte. Alternativ dazu bietet das Plugin auch viele Konfigurationsmöglichkeiten über die POM direkt an; dies stellte sich bei uns jedoch als zu unübersichtlich heraus.

Zu guter Letzt können wir nun mit mvn fabric8:apply die erstellten Ressourcen im Cluster anwenden und damit unsere Anwendung deployen.


Dank des Plugins lässt sich der Deploymentvorgang schnell vereinfachen. Wir kratzen dabei jedoch nur an der Oberfläche – fabric8 bietet noch sehr viel mehr. Wird die eigene Anwendung beispielsweise mit Spring bzw. Spring Boot entwickelt, erkennt fabric8 dies und passt die Konfiguration entsprechend an – inklusive Healthchecks für Spring Boot Actuator. Der klassische Weg mit dem Docker Daemon funktioniert natürlich auch und über mvn fabric8:watch bietet das Plugin sogar ein automatisches Redeployment bei Änderungen im Workspace.

Wer nun Interesse gefunden hat, dem sei trotz des etwas holprigen Einstiegs die ausführliche Dokumentation ans Herz gelegt, ergänzt durch das Handbuch des docker-maven-plugin, welches in das fabric8-maven-plugin integriert ist. Hier lassen sich manchmal ein paar ergänzende Informationen finden.