Zmieniliście ERP trzy lata temu, a stara aplikacja nadal chodzi na serwerze w kącie serwerowni. Nikt jej nie używa codziennie, nikt jej nie chce ruszać, ale nikt też nie ma odwagi jej wyłączyć. Właśnie na tym polega wygaszanie — i właśnie dlatego prawie nikt tego nie robi porządnie.
Widzimy to schemat w każdej drugiej firmie, do której nas zapraszają. Nowy system działa, procesy się przestawiły, ludzie już nie klikają w starą ikonę na pulpicie. A jednak stary program chodzi. Bo ktoś raz na kwartał wchodzi tam sprawdzić historyczną fakturę. Bo w bazie „są jakieś dane, które się mogą przydać". Bo licencja jest opłacona do końca roku. Bo — i to jest najczęstszy powód — nikt nigdy nie napisał, kiedy i jak go w końcu zgasić.
Efekt jest zawsze ten sam. Firma płaci miesięcznie za serwer, licencje, aktualizacje bazy danych, kopie zapasowe i czas administratora na coś, z czego korzystają w praktyce dwie osoby, raz na kilka tygodni. Do tego dochodzi rosnące ryzyko: system nieaktualizowany od dwóch lat, na Windows Server 2012, z bazą Firebird, której nikt w firmie już nie rozumie.
Dlaczego stare systemy nie umierają
Za każdym „nie da się tego wyłączyć" stoi konkretny, wąski powód. I prawie zawsze da się go rozwiązać za ułamek kosztu utrzymywania systemu przez kolejny rok.
Najczęściej to jedna z czterech rzeczy: historyczne faktury i dokumenty, do których księgowość musi mieć dostęp przez pięć lat wstecz. Kartoteka klientów lub kontrahentów, w której są notatki, których nikt nie przeniósł. Raport zarządczy, który ktoś uruchamia raz na kwartał i tylko tam „ładnie wygląda". Albo — najbardziej frustrujące — jedna funkcja, której nowy system po prostu nie ma, więc dwie osoby wchodzą tam z przyzwyczajenia.
Żaden z tych powodów nie uzasadnia trzymania działającego serwera z pełną instalacją aplikacji. Wszystkie da się rozwiązać osobno. Ale dopóki nikt tego nie rozpisze na papierze, wszystkie razem tworzą zaporę, przez którą projekt wygaszania nigdy nie przechodzi.
Co naprawdę oznacza „wygaszenie"
Wygaszenie to nie jest jeden dzień, w którym ktoś klika „shutdown" na serwerze. To jest projekt na 3–6 miesięcy, w którym po kolei rozbrajacie każdy powód, dla którego system dalej działa. Na końcu, kiedy już nie ma żadnego, faktycznie klikacie shutdown.
Konkretny przykład. U jednego z naszych klientów — 28-osobowa hurtownia elektrotechniczna, po migracji z autorskiego systemu Delphi + Firebird do Comarch Optima w 2019 — stara aplikacja chodziła jeszcze przez pięć lat. Dwie osoby z księgowości wchodziły tam średnio raz w tygodniu po historyczne faktury z lat 2011–2018. Cała infrastruktura — serwer w OVH, licencje, backup, godzina administratora miesięcznie — kosztowała firmę około 1600 zł miesięcznie. W skali roku 19 tys. zł za system, którego nie używano do prowadzenia biznesu.
Sunset zajął 4 miesiące. Wyeksportowaliśmy 47 tys. faktur do PDF z tabelą indeksu w Excelu, przenieśliśmy notatki z kartoteki klientów do pola tekstowego w Optimie, odtworzyliśmy jeden raport w Power BI. Serwer zgasł w piątek wieczorem. W poniedziałek nikt nie zauważył. Firma odzyskała 1 godzinę tygodniowo pracy IT i około 4 tys. euro rocznie na infrastrukturze.
Plan wygaszania — krok po kroku
Wygaszanie ma prostą strukturę, którą warto trzymać:
- Inwentaryzacja użycia. Przez 2–4 tygodnie prowadzicie prosty log: kto, kiedy, po co logował się do starego systemu. Bez tego działacie po omacku. Zwykle okazuje się, że korzysta 2–3 osoby, do 3–4 konkretnych rzeczy.
- Lista danych do zachowania. Rozpisujecie, co dokładnie musi zostać dostępne po wyłączeniu — faktury, umowy, notatki, raporty. Precyzyjnie: „faktury sprzedaży 2015–2019 w formacie PDF z indeksem po NIP i numerze". Nie „historia sprzedaży".
- Format archiwum. Wybieracie format, w którym te dane będą żyć dalej. Zwykle PDF + Excel index, plus zrzut bazy w plikach CSV. Prawie nigdy nie warto stawiać drugiej instalacji „read-only" tego samego systemu — to tylko przesuwa problem.
- Migracja tych rzeczy, które muszą działać. Jedna nieprzeniesiona funkcja albo jeden raport dobija do nowego systemu — do Optimy, Power BI, gdziekolwiek. To najczęściej 5–15 dni roboczych.
- Okres równoległy. Stary system chodzi jeszcze przez 4–6 tygodni, ale zablokowany do zapisu. Użytkownicy uczą się, że po fakturę z 2015 chodzi się do archiwum PDF, a nie do aplikacji.
- Wyłączenie i weryfikacja. Serwer gasicie, ale nie kasujecie backupu bazy przez kolejne 12 miesięcy. Jakby coś wyszło — jest z czego odtworzyć.
Ten plan nie jest skomplikowany. Skomplikowana jest tylko decyzja, żeby go w ogóle uruchomić.
Pułapki, na które warto uważać
Sunset ma trzy klasyczne pułapki, na które trafiają wszyscy pierwszym razem.
„Zrobimy to sami, kiedy będzie chwila". Ta chwila nigdy nie nadchodzi. Wygaszanie musi mieć budżet, termin i jedną osobę odpowiedzialną — inaczej stary system po prostu chodzi kolejny rok.
Eksport bez indeksu. Zrzucacie 30 tys. PDF-ów do folderu bez struktury. Za rok, kiedy księgowa szuka konkretnej faktury z 2016, okazuje się, że archiwum jest bezużyteczne. Indeks (CSV z NIP-em, datą, kwotą, numerem faktury, ścieżką do pliku) to obowiązkowa część migracji. Bez niego archiwum jest wysypiskiem.
Wyłączenie przed komunikacją. Ktoś w księgowości loguje się raz na kwartał na koniec miesiąca. Jeśli w tym miesiącu włączycie shutdown w środę, we wtorek dostaniecie telefon, że „nagle brakuje danych". Komunikacja z użytkownikami — imienna, z terminem, z instrukcją, gdzie teraz szukać danych — musi być na tydzień przed.
Kiedy to jeszcze nie moment
Nie każdy stary system nadaje się do wygaszenia w tym roku. Trzy sytuacje, w których warto poczekać:
- Nowy system nie działa jeszcze stabilnie — ryzyko cofnięcia się do starego jest realne. Sunset dopiero jak nowe środowisko pracuje bez zgrzytów przez 6+ miesięcy.
- W bazie starego systemu są dane, których nie potraficie jednoznacznie odtworzyć w nowym (np. skomplikowane kalkulacje kosztów). Najpierw zamykacie tę lukę w nowym, potem gasicie stary.
- Kończy się rok obrotowy i księgowość woli mieć „bezpieczną wersję" dostępu do historii do zamknięcia. Zaplanujcie sunset na styczeń–luty następnego roku.
Poza tymi trzema — jeśli system chodzi drugi rok „na wszelki wypadek", pora go zgasić. Każdy miesiąc dalej to koszt bez wartości.
Co zrobić w tym tygodniu
Trzy rzeczy, które da się zrobić od ręki, bez budżetu i bez decyzji zarządu.
Po pierwsze, spisujecie listę starych aplikacji, które chodzą „na wszelki wypadek". Nazwa, na jakim serwerze, kto ostatnio logował się w tym roku, ile mniej więcej kosztuje utrzymanie. Zwykle wychodzi 2–4 pozycje i suma na koniec kartki jest większa, niż wszyscy myśleli.
Po drugie, na najstarszej pozycji z tej listy włączacie logowanie użyć. Za miesiąc będziecie wiedzieć konkretnie, kto i po co tam wchodzi.
Po trzecie, dopisujecie do przyszłorocznego planu IT „wygaszenie systemu X" — z konkretnym budżetem i terminem. Jeśli tego nie zaplanujecie, nie zrobi się samo.
Wygaszanie starych systemów to jedna z tych rzeczy, o których żaden dostawca IT nie chce Wam zaproponować sam, bo to bezpośrednio zmniejsza jego przychody. Dlatego prawie nigdy się nie dzieje bez wewnętrznej decyzji.
Stary system nie zniknie sam. Wygaszanie to projekt — z terminem, budżetem i jedną osobą odpowiedzialną. Bez tego chodzi kolejny rok.