Niemal w każdej polskiej firmie z 15-letnim stażem stoi jakaś aplikacja, której wszyscy się trochę boją. Napisał ją kuzyn właściciela w 2011 roku w Accessie. Albo zewnętrzny freelancer w 2014 w WinForms-ach. Albo „ten chłopak, który robił staż". Działa. Trzyma firmę. I już od dawna dłużej zajmuje wymyślanie, jak ją obejść, niż faktyczna praca w niej.
Ten tekst jest o tym, jak podjąć decyzję, którą większość MŚP odkłada o pięć lat za długo: co zrobić z taką aplikacją. Bo każda z trzech ścieżek — utrzymać, przepisać od zera, zastąpić gotowym SaaS-em — ma swój moment, w którym jest słuszna, i moment, w którym jest pomyłką.
Sygnały, że stara aplikacja zaczyna kosztować
Nikt nie budzi się rano z postanowieniem „dziś przepiszemy nasz system magazynowy". Ten moment przychodzi po cichu, w postaci serii drobnych symptomów. Jeśli rozpoznajesz u siebie trzy z poniższych — temat jest realny.
- Aplikacja chodzi tylko na jednym konkretnym komputerze w firmie (zwykle leciwym), bo „na innych nie wstaje".
- Po każdej aktualizacji Windowsa coś przestaje działać — drukowanie, eksport do PDF, połączenie z bazą.
- Nikt już nie wie, gdzie jest kompletny kod źródłowy. Są dwa archiwa ZIP z różnymi datami i nikt nie umie powiedzieć, które jest aktualne.
- Pracownicy w terenie nie mogą z niej korzystać, bo wymaga RDP-a do biura albo VPN-a, który połowa zespołu kojarzy z „tym, co nie działa po południu".
- Każda drobna zmiana — nowy wzór wydruku, dodatkowe pole, inny status zamówienia — kosztuje 30 godzin pracy zewnętrznej firmy, bo nikt już nie pamięta, jak to było zrobione.
- Nowo zatrudniona osoba potrzebuje dwóch dni na to, żeby aplikacja w ogóle ruszyła na jej laptopie.
Jeśli odkładasz prostą zmianę „bo Maciek powiedział, że tego dotykać nie wolno" — to ten moment. Aplikacja przestała Ci służyć, zaczęła Ci dyktować, co możesz robić.
Trzy ścieżki: utrzymać, przepisać, migrować
W realiach MŚP są dokładnie trzy sensowne odpowiedzi. Nie ma czwartej, mimo że konsultanci czasem sprzedają hybrydy.
- Utrzymać i kontrolowanie poprawić (refactor). Aplikacja zostaje, ale spina się z aktualnym stosem, dostaje testy, dokumentację i 2-3 najbardziej irytujące błędy zostają naprawione.
- Przepisać od zera (rewrite). Wyrzucamy stary kod, piszemy nową aplikację, która robi to samo, ale w nowoczesnym stosie (np. .NET 8 + SQL Server + przeglądarka).
- Zastąpić gotowym SaaS-em. Rezygnujemy z własnego oprogramowania, kupujemy gotowy produkt z półki i migrujemy do niego dane oraz proces.
Każda z tych ścieżek kosztuje inaczej i daje co innego. Wybór nie jest sprawą gustu — jest sprawą tego, jak bardzo Twój proces różni się od reszty rynku i jak bardzo aplikacja jest Twoją przewagą konkurencyjną.
Kiedy ma sens utrzymanie i drobny refactor
Krótko: kiedy aplikacja działa, jest stosunkowo prosta, a jej zmiana w przyszłości jest mało prawdopodobna. Sytuacja typowa: prosty rejestr w Accessie z dwoma tabelami i trzema formularzami, używany przez dwie osoby w księgowości. Przepisywanie tego na .NET to byłaby przesada.
Refactor ma sens, gdy:
- Aplikacja jest mała (kilkanaście ekranów, jedna prosta baza), a proces, który obsługuje, jest stabilny i nie planujesz go zmieniać.
- Masz dostęp do kodu źródłowego i przynajmniej jedną osobę, która rozumie tę technologię.
- Koszt przepisania przekracza 3-4-letni budżet utrzymania.
- Nie ma jeszcze sensownej alternatywy SaaS-owej dla Twojej niszy.
W takim wariancie inwestujesz raz w porządne porządkowanie: kontrola wersji w Gicie, kopia bazy testowej, lista znanych usterek z priorytetami, jedna lub dwie poprawki, które najbardziej dokuczają. Koszt: zwykle 60-150 godzin pracy. Efekt: spokój na kolejne 2-3 lata.
Kiedy ma sens przepisanie od zera
Sytuacja typowa: aplikacja jest rdzeniem operacyjnym firmy i odróżnia Cię od konkurencji — bo robi coś, czego żaden gotowy system na rynku nie robi tak jak Ty. Przykład: niestandardowy konfigurator produkcyjny w branży metalowej, własny system rozliczania premii dla handlowców, narzędzie do planowania tras w logistyce kontraktowej.
Przepisanie ma sens, gdy:
- Aplikacja realnie wspiera proces, który jest Twoją przewagą — nie chcesz tego standaryzować pod cudzy SaaS.
- Stos jest na tyle stary, że dalsze utrzymanie kosztuje rocznie więcej, niż amortyzacja przepisania w 3 lata.
- Brakuje rzeczy, które dziś są standardem (praca z domu, mobile, integracje API z systemem księgowym, eksport do KSeF).
- Stoisz na ryzyku „bus factor 1" — jedna osoba zna ten kod i odejdzie albo zachoruje, a Ty zostaniesz z plikiem .mdb i Postit-em.
U jednego z naszych klientów — 24-osobowej fabryki opakowań spod Konina — od 2013 r. działał system planowania produkcji napisany w Accessie przez byłego pracownika. Aplikacja stała na jednym, fizycznie wyznaczonym komputerze w hali, bo „tylko tam wstawała". Nie dało się z niej korzystać z laptopa kierownika zmiany, planiści musieli chodzić do tego konkretnego stanowiska, a dwa razy w tygodniu aplikacja się wieszała i tracono ostatnie 20-30 minut pracy. Po 6-tygodniowym projekcie (≈ 220 godzin pracy, koszt ok. 65 000 zł) przepisaliśmy ją na .NET 8 z bazą SQL Server i interfejsem w przeglądarce. Po wdrożeniu: dostęp z dowolnego stanowiska w firmie i z domu, integracja z Comarch Optima zamiast ręcznego przepisywania zleceń, czas wystawienia planu produkcji na zmianę spadł z około 35 do 8 minut. W ciągu pierwszych trzech miesięcy firma odzyskała około 18 godzin pracy planistów tygodniowo.
Kiedy ma sens migracja na SaaS
Sytuacja typowa: Twój proces nie różni się bardzo od reszty rynku, a ktoś już zbudował na to gotowy produkt — często lepszy niż to, co zrobiłby Ci niewielki dostawca pod zlecenie. CRM, helpdesk, prosty WMS dla e-commerce, podstawowe zarządzanie projektami. Tu robienie własnego oprogramowania to zwykle dłubanie czegoś, co przeskoczy konkurencja z półki za miesiąc.
Migracja ma sens, gdy:
- Robisz to samo, co robi tysiąc innych firm w branży — rozliczasz delegacje, ewidencjonujesz urlopy, wystawiasz proste oferty serwisowe.
- Gotowe rozwiązanie obsługuje 85% Twojego procesu, a brakujące 15% jesteś gotów dopasować do narzędzia, nie odwrotnie.
- Twoje zespoły są małe (do 30 osób), więc koszt licencyjny SaaS jest istotnie mniejszy niż koszt utrzymania własnego kodu.
- Ważniejszy jest dla Ciebie regularny rozwój funkcji (które dostawca dorzuca co miesiąc) niż całkowita kontrola.
Pamiętaj: migracja do SaaS nie jest „darmowa" tylko dlatego, że nie piszesz kodu. Koszt to projekt migracji danych, mapowanie procesów, szkolenia i — zawsze — kilka rzeczy, które trzeba przemyśleć inaczej, niż były dotąd.
Jak ugryźć projekt, żeby nie zatonąć
Niezależnie od ścieżki, najczęstszy błąd polskich MŚP to robienie z modernizacji „jednego wielkiego projektu na rok". To prosta droga do tego, żeby po pół roku nikt już nie pamiętał, po co zaczęliśmy.
Co działa zamiast tego:
- Zacznij od jednego konkretnego bólu. Nie „przepisujemy całą aplikację", tylko „za 6 tygodni planiści mają wystawiać plan produkcji z domu". Reszta poczeka.
- Podziel na fragmenty 4-6 tygodniowe, w każdym oddawaj jedną używalną rzecz. Najgorszy projekt to taki, który po 4 miesiącach nadal niczego nie produkuje.
- Stara i nowa aplikacja muszą umieć chodzić obok siebie przez kilka tygodni. Wielki dzień „przepinki" w piątek wieczorem to model, który prawie nigdy się nie udaje w MŚP — za mało rąk do gaszenia pożarów w poniedziałek.
- Dane historyczne migruj świadomie. Nie wszystkie. Wybierz, czego naprawdę potrzebujesz operacyjnie (zwykle 2-3 lata wstecz), reszta może zostać w starym systemie w trybie tylko do odczytu.
Co dalej
Jeśli masz w firmie aplikację, której nazwy nie wymawiasz publicznie ze strachu — to dobry znak, że trzeba się jej w końcu przyjrzeć. Decyzja „utrzymać, przepisać czy migrować" nie zapada na slajdach. Zapada po godzinnej rozmowie, w której ktoś z zewnątrz zobaczy proces od kuchni i powie wprost, gdzie kończy się rozsądek, a gdzie zaczyna sentymentalizm wobec dziesięcioletniego kodu.
Robimy takie rozmowy regularnie dla polskich MŚP. Pierwsza jest bezpłatna i trwa pół godziny.
Stara aplikacja, której nie wolno tknąć, to nie przewaga konkurencyjna. To dług, którego procent rośnie z każdym kwartałem.