Problem, na który wciąż natrafiają zespoły migracyjne.
Większość systemów legacy nie jest zepsuta. Jest gorzej: działają. Wystawiają faktury klientom, przenoszą dane, uruchamiają raporty i realizują wyjątki biznesowe, których nikt nie spisał.
Ryzykiem rzadko jest sam stary kod. Jest nim niewidzialny kontrakt między starym kodem, bazą danych, operatorami, zadaniami i systemami zależnymi, które niejawnie od tego zależą.
Co właściwie budujemy, po kolei.
Zwykle zaczynamy od uczynienia systemu legacy obserwowalnym. Logi, przepływy danych, harmonogramy zadań, obsługi awarii, ścieżki użytkowników i punkty integracji muszą być widoczne, zanim będzie można je wymienić.
Następnie izolujemy jeden ograniczony wycinek: API, workflow, moduł raportowy, proces integracji danych lub część frontendu. Migrujemy, wydzielając krytyczne elementy pojedynczo, zamiast obiecywać przepisanie systemu od zera.
Czego nie robimy.
Nie sprzedajemy migracji typu big bang. Nie nazywamy systemu mianem legacy tylko dlatego, że używa starego frameworka. Nie wymieniamy stabilnego oprogramowania bez zrozumienia, dlaczego przetrwało.
Nie podejmujemy się też pracy migracyjnej, w której plan jest głównie marketingowy: nowe diagramy architektury, brak ścieżki przełączenia, brak akceptacji operatorów i brak budżetu na analizę.