Porting Project: Von Gupta auf .NET.

Rund fünf Jahre dauerte das Migrationsprojekt von Gupta auf .NET. Über zwei Millionen Programmzeilen, verteilt auf rund 100 verschiedene Programme, mussten migriert werden. Ein Hosenlupf und die Basis für das eigentliche Refactoring.

Als Michel Brandenberger vor 13 Jahren zur KMS stiess, war von einem Technologiewechsel noch nicht die Rede. .NET stand noch in den Kinderschuhen. Der Team Developer von Gupta war das Entwicklungs-Tool. Michel war damals schon Datenbank-lastig unterwegs, brachte jedoch auch Erfahrungen in anderen Technologien mit.

«Im Rahmen des Einführungsprojektes der Stadt Zürich kamen auf einmal ganz neue Dimensionen an Massenverarbeitungen auf uns zu», erzählt Michel. Bis dahin wurden die Batchverarbeitungen auf einzelnen GUI-Clients ausgeführt. In Zürich führte das zu Abstürzen. Erste Web-Services und die Verteilung über verschiedene Server würden das Problem lösen. Mit Gupta war dies allerdings nicht realisierbar.

Michel entwickelte für Zürich die ersten Prototypen im neuen Framework .NET. «Wir konzentrierten uns damals lediglich auf die Hintergrundverarbeitungen», sagt Michel heute.

Es wurde immer klarer: Mit Gupta würde die KMS längerfristig in eine Sackgasse einlenken. Ein Technologiewechsel drängt sich auf. Ganz neu entwickeln oder den Zwischenschritt über eine technologische Migration machen? Diese Frage stand im Raum. Die aktuellen Erfahrungen aus dem Refactoring rechtfertigen den damaligen Entscheid: Eine direkte Neuentwicklung hätte die Kapazität der damals noch wesentlich kleineren KMS gesprengt.

Stefan Arnold koordinierte damals die gesamte Migration auf .NET. Sie entschieden sich für den damals bereits erfahrenen Anbieter, Fecher, mit seinem Porting Project (PPJ).

«Fecher migrierte mehr als 2 Millionen Codezeilen», kann sich Stefan erinnern. Und bevor sie überhaupt migrieren konnten, waren aufwändige Bereinigungsarbeiten im bestehenden Gupta-Code notwendig. Die rund 100 verschiedenen nest-Programme referenzierten sich gegenseitig. Nicht zu gebrauchen unter .NET. «Wir mussten den Code zuerst entflechten», erinnert sich Stefan. Und auch nach der Migration, die Fecher durchführte, standen diverse Bereinigungen an. Für einige Vor- und Nachbearbeitungen entwickelte die KMS kleine Hilfsprogramme, welche die Fleissarbeit übernahmen.

Die Migration fand in verschiedenen Etappen statt. Sie hätten damals erst einmal ein, zwei Programme migriert und an die Kunden ausgeliefert, erzählt Stefan. «Dieses Vorgehen brachte die Herausforderung mit sich, das Zusammenspiel zwischen den verschiedenen Technologien zu gewährleisten.»

Eine weitere Hürde nahm die KMS hinsichtlich Reporting. «Pro Kunde sind zwischen 200 bis 500 verschiedene Reports im Einsatz», weiss Stefan. Er rechnet kurz hoch: 11 Kantone und unzählige Gemeinden mal Anzahl Reports. Eine ungeheure Masse, die migriert werden musste.

«Mit dem PPJ hatten wir zwar einen neuen Code, eine neue Sprache – aber noch keine bessere Software», meint Michel. Erich hätte diesbezüglich jeweils von altem Wein in neuen Schläuchen gesprochen. Die Migration habe gewisse Dinge vereinfacht und den technologischen Druck entschärft. Das eigentliche Refactoring war damit für einen Moment aufgeschoben. «Der eigentliche Wandel findet gerade erst statt. Wir investieren heute massiv in die neue Software-Generation», ist sich Michel sicher.