Modernizacja systemu legacy bez zatrzymywania biznesu

System legacy w Access, rozbudowanym Excelu, starej aplikacji desktopowej albo w starszym .NET da się zmodernizować bez zatrzymywania firmy, jeśli przenosi się go etapami: najpierw rozpoznanie tego, co naprawdę robi, potem nowa aplikacja webowa przejmująca kolejne funkcje, migracja danych przećwiczona na kopiach i okres równoległej pracy, w którym oba rozwiązania działają obok siebie. Najczęstszy błąd to próba jednorazowej wymiany „w weekend” – w systemach, które przez lata obrosły wyjątkami, prawie zawsze kończy się to powrotem do starego programu.

Ten wpis dotyczy systemów spoza świata aplikacji webowych w PHP. Jeśli Twój problem to stara aplikacja PHP, przeczytaj artykuł modernizacja legacy PHP bez zatrzymywania firmy.

Jak wygląda legacy poza PHP

W wielu firmach krytyczne procesy działają na narzędziach, które nigdy nie były projektowane jako systemy firmowe:

• baza Access zbudowana lata temu przez pracownika, który już nie pracuje w firmie, z formularzami, makrami i raportami,
• zestaw arkuszy Excel połączonych formułami i makrami VBA, przesyłanych mailem między działami,
• aplikacja desktopowa w Delphi, Visual Basic lub starszym .NET, instalowana na każdym stanowisku i połączona z lokalną bazą,
• program na zamówienie od dostawcy, który przestał go rozwijać albo zniknął z rynku.

Wspólne cechy są podobne: brak dokumentacji, dostęp tylko z komputerów w biurze, problemy z równoczesną pracą wielu osób, brak historii zmian, ręczne kopie zapasowe i zależność od jednego komputera lub jednej osoby. Dochodzą też kwestie systemowe – na przykład zakończenie standardowego wsparcia Windows 10 w październiku 2025 roku zmusiło część firm do sprawdzenia, czy stare programy działają na nowszych systemach.

Krok 1: rozpoznanie, co system naprawdę robi

W systemach tego typu dokumentacją jest sam system i ludzie, którzy z niego korzystają. Rozpoznanie obejmuje:

1. Inwentaryzację ekranów, formularzy, raportów i makr – co istnieje i czego ktoś faktycznie używa.
2. Obserwację pracy użytkowników – często ważne reguły działają „w głowie” pracownika, a nie w programie.
3. Analizę danych – tabele, relacje, słowniki, pola wolnotekstowe używane niezgodnie z nazwą.
4. Listę powiązań – eksporty do programu księgowego, pliki wymieniane z kontrahentami, drukowane dokumenty.
5. Listę problemów – co dziś boli najbardziej i co powinno zmienić się w pierwszej kolejności.

Szczegółową listę kontrolną takiego przeglądu opisujemy we wpisie o audycie systemu przed modernizacją.

Krok 2: wybór docelowej formy

Nie każdy legacy powinien stać się aplikacją webową, choć w większości przypadków to dobry kierunek. Aplikacja webowa daje dostęp z dowolnego miejsca, wielu użytkowników jednocześnie, centralne kopie zapasowe, uprawnienia i historię zmian.

Wyjątki, w których rozważamy nową aplikację desktopową zsynchronizowaną z serwerem:

• program steruje urządzeniami lub drukarkami specjalistycznymi,
• musi działać bez stałego dostępu do sieci, np. na hali produkcyjnej,
• przetwarza duże pliki lokalnie.

Często najlepszy okazuje się układ mieszany: aplikacja webowa jako główny system i niewielki program lokalny dla stanowisk, które tego wymagają.

Krok 3: przenoszenie funkcji etapami

Zamiast przepisywać wszystko naraz, nowa aplikacja przejmuje kolejne obszary. To wariant podejścia strangler fig dopasowany do systemów desktopowych:

1. Najpierw dane referencyjne i podgląd – klienci, produkty, słowniki dostępne w nowym systemie, ale edytowane jeszcze w starym. Użytkownicy przyzwyczajają się do nowego interfejsu bez ryzyka.
2. Potem jeden kompletny proces – np. rejestracja zleceń albo reklamacji – obsługiwany już tylko w nowej aplikacji.
3. Następnie kolejne procesy, z synchronizacją danych do starego programu tam, gdzie wciąż jest potrzebny.
4. Na końcu raporty i archiwum – stary system przechodzi w tryb tylko do odczytu.

