„Ile kosztuje modernizacja legacy code" to pytanie, na które nie da się odpowiedzieć jedną liczbą — i każda oferta, która podaje ją bez pytania o zakres, jest zgadywaniem. Realny koszt zależy od trzech zmiennych, które da się zmierzyć przed wyceną: jak głęboko dług techniczny sięga, co dokładnie ma się zmienić i czy biznes może czekać. Ten artykuł podaje widełki dla każdego poziomu i pokazuje, jak policzyć zwrot.
Najważniejsze: Modernizacja legacy code kosztuje w Polsce od 2 000 zł netto za audyt techniczny do 150 000 zł netto i więcej za przebudowę systemu krytycznego. Typowy projekt mieści się w przedziale 8 000–40 000 zł netto i trwa 2–6 miesięcy. Trzy czynniki odpowiadają za większość różnicy: zakres (co modernizujesz), stan wyjściowy (czy da się uruchomić system i czy są testy) i wymagania (czy system może działać w trakcie prac). Modernizacja prawie nigdy nie wymaga przepisania od zera — a wariant „przepiszemy wszystko" jest zwykle najdroższy i najrzadziej uzasadniony.
Poziomy modernizacji i ich koszt
Rynek wycenia modernizację w czterech poziomach. Rozróżnienie ma znaczenie, bo „modernizacja" w ofercie może oznaczać każdy z nich — a różnica w cenie jest dziesięciokrotna.
| Poziom | Co obejmuje | Czas | Koszt netto |
|---|---|---|---|
| 0. Audyt techniczny | Mapa systemu, identyfikacja krytycznych ścieżek, diagnoza przyczyn wolnych zmian, warianty wyjścia z wyceną | 1–2 tygodnie | 2 000–6 000 zł |
| 1. Uporządkowanie | Środowisko lokalne i testowe, kontrola wersji, kopie zapasowe, CI, testy wokół krytycznych ścieżek | 2–6 tygodni | 4 000–15 000 zł |
| 2. Refaktoryzacja modułów | Przebudowa najbardziej blokujących modułów, aktualizacje zależności i frameworka, poprawki bezpieczeństwa | 1–4 miesiące | 15 000–60 000 zł |
| 3. Przebudowa komponentu lub systemu | Zastąpienie wybranych komponentów lub całego systemu, migracja danych, praca równoległa | 3–12 miesięcy | 40 000–150 000 zł i więcej |
Kluczowa obserwacja: poziom 1 rozwiązuje większość problemów z „nie da się bezpiecznie zmienić". Samo odtworzenie środowiska, wprowadzenie kontroli wersji i dodanie testów wokół ścieżek krytycznych potrafi skrócić czas wdrożenia zmiany o połowę — za ułamek kosztu przepisania. Dlatego projekty zaczyna się od poziomu 0 i 1, a nie od decyzji o przepisaniu.
Co konkretnie podnosi koszt
1. Stan wyjściowy — czy da się uruchomić system. Jeśli istnieje środowisko lokalne, repozytorium i choć minimalne testy, projekt startuje z solidnego punktu. Jeśli kod żyje wyłącznie na produkcji, bez repozytorium, a baza nie ma migracji — pierwszy etap to odtworzenie tego, co jest. To potrafi pochłonąć 30–40% budżetu, zanim dotkniesz logiki biznesowej.
2. Zakres krytyczny — co naprawdę trzeba ruszyć. Systemy mają zwykle 20% kodu odpowiedzialnego za 80% problemów. Modernizacja tych 20% jest opłacalna; modernizacja pozostałych 80% to koszt bez zwrotu. Projekty, które zaczynają się od „przepiszemy cały system", przekraczają budżet najczęściej — bo zakres rośnie w trakcie.
3. Wymaganie ciągłości działania. Jeśli system może działać w trakcie modernizacji (a w większości przypadków może), pracujesz na kopii środowiska i przełączasz moduły po testach. Jeśli musi być zatrzymany — okno serwisowe, migracja bazy w całości — koszt rośnie, bo praca musi zmieścić się w wąskim przedziale czasu.
4. Stan testów. Brak testów oznacza, że każdą zmianę trzeba weryfikować ręcznie, a ryzyko regresji jest wysokie. Etap dodawania testów wokół istniejącego kodu jest droższy niż pisanie testów od razu (bo trzeba zrozumieć, co kod faktycznie robi) — ale bez niego refaktoryzacja jest hazardem.
5. Wersja PHP i frameworka. Migracja z PHP 5.x na 8.x to nie aktualizacja, ale przebudowa: usunięte funkcje, zmiany w obsłudze typów, niekompatybilne biblioteki. To często osobny projekt w projekcie.
6. Integracje zewnętrzne. Każde połączenie z zewnętrznym systemem (płatności, marketplace, ERP, bank) trzeba odtworzyć i przetestować. Przy systemach, które mają ich kilkanaście, ten etap bywa dłuższy niż refaktoryzacja samego kodu.
Koszt utrzymania po modernizacji
Modernizacja nie kończy się wdrożeniem. Po niej zostaje stały koszt utrzymania: aktualizacje zależności i frameworka, poprawki bezpieczeństwa, monitoring i bieżące poprawki. Standard to 15–25% wartości modernizacji rocznie.
Jeśli wykonawca tego nie ujmuje w ofercie, to nie znaczy, że kosztu nie będzie — znaczy, że pojawi się po roku, gdy zależności zaczną się rozjeżdżać, a Ty nie będziesz miał planu aktualizacji. Wariant tańszy w utrzymaniu to zwykle opieka techniczna z SLA niż zadaniowe zlecanie każdej poprawki osobno.
Jak policzyć zwrot
Trzy liczby po stronie kosztu
Koszt walki z kodem = liczba zmian rocznie × nadwyżka czasu na zmianę × koszt godziny zespołu.
- Przykład: 20 zmian rocznie, każda przeciąga się o tydzień, tydzień pracy zespołu to 8 000 zł → 160 000 zł rocznie.
Koszt zmian, których nie wprowadzasz = wartość funkcji i kanałów odłożonych „na po modernizacji". Ten koszt bywa największy, ale nie pojawia się w żadnym raporcie — trzeba go oszacować z biznesem, nie z kodu.
Koszt ryzyka = prawdopodobieństwo awarii × koszt przestoju. Przy systemie obsługującym sprzedaż to zwykle najprostsza liczba do policzenia i najskuteczniejszy argument.
- Po stronie zwrotu: skrócenie czasu zmian, możliwość rozwoju, usunięcie ryzyka, obniżenie kosztu utrzymania.
Okres zwrotu licz jak przy każdej inwestycji: koszt modernizacji ÷ roczna oszczędność. Powyżej 36 miesięcy projekt trzeba przeprojektować na mniejszy zakres — rzadko kiedy warto modernizować wszystko naraz.
Czego nie robić
Nie łączyć modernizacji z dodawaniem funkcji. „Przy okazji dodamy nowy moduł" to najczęstsza przyczyna przekroczenia budżetu. Najpierw odtwórz działanie w nowej strukturze, potem rozwijaj. Inaczej nie wiesz, czy problem jest w modernizacji, czy w nowej funkcji.
Nie przepisywać od zera bez audytu. Wariant „przepiszemy całość" wygląda na prostszy, ale jest droższy i bardziej ryzykowny: przez cały czas trwania projektu masz dwa systemy, a nowy trzeba doprowadzić do pełnej zgodności z tym, co stary robi — włącznie z błędami, na których opierają się procesy.
Nie wyceniać bez dostępu do kodu. Wycena na podstawie opisu „mamy stary system w PHP" jest bezwartościowa — dla wykonawcy i dla Ciebie. Każda rzetelna oferta zaczyna się od audytu.
Nie zakładać, że modernizacja rozwiąże problem organizacyjny. Jeśli zmiany są wolne, bo nikt nie podejmuje decyzji, szybszy kod tego nie naprawi.
Najczęściej zadawane pytania
Ile kosztuje audyt techniczny legacy code?
2 000–6 000 zł netto, zależnie od wielkości systemu i liczby integracji. Audyt daje mapę funkcji, identyfikację krytycznych ścieżek, diagnozę przyczyn wolnych zmian i warianty modernizacji z wyceną każdego. Koszt audytu jest ułamkiem kosztu modernizacji, a bez niego każda wycena jest zgadywaniem.
Ile kosztuje modernizacja systemu w PHP?
Typowy projekt (refaktoryzacja modułów krytycznych) to 15 000–60 000 zł netto i 1–4 miesiące. Uporządkowanie środowiska, repozytorium i testów — 4 000–15 000 zł. Przebudowa całego systemu: 40 000–150 000 zł i więcej, przy czym ten wariant jest uzasadniony rzadziej, niż się wydaje.
Czy modernizacja wymaga przepisania całego systemu?
Prawie nigdy. Najczęściej wystarczy odtworzyć środowisko, dodać kontrolę wersji i testy wokół ścieżek krytycznych, a następnie zrefaktoryzować moduły, które najbardziej blokują zmiany. To zwykle 20% kodu odpowiadającego za 80% problemów. Przepisanie od zera ma sens tylko wtedy, gdy fundamentu nie da się odtworzyć.
Jak długo trwa modernizacja?
- Audyt: 1–2 tygodnie. Uporządkowanie środowiska i testów: 2–6 tygodni. Refaktoryzacja modułów krytycznych: 1–4 miesiące. Przebudowa komponentu: 3–12 miesięcy. Najdłuższym etapem bywa nie pisanie kodu, ale odtworzenie wiedzy o tym, co system faktycznie robi — zwłaszcza gdy dokumentacja nie istnieje.
Czy system musi być wyłączony w trakcie modernizacji?
W większości przypadków nie. Pracuję na kopii środowiska i przełączam moduły pojedynczo, po testach porównawczych. Przestój występuje tylko wtedy, gdy wymaga go migracja bazy danych — wtedy planuje się go na okno o najniższym ruchu i przygotowuje procedurę powrotu.
Co się stanie, jeśli nic nie zrobię?
Nic — dopóki system nie wymaga zmian. Zamrożony system, który działa i nie jest rozwijany, nie generuje kosztu modernizacji. Problem pojawia się w momencie, gdy biznes potrzebuje zmiany, kończy się wsparcie techniczne PHP, dostawca zewnętrznego API zmienia wersję, albo kluczowa osoba odchodzi z firmy. Wtedy modernizacja staje się pilna — a pilne projekty są droższe.
Źródła i narzędzia
- PHP — wspierane wersje (kiedy kończy się wsparcie)
- Martin Fowler — Strangler Fig Application
- OWASP Top 10 — najczęstsze podatności
- SonarSource — metryki jakości kodu (dług techniczny)
👉 Chcesz wycenę modernizacji swojego systemu? Zobacz usługę modernizacji i utrzymania kodu — zaczynamy od audytu, który daje listę priorytetów i realną wycenę. Orientacyjne widełki są w cenniku. Napisz przez formularz kontaktowy lub na kontakt@informatix.com.pl.
📖 Zobacz również: Legacy code — co to jest, refaktoryzacja czy przepisanie od zera oraz case study: modernizacja aplikacji PHP.