Ile kosztuje modernizacja starego systemu PHP?

Znam ten obrazek z dziesiątek rozmów. W firmie działa system postawiony w 2012 roku. Obsługuje zamówienia, magazyn, czasem całą produkcję. Programista, który go napisał, od dawna nie odbiera telefonu, dokumentacji nigdy nie było, a ostatnia poważniejsza zmiana skończyła się tygodniem gaszenia pożarów. Więc nikt niczego nie rusza. System działa — i cała firma wie, że to „działa" wisi na włosku. Prezes wie najlepiej, bo to on budzi się w nocy. No i to on w końcu zadaje pytanie: ile kosztuje wyjście z tej pułapki?

Mniej, niż się obawiasz, i na pewno nie jednorazowo. Modernizację starego systemu PHP zaczynamy od audytu — to zwykle jeden pakiet 40 godzin, czyli 5000 zł netto. Potem powstaje plan, a samo przepisywanie idzie w miesięcznych pakietach przy stawce 125 zł netto za godzinę pracy zespołu. Rozbijmy to na kroki.

Krok pierwszy: audyt, czyli ile w tym systemie jest jeszcze życia

Zanim ktokolwiek cokolwiek Ci obieca, trzeba zajrzeć pod maskę. W audycie sprawdzamy wersję PHP i bibliotek, stan bazy danych, zabezpieczenia, jakość kodu oraz to, czy istnieją jakiekolwiek kopie zapasowe — zaskakująco często okazuje się, że nie istnieją albo nikt nigdy nie próbował ich odtworzyć. Pytamy też o rzeczy pozatechniczne: które moduły firma naprawdę wykorzystuje, a które leżą odłogiem od lat, bo procesy dawno uciekły do Excela.

Wynik to krótki raport z planem: co jest groźne i wymaga działania od zaraz, co można przepisać w drugiej kolejności, a czego nie ma sensu ratować wcale. Dostajesz też nasze zdanie wprost. Czasem brzmi ono „ten system da się uratować", a czasem „szkoda pieniędzy na reanimację — budujemy nowy rdzeń obok". Za tę szczerość audyt płaci się sam.

Ma on jeszcze jedną zaletę: dostajesz dokument, który zrozumie i zarząd, i każdy kolejny wykonawca. Nawet gdybyś dalszą część robił z kimś innym, ta wiedza zostaje u Ciebie, a nie w czyjejś głowie.

Modułami czy od zera?

To najważniejsza decyzja całej modernizacji i zarazem główna dźwignia kosztów.

Droga pierwsza: przepisywanie modułami. Stary system pracuje dalej, a my co miesiąc przenosimy kolejny fragment na aktualną wersję PHP — zaczynając od tego, co najbardziej boli albo niesie największe ryzyko. Nowe moduły działają obok starych, użytkownicy przechodzą płynnie, często w ogóle tego nie zauważając. Zaleta: koszty rozłożone w czasie i firma nie staje ani na dzień. Wada: przez jakiś czas utrzymujesz dwa światy naraz.

Droga druga: nowy system stawiany od zera obok starego. Wybieramy ją, gdy kod nie nadaje się do ratowania albo gdy przy okazji zmienia się tyle procesów biznesowych, że przenoszenie starych rozwiązań jeden do jednego mija się z celem. W krótkim okresie kosztuje więcej, w perspektywie dwóch–trzech lat bywa tańsza.

W praktyce najczęściej wychodzi hybryda: moduły krytyczne dla biznesu od zera, reszta przenoszona stopniowo. Proporcje ustawia audyt, nie czyjeś widzimisię.

Co decyduje o koszcie modernizacji

Rozpiętość jest spora — od kilku pakietów po ponad rok pracy — a o miejscu w tych widełkach przesądza kilka rzeczy.

Rozmiar i splątanie kodu. Nie chodzi o liczbę linijek, tylko o to, czy logika biznesowa siedzi w jednym miejscu, czy jest rozsmarowana po szablonach, zapytaniach SQL i doklejanych latami wtyczkach.

Baza danych. Zaskakująco często to ona okazuje się największym problemem — lata dopisywania kolumn „na chwilę" robią swoje. Migracja danych z porządkowaniem bywa osobnym etapem z własnym budżetem.

Integracje. Wszystko, co system wymienia z księgowością, kurierami czy sklepem internetowym, trzeba przepisać i przetestować równolegle ze starą wersją, żeby niczego nie zgubić po drodze.

Wymóg ciągłości. Jeśli system może stanąć na weekend, jest prościej. Jeśli musi chodzić non stop, bo firma na nim jedzie, przełączenia planujemy jak operacje na otwartym sercu — i to kosztuje dodatkowe godziny.

No i zakres zmian „przy okazji". Modernizacja to naturalny moment na poprawienie procesów, ale każde „skoro już ruszamy, to może jeszcze..." przesuwa budżet. Lepiej świadomie ustalić, co wchodzi teraz, a co poczeka na spokojniejszy etap.

Ile kosztuje odkładanie tej decyzji

Teraz druga strona rachunku, o której mówi się rzadziej: nicnierobienie też ma swój cennik.

Stare wersje PHP nie dostają poprawek bezpieczeństwa. Każdy miesiąc na wersji bez wsparcia to loteria, w której główną wygraną jest wyciek danych klientów albo zaszyfrowany serwer i okup.

Hosting robi się problemem. Dostawcy wygaszają obsługę muzealnych wersji, a oferty, które zostają, są coraz droższe i coraz gorsze technicznie.

Ludzie. Programistów chętnych do grzebania w bardzo starym kodzie ubywa z roku na rok, a ich stawki rosną — bo to robota, za którą mało kto się dziś zabiera z własnej woli.

I codzienny podatek od splątania: każda zmiana w takim systemie trwa dwa–trzy razy dłużej, niż powinna. Płacisz go przy każdej drobnej poprawce, tylko nigdy nie widzisz go jako osobnej pozycji na fakturze.

Coraz częściej dochodzi jeszcze presja z zewnątrz. Duzi kontrahenci i ubezpieczyciele wysyłają ankiety bezpieczeństwa z pytaniem o wersje używanego oprogramowania — i muzealny PHP potrafi zablokować kontrakt szybciej niż cena.

Zsumuj to wszystko, a wyjdzie, że modernizacja nie jest kosztem dodatkowym. Jest kosztem, który już ponosisz — rozmytym, comiesięcznym i bez żadnej wartości w zamian.

Jak taką modernizację prowadzimy

U nas wygląda to tak: audyt, plan pocięty na etapy, potem praca w miesięcznych pakietach — najczęściej 80 godzin, czyli 10000 zł netto miesięcznie. Najpierw powstaje nowy, bezpieczny rdzeń (nasze MVP modernizacji), potem kolejne moduły przechodzą na jasną stronę, a stary system gaśnie po kawałku. W każdej chwili wiesz, co już przeniesione, co w trakcie i na co poszły godziny z pakietu.

Po wszystkim system wraca do normalnego cyklu życia: rozwój w pakietach, gdy są pomysły, tryb utrzymaniowy, gdy potrzebny jest spokój. A Ty przestajesz się budzić w nocy. Więcej o naszym podejściu przeczytasz w tekście o przepisywaniu starych systemów na najnowsze wersje PHP.

Masz w firmie system, którego wszyscy się boją? Napisz do nas — zaczniemy od audytu, nie od faktury na pół roku z góry.