Nowe funkcje warto włączać przełącznikami dla wybranych użytkowników lub działów, a nie dla całej firmy od razu.

Krok 4: migracja danych

Dane z Access i Excela prawie nigdy nie nadają się do przeniesienia jeden do jednego. Typowe problemy:

• ten sam klient zapisany kilka razy w różnej formie,
• daty i liczby zapisane jako tekst w różnych formatach,
• słowniki wpisywane ręcznie zamiast wybierane z listy,
• brak kluczy i relacji, które nowy system będzie wymuszał,
• pola używane przez lata do innych celów niż wskazuje nazwa.

Dlatego migrację traktujemy jak osobny projekt: skrypty przenoszące dane, raport błędów do ręcznej weryfikacji, kilka próbnych migracji na kopii i porównanie wyników z raportami ze starego systemu. Dopiero gdy liczby się zgadzają, planuje się migrację docelową.

Krok 5: praca równoległa i przełączenie

Okres równoległej pracy daje bezpieczeństwo, ale musi mieć jasne zasady:

• który system jest źródłem prawdy dla każdego rodzaju danych w danym momencie,
• jak długo trwa okres przejściowy i jakie kryteria kończą go,
• kto zgłasza rozbieżności i jak szybko są wyjaśniane,
• jak wygląda powrót, gdyby coś poszło nie tak.

Podwójne wprowadzanie tych samych danych do dwóch systemów przez dłuższy czas męczy zespół i rodzi błędy – dlatego lepiej przełączać proces po procesie niż utrzymywać pełną równoległość.

Przykład: arkusz zleceń serwisowych zamieniony w aplikację

Dobrze ilustruje to typowa sytuacja z firm usługowych. Zlecenia serwisowe prowadzone są w dużym arkuszu Excel na dysku sieciowym. Każdy dział ma swoją zakładkę, makra generują protokół do druku, a kierownik raz w tygodniu kopiuje dane do raportu. Problemy: jednocześnie może pracować jedna osoba, historia zmian nie istnieje, a po awarii dysku tracony jest dzień pracy.

Modernizacja etapami może wyglądać tak:

1. Nowa aplikacja webowa importuje co noc dane z arkusza i pokazuje je w formie listy z filtrami – na razie tylko do podglądu.
2. Rejestracja nowych zleceń przechodzi do aplikacji; arkusz zostaje do obsługi zleceń już otwartych.
3. Protokół generowany jest w aplikacji jako PDF, z tym samym układem, do którego przyzwyczaili się technicy i klienci.
4. Po zamknięciu ostatniego zlecenia ze starego arkusza plik przechodzi do archiwum w trybie tylko do odczytu.
5. Raport kierownika powstaje automatycznie z danych w aplikacji.

Na żadnym etapie firma nie traci możliwości pracy, a każdy krok można cofnąć.

Ludzie i przyzwyczajenia

Stare narzędzia bywają nielubiane, ale znane. Użytkownicy wypracowali skróty, obejścia i własne sposoby pracy. Nowy system zostanie przyjęty szybciej, jeśli przedstawiciele każdego działu biorą udział w testach od pierwszego etapu, a najczęstsze czynności wymagają w nim nie więcej kroków niż wcześniej. Krótkie instrukcje dla konkretnych stanowisk działają lepiej niż jedno obszerne szkolenie dla wszystkich.

Czego unikać

• przenoszenia wszystkich ekranów „tak jak były”, łącznie z tymi, których nikt nie używa,
• odkładania migracji danych na ostatni tydzień,
• pomijania użytkowników przy projektowaniu nowych ekranów,
• wyłączania starego programu bez archiwum w trybie odczytu,
• modernizacji bez monitoringu i kopii zapasowych od pierwszego dnia.

Następny krok

Zrób listę tego, co dziś robi Twój stary system: formularze, raporty, eksporty i osoby, które z nich korzystają. Zaznacz, który proces sprawia najwięcej problemów – od niego zwykle zaczyna się pierwszy etap. Jeśli chcesz ocenić, jak przenieść taki system do nowoczesnej aplikacji, zobacz, jak budujemy dedykowane oprogramowanie dla firm, i napisz do nas – zaczniemy od przeglądu obecnego rozwiązania i danych.