Stare systemy mają dwie wspólne cechy: działają i denerwują wszystkich. Działają, bo lata realnego użycia dopasowały je do faktycznego biznesu. Denerwują, bo nikt nie chce ich dotykać, dokumentacja jest szczątkowa, a jeden z pierwotnych programistów odszedł trzy firmy temu.
Co naprawdę znaczy „legacy”
Nie każdy stary system to legacy. 10-letnia aplikacja na wspieranym stosie, dobrze testowana i aktywnie utrzymywana, to po prostu dojrzała. Legacy zwykle oznacza:
- Wersje platformy lub frameworka bez wsparcia bezpieczeństwa.
- Wiedzę skupioną w jednej-dwóch osobach.
- Strach przed zmianami, bo drobiazg psuje odległe funkcje.
- Ręczne wdrożenia, ręczne testy, ręczne wszystko.
- Rosnącą przepaść między potrzebami biznesu a tym, co system potrafi.
Dwie podejścia, które zawodzą
- Nie ruszać. Ryzyko się kumuluje. W końcu coś krytycznego pęka w najgorszym momencie.
- Przepisać od zera. Wielki rewrite prawie zawsze trwa dłużej niż planowano, ukryte wymagania wychodzą za późno, a równoległe działanie dwóch systemów ciągnie się tak długo, że zespół się poddaje.
Podejścia, które naprawdę działają, leżą pomiędzy.
Strategia 1: „Strangle the legacy”
Legacy działa dalej, ale nowe funkcje trafiają stopniowo do nowej warstwy. Z czasem w nowym systemie żyje coraz więcej, stary kurczy się, aż wreszcie można go wyłączyć.
Działa dla stron (strona po stronie), narzędzi wewnętrznych (moduł po module) i integracji (nowa brama API, potem przekierowanie wywołań).
Strategia 2: modernizacja w miejscu
Czasem architektura jest OK, za stary jest stos. Wtedy aktualizujemy po warstwie: język/runtime, biblioteki, framework, deployment. Po drodze dopisujemy testy automatyczne, żeby każdy krok dało się zweryfikować. Niegłośne, ale bardzo skuteczne.
Strategia 3: najpierw podzielić, potem modernizować
Duże monolityczne systemy łatwiej modernizuje się kawałkami, gdy widać szwy. Najpierw definiujemy granice w istniejącym kodzie (moduły, bounded contexts), potem wymieniamy moduł po module. Granice mają większe znaczenie niż wybór technologii.
Co zrobić, zanim powstanie jakikolwiek nowy kod
- Opisać, co system naprawdę dziś robi, nie co miał robić.
- Zidentyfikować funkcje, na których ludzie polegają codziennie, muszą działać przez całą tranzycję.
- Zidentyfikować martwe funkcje, często spora część kodu, cicho do wygaszenia.
- Zinwentaryzować dane, integracje, uprawnienia i eksporty. Właśnie tam projekty modernizacyjne zwykle się wywracają.
- Zdecydować, co znaczy „skończone” w mierzalny sposób.
Zabezpieczenia, które realnie robią różnicę
- Kopie zapasowe i przećwiczone odtworzenia, przed jakąkolwiek zmianą.
- Testy automatyczne na zachowanie, które Was interesuje, stopniowo dokładane.
- Feature flagi, zmiany do wyłączenia w produkcji bez deployu.
- Obserwowalność, logi, tracking błędów, kluczowe metryki biznesowe, żeby szybko widzieć regresje.
- Etapowe wdrażanie: nowy kod dla wewnętrznych, potem mała grupa użytkowników, potem wszyscy.
Wzorzec strangler fig. Zamiast ryzykownego przepisania „na big bang”, ruch trafia przez cienki fasadowy gateway, który stopniowo przekierowuje coraz więcej żądań do nowych usług, a legacy obsługuje resztę, aż zostanie puste.
Przykład: minimalna reguła fasady
Mały gateway może decydować per-ścieżka, czy żądanie trafia do starego monolitu czy do nowej usługi. Neutralnie względem frameworka:
app.use((req, res, next) => {
if (req.path.startsWith('/api/v2/invoices')) {
return proxy(req, res, NEW_SERVICE_URL);
}
return proxy(req, res, LEGACY_URL);
});Każdy zmigrowany moduł przenosi jeden prefiks z LEGACY_URL na NEW_SERVICE_URL. Użytkownicy nigdy nie widzą „dnia przełączenia”; zespół dowozi małe, odwracalne kroki.
Częsta pułapka: pisanie nowego systemu tak, jakby od pierwszego dnia miał mieć te same funkcje co stary. Nie musi. Zacznijcie od najmniejszego fragmentu, który ma realną wartość biznesową, udowodnijcie ścieżkę migracji, a potem powtarzajcie.
Najczęstsze błędy
- Skupienie na wyborze technologii. Fajny nowy stos nie pomaga, jeśli model danych i integracje dalej są tajemnicą.
- Czekanie na wielki rebranding zamiast naprawienia widocznych problemów. Płacą za to użytkownicy; traci się impet.
- Zbyt wczesne wyłączanie starego systemu. Dwa systemy równolegle muszą pożyć tyle, ile trzeba, żeby zaufać nowemu.
- Strata wiedzy instytucjonalnej. Pracujcie w parze z ludźmi, którzy znają system. Ich wiedza to realny majątek.
Realistyczna kolejność
- Ustabilizować: backupy, monitoring, łatki bezpieczeństwa, minimum testów.
- Zmapować: udokumentować to, co istnieje i co jest realnie używane.
- Ustawić priorytety: wybrać kawałek boli dziś i warto go zmodernizować teraz.
- Zastąpić: zbudować nową wersję obok starej.
- Przełączyć: skierować ruch, obserwować, poprawić błędy.
- Wyłączyć: stary kawałek gasimy dopiero wtedy, gdy przez jakiś czas jest „cicho”.
- Powtórzyć dla kolejnego kawałka.
