Migracja bez zatrzymywania firmy - jak przenosić system kawałek po kawałku

"Nie możemy teraz ruszać systemu. Firma stanie."

To zdanie słyszymy na każdym spotkaniu z klientem, który wie, że potrzebuje nowego systemu, ale boi się procesu migracji. I ten strach jest uzasadniony - bo w ich głowie migracja wygląda tak:

1. Zatrzymaj stary system
2. Przenieś dane
3. Uruchom nowy system
4. Módl się, żeby działał

To podejście nazywa się "big-bang migration" i jest najgorszym możliwym sposobem na modernizację systemu. Ale jest inny sposób. Sposób, w którym stary system działa do ostatniego dnia, nowy system rośnie obok niego, a firma ani przez chwilę nie traci zdolności operacyjnej.

Strangler fig pattern - natura wie lepiej

W lasach tropikalnych rośnie fikus dusiciel (strangler fig). Zaczyna życie jako nasionko na gałęzi dużego drzewa. Wypuszcza korzenie, które oplatają pień gospodarza i sięgają ziemi. Fikus rośnie latami, stopniowo przejmując światło i zasoby. Gdy stare drzewo obumiera, fikus stoi samodzielnie - z pełnym systemem korzeni, koroną i pniem. Przejście jest płynne. Nie ma momentu, w którym las jest pusty.

Martin Fowler zastosował tę metaforę do migracji systemów informatycznych. Nowy system rośnie obok starego, przejmując funkcję po funkcji. Stary system stopniowo traci odpowiedzialności, aż w końcu nie robi nic i można go wyłączyć. W dowolnym momencie procesu firma ma działający system - częściowo stary, częściowo nowy.

Jak to wygląda w praktyce

Etap 0: Audit i mapa zależności

Zanim napiszemy linijkę kodu, musimy zrozumieć stary system. Nie cały - to niemożliwe i niepotrzebne. Musimy zrozumieć:

Co system robi - lista modułów i procesów biznesowych. Zwykle to: zamówienia, magazyn, fakturowanie, raporty, CRM, cennik, logistyka. Każdy moduł to osobny kandydat do migracji.

Jak moduły zależą od siebie - zamówienia potrzebują cennika i stanów magazynowych. Fakturowanie potrzebuje zamówień. Raporty potrzebują wszystkiego. Rysujemy graf zależności.

Które moduły bolą najbardziej - rozmawiamy z ludźmi, którzy używają systemu codziennie. Zwykle 2-3 moduły generują 80% frustracji. To nasi kandydaci na pilotaż.

Jak dane przepływają - skąd przychodzą, gdzie są zapisywane, kto je czyta. Identyfikujemy punkty styku między modułami.

Ten etap trwa 1-2 tygodnie. Jego rezultat to mapa systemu z priorytetami migracji.

Etap 1: Fasada - nowy interfejs, stare dane

Pierwszy krok nie dotyka danych. Budujemy nowy interfejs w Phoenix LiveView, który czyta dane ze starej bazy danych. PostgreSQL Foreign Data Wrappers pozwalają nowemu systemowi odpytywać starą bazę jak swoją własną:

-- Nowy system "widzi" tabele starego systemu
CREATE SERVER legacy_system FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host 'stary-serwer.firma.pl', dbname 'erp_legacy');

IMPORT FOREIGN SCHEMA public
    LIMIT TO (zamowienia, klienci, produkty)
    FROM SERVER legacy_system INTO legacy;

Efekt: użytkownicy otwierają nowy, szybki interfejs, ale dane nadal leżą w starej bazie. Stary system działa równolegle - kto chce, używa starego. Kto chce spróbować nowego - proszę bardzo. Zero ryzyka, bo dane nie zostały ruszony.

To jest moment, w którym zespół widzi, że "nowy system" to nie abstrakcja - to działający interfejs z ich danymi. Opór spada dramatycznie.

Etap 2: Moduł pilotażowy - pełna migracja jednego procesu

Wybieramy jeden moduł - najczęściej ten, który najbardziej boli. Powiedzmy: zarządzanie cennikiem. W starym systemie cennik to Excel uploadowany na serwer. W nowym:

