Als Backe, einer der größten Generalunternehmer Norwegens, einen konzernweiten Vertrag mit Rucoria unterzeichnete, war die Einführung einer neuen Plattform nur ein Teil der Arbeit. Jahrelange Projekthistorie musste ebenfalls mitziehen.
Über zwölf Regionen hinweg mussten mehr als 100 aktive Projekte und große Mengen an historischen Daten aus Alt-Systemen extrahiert, in eine neue Struktur überführt und validiert werden, und das bei laufendem Tagesgeschäft.
Und mit „historischen Daten" war weit mehr gemeint als alte Projektakten. Dazu gehörten Gewährleistungsfälle mit ihrer kompletten Fallhistorie, Kommunikation zwischen Backe und Wohnungskäufern, Fotos und Dokumentation, Pläne und Wartungsdokumentation, Begehungsprotokolle sowie unterschriebene Übergabeprotokolle.
Informationen also, die Backes Teams noch Jahre nach dem Projektabschluss brauchen können.
Das Migrationsprogramm zog sich über mehrere Monate und wurde planmäßig abgeschlossen. Am interessantesten war jedoch, was zwischendurch passierte: Mit jedem gelernten Schritt wurde die Migration schneller und wiederholbarer. In der letzten Region war die eigentliche Datenmigration innerhalb eines einzigen Tages fertig.
Warum die Historie überhaupt mitnehmen?
Es gibt einen einfacheren Weg, eine neue Plattform einzuführen: einen Schlussstrich ziehen.
Neue Projekte und Fälle laufen im neuen System. Alles Historische bleibt, wo es ist.
Das macht die anfängliche Migration einfacher, kann aber die tägliche Arbeit für Jahre danach mühsam machen.
Ein Gewährleistungsfall, der heute eingereicht wird, kann eine Wohnung betreffen, die vor mehreren Jahren übergeben wurde. Wer den Fall bearbeitet, braucht möglicherweise Zugriff auf frühere Fälle, Kommunikation mit dem Wohnungskäufer, Fotos aus einer Begehung, Pläne, frühere Entscheidungen oder unterschriebene Übergabedokumente.
Bleibt diese Historie im Alt-System, müssen Mitarbeitende zwischen alter und neuer Plattform hin- und herwechseln, je nachdem wann ein Projekt oder Fall entstanden ist.
Backe wollte etwas anderes: einen einzigen Ort, an dem sich mit Vergangenheit und Gegenwart arbeiten lässt.
Die historischen Daten nach Rucoria mitzunehmen macht diese Historie außerdem zum Teil derselben Datengrundlage wie neue Projekte und Fälle. Statt alte Informationen nur zum Nachschlagen zu archivieren, kann Backe historische und aktuelle Daten gemeinsam nutzen, um Muster zu erkennen, Projekte und Regionen zu vergleichen und mit der Zeit ein vollständigeres Bild aufzubauen.
Projekthistorie kann auch lange nach der Übergabe entscheidend sein. Wenn Jahre später Rückfragen oder Auseinandersetzungen entstehen, kann es kritisch werden, nachvollziehen zu können, was gemeldet, kommuniziert, dokumentiert, gelöst und unterschrieben wurde.
Das Ziel war nicht einfach, Backes historische Daten zu bewahren. Das Ziel war, die relevanten Informationen zugänglich, verknüpft und nutzbar zu halten.
Zwölf Regionen, ein Migrations-Playbook
Backe ist in ganz Norwegen aktiv, mit lokalen Gesellschaften in zwölf Regionen. Über die Jahre haben diese Gesellschaften erhebliche Mengen an Projektdaten in verschiedenen Alt-Systemen angesammelt.
Aber die Systeme waren nicht die einzige Variable. Backe hat sie unterschiedlich genutzt, entsprechend den Projekten, lokalen Prozessen und Arbeitsweisen.
Das hieß: Migration konnte nicht einfach heißen, ein generisches Import-Skript zwölfmal auszuführen. Die Daten mussten verstanden, extrahiert, auf die passende Struktur in Rucoria abgebildet und für jede Region validiert werden.
Auch der Umfang variierte. Einzelne Gesellschaften konnten grob 5.000 bis mehr als 15.000 Fälle mitbringen. Und ein einzelnes Projekt konnte für sich genommen bereits eine erhebliche Datenmenge enthalten. Ein Projekt umfasste zum Beispiel mehr als 12.000 Dateien mit über 16 GB an Daten.
Backes Entscheidung, diesen Schritt zu gehen, war das Ergebnis jahrelanger Evaluierung verschiedener Lösungen. Mårten Skällenäs, ehemaliger Director bei Backe Entreprenør AS, formuliert es so:
„Wir haben im Laufe der Jahre verschiedene Lösungen getestet und stellen fest, dass Rucoria eine einzigartige Plattform bietet, die sowohl hochflexibel ist als auch aktuelle und künftige Anforderungen erfüllt. Uns beeindruckt zudem, wie das Team arbeitet und welche Ambitionen es verfolgt. Deshalb ist die enge Zusammenarbeit mit Rucoria für uns selbstverständlich."
Statt einen einzigen konzernweiten Cutover zu versuchen, teilten Backe und Rucoria das Programm Region für Region auf: zwölf Migrationen nacheinander, alle nach demselben übergeordneten Playbook, das sich mit jedem Durchgang verbesserte.
Vorsichtig starten. Lernen. Dann beschleunigen.
Die ersten Migrationen dauerten am längsten.
Die Teams verbrachten mehrere Wochen mit Planung, Entwicklung des Migrations-Tooling, Mapping der Datenstrukturen, Testen der Übertragung und Validierung der Ergebnisse. Diese Arbeit legte das Fundament für alles Weitere.
Jede abgeschlossene Region brachte neues Wissen. Das Tooling wurde besser. Die Teams wurden besser darin, Unterschiede in der Datenstruktur und Nutzung zu erkennen. Validierung wurde effizienter, und Probleme, die beim ersten Mal Untersuchung erforderten, ließen sich zunehmend vorhersehen.
Das Programm beschleunigte sich.
Gegen Ende konnten mehrere Regionen innerhalb einer Woche abgewickelt werden. Für die letzte Region war die eigentliche Datenmigration an einem Tag erledigt.
Diese Beschleunigung war nicht das Ergebnis von Abkürzungen. Sie entstand daraus, dass viele der schwierigen Probleme früher im Programm bereits gelöst worden waren.
Zu diesem Zeitpunkt war Migration ein wiederholbarer Prozess geworden, kein neues Projekt jedes Mal.
Die richtigen Daten an den richtigen Ort bringen
Rucorias Entwickler bauten eigens Migrations-Tooling, um strukturierte Daten und Dateien aus den Alt-Systemen zu extrahieren und in Rucoria zu überführen.
Aber Extraktion war nur ein Teil der Arbeit.
Weil Backe seine bestehenden Systeme unterschiedlich genutzt hatte, musste das Migrations-Setup für jedes System angepasst und validiert werden. Das Team musste sicherstellen, dass die richtigen Daten extrahiert wurden, dass alte Strukturen an den passenden Stellen in Rucoria landeten und dass das Angekommene mit dem Erwarteten übereinstimmte.
Große Migrations-Batches konnten parallel verarbeitet werden, um die Übertragungszeit zu verkürzen. Während des gesamten Prozesses wurden Daten und Dateien geprüft und getestet, mit abschließenden Zählprüfungen zur Verifikation der Migration.
Nichts galt als abgeschlossen, nur weil ein Import fertig war.
Und nicht alles lief automatisch. Ein kleiner Anteil an Dateien scheiterte im ersten Durchgang an der Validierung, zum Beispiel wegen Dateiformaten oder übergroßen Anhängen, und musste manuell nachbearbeitet werden statt sauber per Skript übertragen zu werden. In einer Region waren Teile der Quelldaten nicht sauber genug strukturiert, um automatisch abgebildet zu werden, sodass Wohnungstyp-Klassifizierungen im Nachhinein manuell korrigiert werden mussten.
Es gab auch bewusste Entscheidungen darüber, was nicht migriert wird. Ältere Fallhistorien aus einem separaten CRM-System wurden außerhalb des Migrationsumfangs belassen, nachdem der dafür nötige Aufwand gegen die Wahrscheinlichkeit abgewogen wurde, dass diese Informationen im Tagesgeschäft überhaupt gebraucht werden.
Diese Unterscheidung ist wichtig: Eine erfolgreiche Migration bedeutet nicht zwingend, jedes einzelne Stück historischer Daten mitzunehmen. Sie bedeutet zu verstehen, was mitmuss, es korrekt abzubilden und zu verifizieren, dass dem Ergebnis vertraut werden kann.
Eine Migration dieser Größenordnung braucht immer noch menschliches Urteilsvermögen und Qualitätssicherung, nicht nur ein Skript, das „erfolgreich" meldet.
Jede Gesellschaft brauchte außerdem einen kontrollierten Cutover. Zu einem vereinbarten Zeitpunkt wurden neue Kundenmeldungen im Alt-System vorübergehend geschlossen, die letzten Daten extrahiert, migriert und validiert, und dann wurde die Gesellschaft für neue Fälle in Rucoria geöffnet.
Über das gesamte Programm hinweg lief bei Backe der reguläre Betrieb weiter, während die Gesellschaften auf die neue Plattform wechselten.
Martin Borg, Qualitätsmanager bei Backe Entreprenør AS, formuliert es so:
„Nach der Entscheidung für Rucoria wollten wir alle unsere Projekte und Daten an einem Ort haben. Mehr als 100 aktive Projekte und Tausende von Wohnungen zu migrieren und dabei den normalen Betrieb aufrechtzuerhalten, verlangte sorgfältige Planung und enge Zusammenarbeit. Dank geschulter Teams in beiden Organisationen und einer starken Arbeitsbeziehung ist der Übergang bemerkenswert reibungslos verlaufen."
Backe’s programme also ran alongside other legacy-system migrations handled by Rucoria’s team during the same year. Experience across these projects helped strengthen Rucoria’s migration tooling and approach further.
H2: Die Technik zählte. Die Menschen genauso.
Ein kleines Kernteam trieb das Programm konzernweit voran. Oskar Björk und Victor Minge auf Backes Seite hielten den Implementierungsprozess am Laufen, während Martin das Gesamtprogramm im Griff behielt. Ein dedizierter Datenspezialist übernahm die technische Extraktion aus der Alt-Umgebung, in enger Abstimmung mit Rucorias Technologie- und Customer-Success-Teams.
Klare Verantwortlichkeiten und straffe, aber realistische Deadlines hielten das Programm in Bewegung. Genauso wichtig: Die Menschen aus den einzelnen Gesellschaften waren früh eingebunden.
Sie kannten die Projekte, verstanden, wie ihre Region die Alt-Systeme tatsächlich genutzt hatte, und konnten zwischen technischen Anomalien und Informationen unterscheiden, die schlicht lokale Arbeitsweisen widerspiegelten.
Die Teams akzeptierten außerdem, dass sich eine Migration dieser Größe nicht vorher perfekt auf dem Papier planen lässt. Kurze, häufige Status-Meetings dienten dazu, Blocker aufzulösen und Entscheidungen zu treffen, während der Gesamtansatz iterativ blieb: migrieren, validieren, lernen, verbessern.
Migration und Adoption liefen gemeinsam
Backe und Rucoria haben Datenmigration und Implementierung nicht als zwei getrennte Projekte behandelt.
Wenn eine Gesellschaft nach Rucoria wechselte, kamen ihre historischen Projekte mit. Gleichzeitig wurden die Menschen, die die Plattform tatsächlich nutzen sollten, geschult und begannen im Kontext ihrer eigenen Projekte und Zuständigkeiten mit der Arbeit.
Dieser zeitliche Zusammenhang zählt.
Nutzer zentral zu schulen und dann Monate später zu erwarten, dass sie das Gelernte anwenden, schafft eine unnötige Lücke zwischen Lernen und Tun. Backe hat stattdessen das lokale Onboarding an den Zeitpunkt gekoppelt, an dem jede Region tatsächlich auf die Plattform wechselte.
Nutzer konnten Rucoria anhand vertrauter Projekte, vertrauter Fälle und echter Arbeit lernen.
Migration, Implementierung und Adoption passierten gemeinsam.
Was Backe heute hat
Backe arbeitet heute auf einer gemeinsamen Plattform, mit gemeinsamen Prozessen und Vorlagen über Wohnungs- und Gewerbeprojekte hinweg.
Für die Menschen, die täglich mit Kunden und Projekten arbeiten, sind historische und neue Informationen in derselben Umgebung verfügbar. Ein neuer Gewährleistungsfall lässt sich bearbeiten, wenn die relevante Projekthistorie bereits zugänglich ist, statt dass Nutzer zwischen alten und neuen Systemen suchen müssen.
Was eine Gesellschaft lernt oder aufbaut, lässt sich außerdem an anderer Stelle wiederverwenden, statt lokal neu erfunden zu werden. Und mit historischen und aktuellen strukturierten Daten auf einer Plattform hat Backe eine stärkere Grundlage, um Muster zu erkennen, Projekte und Regionen zu vergleichen und konzernweit zu lernen.
Der unmittelbare Nutzen ist einfachere tägliche Arbeit.
Der langfristige Nutzen ist eine gemeinsame Datengrundlage.
Sieben Lektionen aus der Migration
Jede Alt-Umgebung ist anders, aber mehrere Lektionen aus dem Backe-Programm gelten weit über diese spezielle Migration hinaus.
1. Geben Sie der Migration echte Verantwortlichkeit. Dedizierte Ressourcen werden zentral und lokal gebraucht, mit klaren Rollen, Zuständigkeiten und der Befugnis, Entscheidungen zu treffen.
2. Machen Sie es zur Priorität. Migration darf nicht das Thema sein, das alle für wichtig halten, für das aber niemand Zeit reserviert. Straffe, realistische Deadlines schaffen Momentum.
3. Binden Sie lokale Nutzer früh ein. Die Menschen, die am nächsten an den Projekten sind, verstehen die Daten oft besser als alle anderen. Ihr Wissen ist entscheidend, wenn historische Strukturen in eine neue Plattform übersetzt werden.
4. Entscheiden Sie, was es wert ist, migriert zu werden. Mehr Daten sind nicht automatisch besser. Legen Sie fest, was die Nutzer wirklich brauchen, was langfristigen Wert hat und wo der Migrationsaufwand gerechtfertigt ist.
5. Warten Sie nicht auf Perfektion. Große Migrationen bringen Dinge ans Licht, die sich aus einem Planungsdokument nicht vorhersagen lassen. Vorwärtsgehen, validieren, lernen, verbessern.
6. Kombinieren Sie Migration mit Implementierung. Die historischen Daten mitzunehmen und gleichzeitig die neue Arbeitsweise einzuführen, macht den Übergang von Tag eins an nützlicher.
7. Schulen Sie Menschen dann, wenn sie das Wissen brauchen. Lokales, projektbezogenes Onboarding nahe am Go-Live ist nützlicher als generische Schulung lange bevor Nutzer im System zu arbeiten beginnen.
Die vielleicht größte Lektion: Große Migrationen werden nicht einfach. Sie werden beherrschbar, wenn die richtigen Menschen, das richtige Tooling und der richtige Prozess vorhanden sind.
Eine Partnerschaft, die in beide Richtungen wirkt
Das Programm hat auch Rucorias eigene Migrations-Fähigkeiten verändert. Jede Region war eine weitere Gelegenheit, Tooling, Validierungsmethoden und Playbook zu verbessern, Wissen, das jetzt in künftige Migrationen einfließen kann.
Lars-Thomas Stene, CCO bei Rucoria:
„Backe hat harte Fragen gestellt und uns durchgehend an hohen Ansprüchen gemessen. Genau die Art Partner, die uns besser macht. Jede Region, die wir gemeinsam migriert haben, hat uns etwas beigebracht, das wir seither in die Art eingebaut haben, wie wir das für jeden Kunden angehen. Wir haben nicht nur Backes Daten umgezogen, wir sind gemeinsam mit ihnen gewachsen."
Planen Sie einen ähnlichen Wechsel?
Historische Projektdaten sollten nicht der Grund sein, weshalb eine Organisation auf einer Alt-Plattform bleibt.
Das Backe-Programm hat gezeigt, was ein strukturierter Ansatz erreichen kann: Mehr als 100 aktive Projekte verteilt auf zwölf Gesellschaften umgezogen, jahrelange Projekthistorie in dieselbe Umgebung wie neue Arbeit überführt und ein Migrationsprozess, der mit jeder Gesellschaft schneller und wiederholbarer wurde.
Wenn Sie einen Wechsel von einer bestehenden Bausoftware erwägen und verstehen wollen, was die Migration Ihrer Projekte und historischen Daten tatsächlich bedeutet, nehmen Sie Kontakt mit dem Rucoria-Team auf.
