Koszt systemu legacy rzadko ogranicza się do infrastruktury, licencji i pracy zespołu utrzymaniowego. Znacznie większa część kosztu może być ukryta w wolniejszych wdrożeniach, trudniejszych integracjach, ręcznych procesach, ryzyku awarii, zależności od kilku specjalistów oraz inicjatywach biznesowych, których organizacja nie może uruchomić wystarczająco szybko.
Dlatego pytanie „ile kosztuje nas system legacy?” nie powinno kończyć się na sprawdzeniu rocznego budżetu maintenance. Żeby ocenić rzeczywisty koszt starszego systemu, trzeba spojrzeć szerzej: na koszt jego działania, wprowadzania zmian, ryzyka oraz możliwości biznesowych, które organizacja traci przez ograniczenia technologiczne.
System legacy nie staje się drogi dlatego, że jest stary. Staje się drogi wtedy, gdy koszt jego utrzymania i rozwoju zaczyna rosnąć szybciej niż wartość, którą system dostarcza biznesowi.
W skrócie:
- rzeczywisty koszt systemu legacy to nie tylko koszt jego bieżącego utrzymania,
- do TCO warto doliczyć koszt zmian, integracji, testów, wiedzy eksperckiej, ryzyka oraz utraconych możliwości biznesowych,
- najbardziej użyteczne jest porównywanie kosztów w czterech obszarach: RUN, CHANGE, RISK i OPPORTUNITY COST,
- rosnący koszt legacy nie oznacza automatycznie konieczności pełnego rewrite’u,
- decyzję o modernizacji warto podejmować na podstawie konkretnych ograniczeń i ich wpływu na biznes.
Co naprawdę składa się na koszt systemu legacy?
Najłatwiejszą częścią kosztu legacy do policzenia są wydatki widoczne bezpośrednio w budżecie IT: infrastruktura, licencje, support, utrzymanie czy praca zespołu. Problem w tym, że ten obraz jest niepełny.
Starszy system może działać stabilnie i jednocześnie generować coraz większy koszt w innych częściach organizacji. Każda zmiana trwa dłużej. Nowa integracja wymaga dodatkowych obejść. Testowanie pochłania więcej czasu. Wiedza o krytycznych mechanizmach pozostaje w głowach kilku osób. Część pomysłów biznesowych jest odkładana, ponieważ ich realizacja wymagałaby zbyt głębokiej ingerencji w istniejący system.
Najdroższy system legacy nie zawsze ma najwyższy koszt utrzymania.
Czasem najwięcej kosztuje to, czego przez niego nie można zrobić.
Dlatego do analizy kosztów warto wykorzystać szerszy model TCO – Total Cost of Ownership – uwzględniający nie tylko bieżące wydatki, ale także koszt zmian, ryzyka i utraconych możliwości.
RUN + CHANGE + RISK + OPPORTUNITY COST – prosty model TCO systemu legacy
Praktycznym punktem wyjścia może być podzielenie całkowitego kosztu systemu na cztery grupy.
| Obszar | Co obejmuje? | Przykładowe pytanie |
|---|---|---|
| RUN | Infrastruktura, licencje, support, utrzymanie, monitoring i obsługa incydentów. | Ile kosztuje samo utrzymanie systemu w obecnym stanie? |
| CHANGE | Development, testy, regresja, deployment, integracje i manualna praca potrzebna do wprowadzania zmian. | Ile kosztuje wdrożenie jednej typowej zmiany? |
| RISK | Awarie, problemy bezpieczeństwa, brak wsparcia technologii, compliance, zależność od kluczowych osób. | Jakie konsekwencje biznesowe ma awaria lub brak możliwości zmiany systemu? |
| OPPORTUNITY COST | Opóźnione projekty, niewdrożone produkty, ograniczona automatyzacja, trudności z wykorzystaniem danych i AI. | Z czego organizacja rezygnuje, ponieważ system jest zbyt trudny lub drogi do zmiany? |
Uproszczony model: rzeczywisty koszt systemu legacy = RUN + CHANGE + RISK + OPPORTUNITY COST. Dopiero spojrzenie na wszystkie cztery obszary pozwala porównać koszt dalszego utrzymywania systemu z kosztem jego modernizacji.
1. Koszt utrzymania rośnie, mimo że system prawie się nie zmienia
Jednym z najbardziej charakterystycznych sygnałów problemu z legacy jest sytuacja, w której organizacja inwestuje coraz więcej w utrzymywanie systemu, ale nie przekłada się to na proporcjonalny rozwój produktu.
Źródłem kosztów mogą być m.in.:
- starsze wersje platform wymagające dodatkowego supportu,
- niestandardowa infrastruktura,
- manualne operacje i procesy utrzymaniowe,
- specjalistyczne licencje,
- duża liczba incydentów i zgłoszeń supportowych,
- czas zespołu przeznaczany na stabilizowanie systemu zamiast jego rozwoju.
Warto więc rozdzielić budżet na „keep the lights on” oraz rozwój. Jeśli coraz większa część wydatków służy wyłącznie utrzymaniu obecnego stanu, jest to sygnał, że ekonomika systemu zaczyna się pogarszać.
2. Każda nowa funkcja kosztuje więcej niż powinna
System legacy może nadal obsługiwać bieżące procesy poprawnie, ale jego prawdziwy koszt ujawnia się podczas zmian.
Nowa funkcja, która w nowszej architekturze wymagałaby zmiany jednego modułu, w starszym systemie może uruchomić cały łańcuch zależności: analizę istniejącej logiki, modyfikacje kilku komponentów, dodatkowe testy regresyjne, ręczne wdrożenie i weryfikację integracji.
Dobry KPI: obserwuj cost per change i lead time dla podobnych zmian w kolejnych okresach. Jeżeli zakres biznesowy pozostaje podobny, ale czas i koszt realizacji systematycznie rosną, problemem może być właśnie struktura legacy.
W praktyce coraz większa część kosztu zmiany zaczyna wynikać nie z tworzenia nowej funkcjonalności, ale z konieczności bezpiecznego przeprowadzenia jej przez istniejące zależności.
3. Każda nowa integracja staje się osobnym projektem
Nowoczesne środowiska IT opierają się na integracjach. System musi wymieniać dane z aplikacjami mobilnymi, platformami SaaS, systemami partnerów, hurtowniami danych, narzędziami automatyzacji czy rozwiązaniami AI.
Jeżeli legacy nie posiada stabilnych API, ma silnie sprzężoną architekturę lub wykorzystuje niestandardowe formaty danych, każda nowa integracja może wymagać dodatkowych adapterów, warstw pośrednich i obejść.
Koszt rośnie nie tylko po stronie developmentu. Każdy kolejny workaround trzeba później utrzymywać, monitorować, testować i uwzględniać podczas następnych zmian.
Jeżeli jednym z planowanych kierunków rozwoju jest wykorzystanie sztucznej inteligencji, temat integracji, danych i architektury opisujemy szerzej w materiale modernizacja systemów legacy pod AI →
4. Wiedza o systemie staje się kosztownym i trudno zastępowalnym zasobem
W starszych systemach dokumentacja często nie nadąża za rzeczywistą logiką biznesową. Część wiedzy istnieje wyłącznie w kodzie, część w starych ticketach, a część w doświadczeniu osób, które rozwijały system przez wiele lat.
Wtedy koszt utrzymania systemu zaczyna zależeć od dostępności konkretnych specjalistów.
Ryzyko rośnie szczególnie wtedy, gdy:
- tylko kilka osób zna krytyczną logikę systemu,
- onboarding nowych developerów trwa bardzo długo,
- część technologii jest rzadko spotykana na rynku,
- zespół unika zmian w wybranych komponentach z powodu braku wiedzy,
- dokumentacja nie pozwala samodzielnie odtworzyć działania kluczowych procesów.
Warto tutaj monitorować tzw. bus factor: ile osób musi być niedostępnych, aby organizacja straciła możliwość bezpiecznego rozwijania lub utrzymywania krytycznego obszaru.
5. Testowanie i wdrożenia pochłaniają coraz więcej czasu
W legacy koszt pojedynczej zmiany często rośnie przez brak izolacji pomiędzy komponentami. Zmiana w jednym miejscu może wpływać na funkcje, które z pozoru nie mają z nią związku.
Jeżeli automatyzacja testów jest ograniczona, dużą część bezpieczeństwa zapewnia ręczna regresja. Z kolei skomplikowany proces deploymentu może wymagać dodatkowych okien serwisowych, manualnych operacji i obecności wielu osób podczas wdrożenia.
Kosztem nie jest więc tylko czas QA czy DevOps. Kosztem jest również opóźniony release i dłuższy time-to-market.
Im więcej pracy potrzeba, żeby bezpiecznie wdrożyć małą zmianę,
tym droższa staje się każda kolejna decyzja produktowa.
6. Ryzyko operacyjne i bezpieczeństwa zaczyna mieć realny koszt
Ryzyko legacy często jest traktowane jako problem jakościowy: system jest stary, trudny w utrzymaniu albo mało wygodny. Tymczasem część ryzyka można przeliczyć na konkretne konsekwencje biznesowe.
Warto analizować m.in.:
- częstotliwość i długość awarii,
- MTTR – średni czas przywracania działania,
- koszt przestoju krytycznych procesów,
- czas potrzebny na wdrażanie poprawek bezpieczeństwa,
- technologie, które tracą lub straciły wsparcie producenta,
- koszt spełnienia wymagań compliance,
- trudność w odtworzeniu środowiska po poważnej awarii.
Jedno z możliwych uproszczeń: oczekiwany koszt ryzyka = prawdopodobieństwo zdarzenia × potencjalny wpływ biznesowy. Nie zastępuje to pełnej analizy ryzyka, ale pomaga porównać koszt pozostawienia problemu z kosztem jego usunięcia.
7. Największy koszt legacy: utracone możliwości biznesowe
To koszt, którego najczęściej nie widać w budżecie IT, ponieważ nie pojawia się jako osobna faktura czy linia kosztowa.
Może jednak mieć największy wpływ na biznes.
Legacy może powodować, że:
- nowy produkt lub kanał trafia na rynek później,
- integracja z partnerem trwa kilka miesięcy zamiast kilku tygodni,
- automatyzacja procesu jest odkładana,
- dane pozostają rozproszone lub trudno dostępne,
- wdrożenie AI wymaga najpierw przebudowy warstwy danych i integracji,
- organizacja rezygnuje z części pomysłów, ponieważ ich implementacja jest zbyt kosztowna.
To właśnie opportunity cost: wartość korzyści, których firma nie realizuje ze względu na ograniczenia technologiczne.
W praktyce to często właśnie ten element zmienia rachunek ekonomiczny. System może nadal działać i mieć akceptowalny koszt utrzymania, ale jednocześnie blokować rozwój organizacji w obszarach, które są strategicznie znacznie ważniejsze.
Jak policzyć rzeczywisty koszt systemu legacy?
Nie trzeba od razu budować skomplikowanego modelu finansowego. Pierwszym krokiem może być zebranie kilku mierzalnych danych z ostatnich 6–12 miesięcy i porównanie ich z wcześniejszym okresem.
| Obszar | Co mierzyć? |
|---|---|
| RUN | Infrastruktura, licencje, support, maintenance, monitoring, obsługa incydentów. |
| CHANGE | Średni czas realizacji zmiany, koszt developmentu, liczba zależności i czas testów. |
| INCIDENTS | Liczba awarii, MTTR, czas przestoju i wpływ na klientów lub procesy. |
| PEOPLE | Czas onboardingu, dostępność kompetencji, bus factor, koszt zewnętrznych specjalistów. |
| RELEASE | Częstotliwość deploymentów, czas regresji, liczba manualnych kroków. |
| INTEGRATION | Średni czas i koszt uruchomienia nowej integracji. |
| BUSINESS | Projekty opóźnione, ograniczone lub odrzucone ze względu na możliwości systemu. |
Najcenniejsze jest porównanie trendu. Sam koszt utrzymania na poziomie X nie mówi jeszcze wiele. Znacznie ważniejsze pytanie brzmi: czy z roku na rok płacimy więcej, aby uzyskać tę samą lub mniejszą zdolność do zmiany systemu?
Kiedy koszt legacy zaczyna uzasadniać modernizację?
Nie istnieje jeden poziom kosztu, po którego przekroczeniu system należy modernizować. Znacznie lepszym sygnałem jest połączenie kilku trendów.
Modernizację warto poważnie rozważyć, jeżeli:
- koszt zmian rośnie szybciej niż ich zakres biznesowy,
- release cycle regularnie się wydłuża,
- duża część capacity zespołu jest przeznaczana na utrzymanie i stabilizację,
- każda integracja wymaga dodatkowych workaroundów,
- odejście pojedynczych specjalistów tworzy istotne ryzyko,
- system blokuje projekty o znaczeniu biznesowym,
- koszt ryzyka zaczyna być porównywalny z kosztem zmiany.
Ważne: ekonomiczne uzasadnienie modernizacji nie oznacza automatycznie pełnego rewrite’u. Często wystarczy usunąć kilka konkretnych ograniczeń – przebudować moduł, zmienić platformę, uporządkować integracje albo wydzielić najbardziej problematyczne komponenty.
Podejścia do takich decyzji opisujemy szerzej w materiale modernizacja systemów legacy – jak wybrać strategię i ograniczyć ryzyko →
10 pytań, które warto zadać przed kolejnym budżetem na system legacy
- Ile rocznie kosztuje utrzymanie systemu w obecnym stanie?
- Jak zmienił się średni koszt podobnej funkcjonalności w ciągu ostatnich 2–3 lat?
- Ile czasu mija od decyzji o zmianie do jej wdrożenia na produkcję?
- Ile osób posiada wiedzę potrzebną do bezpiecznego rozwijania krytycznych komponentów?
- Ile ręcznych procesów i obejść powstało wokół systemu?
- Jak często występują incydenty i ile kosztuje ich obsługa?
- Ile czasu i pracy wymaga nowa integracja?
- Jakie inicjatywy biznesowe zostały opóźnione przez ograniczenia systemu?
- Czy możemy wymieniać komponenty niezależnie, czy każda zmiana wymaga ingerencji w cały system?
- Co stanie się z kosztami i ryzykiem, jeśli przez kolejne trzy lata nic nie zmienimy?
Odpowiedzi na te pytania zwykle dają więcej informacji niż sam wiek systemu czy stos technologiczny. Pozwalają także zbudować business case modernizacji oparty na realnych ograniczeniach, a nie na założeniu, że „stare trzeba wymienić”.
Koszt systemu legacy – najważniejsze wnioski
- Nie patrz tylko na maintenance. Rzeczywisty koszt obejmuje także zmianę, ryzyko i utracone możliwości.
- Mierz trend, nie pojedynczą wartość. Najważniejsze jest to, czy koszt uzyskania kolejnej zmiany rośnie.
- Uwzględnij koszt biznesowy. Opóźniony produkt lub niewdrożona automatyzacja mogą kosztować więcej niż infrastruktura.
- Legacy nie oznacza automatycznie rewrite’u. Modernizacja może dotyczyć wybranych ograniczeń.
- Business case powinien porównywać koszt zmiany z kosztem pozostawienia obecnego stanu.
Dzięki temu rozmowa o legacy przestaje być dyskusją o wieku technologii. Staje się decyzją biznesową opartą na kosztach, ryzyku i zdolności organizacji do dalszego rozwoju.
FAQ – koszt systemów legacy
Najczęstsze pytania dotyczące kosztów utrzymania starszych systemów i decyzji o ich modernizacji.
Co to jest system legacy?
System legacy to istniejący system lub aplikacja, których technologia, architektura albo sposób utrzymania zaczynają ograniczać rozwój, integracje, skalowanie lub bezpieczeństwo organizacji. Sam wiek systemu nie przesądza jeszcze, że jest on legacy.
Ile kosztuje utrzymanie systemu legacy?
Nie ma jednej uniwersalnej wartości. Rzeczywisty koszt powinien uwzględniać nie tylko infrastrukturę, licencje i maintenance, ale także koszt zmian, testów, integracji, incydentów, specjalistycznej wiedzy, ryzyka i utraconych możliwości biznesowych.
Co oznacza TCO systemu legacy?
TCO, czyli Total Cost of Ownership, oznacza całkowity koszt posiadania systemu. W przypadku legacy warto analizować cztery obszary: RUN – bieżące działanie, CHANGE – koszt zmian, RISK – koszt ryzyka oraz OPPORTUNITY COST – wartość utraconych możliwości.
Kiedy warto modernizować system legacy?
Modernizację warto rozważyć, gdy system regularnie zwiększa koszt zmian, wydłuża time-to-market, komplikuje integracje, generuje istotne ryzyko operacyjne albo blokuje ważne inicjatywy biznesowe.
Czy każdy system legacy trzeba przepisać od zera?
Nie. Pełny rewrite jest tylko jedną z możliwych strategii. W zależności od problemu można zastosować refactor, replatforming, rearchitecture, wymianę pojedynczych komponentów albo etapową modernizację.
Co jest droższe: utrzymanie legacy czy modernizacja?
To zależy od systemu i jego roli biznesowej. Warto porównać koszt modernizacji z kilkuletnim kosztem dalszego utrzymania, zmian, ryzyka oraz niewdrożonych inicjatyw. W niektórych przypadkach dalsze utrzymanie będzie racjonalne, w innych modernizacja przyniesie niższy całkowity koszt w dłuższym horyzoncie.
Jak przygotować business case modernizacji systemu legacy?
Najpierw warto zebrać dane dotyczące bieżącego kosztu systemu, czasu i kosztu zmian, incydentów, integracji, dostępności kompetencji oraz projektów blokowanych przez obecne ograniczenia. Następnie można porównać scenariusz dalszego utrzymania z kosztami i efektami kilku wariantów modernizacji.
Nie wiesz, ile naprawdę kosztuje utrzymywanie obecnego systemu?
Audyt architektury, kodu, integracji i procesów utrzymaniowych pomaga wskazać, gdzie rzeczywiście powstaje koszt i które ograniczenia warto usuwać w pierwszej kolejności. Edge One Solutions może wesprzeć zarówno diagnozę systemu, jak i etapową modernizację – od software developmentu i architektury po QA, DevOps, dane i integracje.