1. Migracja danych - przenosimy cennik ze starej bazy do nowej struktury w PostgreSQL. Czyścimy duplikaty, normalizujemy formaty, dodajemy brakujące constrainty.

2. Nowa logika - Phoenix LiveView z inline editing, historią zmian, walidacją w czasie rzeczywistym, uprawnieniami (kto może zmieniać ceny).

3. Synchronizacja wsteczna - nowy system zapisuje zmiany cen i replikuje je do starej bazy, żeby moduły, które jeszcze nie zostały zmigrowane (np. fakturowanie), nadal widziały aktualne ceny.

Użytkownik → Nowy system (cennik) → Nowa baza PostgreSQL
                                          ↓
                                   Synchronizacja
                                          ↓
                               Stara baza (legacy)
                                          ↓
                         Stary system (fakturowanie, magazyn)

Stary system nie wie, że cennik jest zarządzany gdzie indziej. Widzi te same dane w swojej bazie. Fakturowanie działa jak wcześniej. Nic się nie zepsuło.

Etap 3: Kolejne moduły

Powtarzamy etap 2 dla kolejnych modułów. Każdy moduł przechodzi tę samą ścieżkę:

1. Migracja danych do nowej struktury
2. Nowy interfejs w LiveView
3. Synchronizacja wsteczna do legacy (dopóki inne moduły tego potrzebują)

Kolejność migracji wynika z grafu zależności:

• Najpierw moduły niezależne (cennik, dane klientów, katalog produktów)
• Potem moduły zależne (zamówienia - potrzebują cennika i klientów)
• Na końcu moduły podsumowujące (raporty - potrzebują wszystkiego)

Z każdym zmigrowanym modułem synchronizacja wsteczna staje się mniej potrzebna. Gdy wszystkie moduły czytające cennik są w nowym systemie, synchronizacja cennika do legacy jest wyłączana.

Etap 4: Wygaszanie legacy

Przychodzi moment, w którym stary system nie robi nic. Żaden użytkownik go nie otwiera. Żaden moduł nowego systemu nie czyta z jego bazy. Ten moment zwykle przychodzi miesiące po faktycznej migracji - bo firma trzyma stary system "na wszelki wypadek".

Wygaszanie:

1. Wyłącz dostęp użytkowników (ale nie serwer)
2. Czekaj 2 tygodnie - czy ktoś się skarży?
3. Zrób ostateczny backup starej bazy
4. Wyłącz serwer
5. Zachowaj backup na 12 miesięcy (wymóg prawny)

Dlaczego to działa

Zero przestojów

W żadnym momencie procesu firma nie traci dostępu do danych ani możliwości pracy. Stary system działa do dnia wyłączenia. Nowy system jest dostępny od pierwszego dnia fasady. Przejście jest płynne - użytkownicy stopniowo przesiadają się na nowy interfejs.

Ryzyko rozłożone w czasie

Big-bang migration to jedno wielkie ryzyko: albo zadziała, albo katastrofa. Strangler fig rozkłada ryzyko na wiele małych kroków. Jeśli migracja cennika się nie uda - cofamy ten jeden moduł. Reszta systemu nie jest dotknięta. Stary cennik nadal działa.

Feedback od użytkowników na bieżąco

Po migracji pierwszego modułu użytkownicy mówią: "Fajne, ale brakuje mi opcji X" albo "W starym systemie robiłem to inaczej". Te uwagi wpływają na migrację kolejnych modułów. W big-bangu dowiadujesz się o problemach po uruchomieniu, gdy jest za późno na fundamentalne zmiany.

Wartość biznesowa od pierwszego miesiąca

Nie czekasz 12 miesięcy na "gotowy system". Po 4-6 tygodniach masz pierwszy zmigrowany moduł, który działa szybciej, jest bezpieczniejszy i wygodniejszy niż stary. Firma widzi efekty inwestycji natychmiast.

Najtrudniejsze momenty i jak sobie z nimi radzimy

Synchronizacja dwukierunkowa

Gdy część modułów jest w nowym systemie, a część w starym, dane muszą przepływać w obie strony. To najtrudniejszy techniczny aspekt migracji. Rozwiązania:

PostgreSQL Logical Replication - zmiany w nowej bazie automatycznie replikują się do starej. Zero kodu aplikacyjnego.

Oban z zadaniami synchronizacji - bardziej złożone transformacje (np. konwersja formatów) jako zadania w tle. Z transakcyjnością PostgreSQL - albo obie bazy są spójne, albo zmiana się cofa.

Event sourcing na granicy - każda zmiana generuje event, który jest konsumowany przez obie strony. Pełna audytowalność: kto, co, kiedy zmienił.

Opór użytkowników

"Stary system był lepszy" - słyszymy to przy każdej migracji. Zwykle oznacza: "przyzwyczaiłem się do starego i nie chcę się uczyć nowego". Rozwiązania:

Równoległy dostęp - przez pierwsze tygodnie użytkownicy mają dostęp do obu systemów. Nikt nie jest zmuszany do przesiadki. Gdy nowy system okaże się szybszy i wygodniejszy, przesiadka następuje naturalnie.

Champions - w każdym dziale identyfikujemy 1-2 osoby, które są otwarte na zmiany. Szkolimy je jako pierwsze. One stają się wewnętrznymi ambasadorami nowego systemu.

Quick wins - pierwszy zmigrowany moduł musi być wyraźnie lepszy od starego. Szybszy, ładniejszy, z funkcjami, których ludzie chcieli od lat. Pierwszy sukces buduje zaufanie do reszty procesu.

Jakość danych w legacy

Stara baza pełna niespójności: duplikaty klientów, produkty bez cen, zamówienia bez daty, adresy w polu "notatki". Migracja to okazja do oczyszczenia danych - ale nie można czyścić w nieskończoność.

Reguła 80/20 - czyścimy 80% problemów automatycznie (skrypty normalizacji, deduplikacji). Pozostałe 20% to edge case'y, które wymagają ludzkiej decyzji. Te zostawiamy do ręcznej weryfikacji, z interfejsem w nowym systemie, który ułatwia tę pracę.

Harmonogram typowej migracji

Dla systemu ERP średniej wielkości (zamówienia, magazyn, fakturowanie, cennik, CRM, raporty):

Łączny czas: 6-10 miesięcy. Ale wartość biznesowa pojawia się po 6-8 tygodniach (pierwszy zmigrowany moduł). A stary system działa przez cały ten czas.

Ile to kosztuje vs ile kosztuje alternatywa

Koszt migracji strangler fig

Rozłożony w czasie, przewidywalny, z wczesnym zwrotem inwestycji. Płacisz za moduł po module. Po każdym module możesz podjąć decyzję: kontynuować czy zatrzymać. Ryzyko finansowe jest ograniczone do jednego modułu.

Koszt big-bang migration

Wszystko albo nic. Płacisz za 12 miesięcy rozwoju, zanim zobaczysz jakikolwiek efekt. Jeśli po uruchomieniu system nie działa - cofasz się do zera. Pieniądze stracone, czas stracony, zaufanie zespołu stracone.

Koszt robienia nic

To jest opcja, którą firmy wybierają najczęściej - i jest najdroższa ze wszystkich. Każdy miesiąc z legacy systemem to:

• Czas pracowników na obejścia i ręczną pracę
• Utracone zamówienia przez wolność i niedostępność
• Ryzyko awarii bez możliwości naprawy
• Rosnący koszt utrzymania (sprzęt, licencje, "programista Tomek")
• Niemożność integracji z nowymi partnerami, platformami, przepisami

Te koszty nie pojawiają się jako jedna faktura. Są rozproszone po całej firmie, niewidoczne w budżecie IT. Ale po zsumowaniu - przekraczają koszt migracji wielokrotnie.

Pierwszy krok jest prostszy niż myślisz

Nie musisz teraz decydować o pełnej migracji. Zacznij od auditu:

1. Spisz moduły starego systemu
2. Oceń ból - które moduły generują najwięcej frustracji?
3. Oceń ryzyko - co się stanie, gdy stary system padnie?

Chcesz przeprowadzić ten audit z nami? Porozmawiajmy - bezpłatna konsultacja 30 minut, w której ocenimy Twój przypadek i powiemy, czy strangler fig ma sens dla Twojej firmy.