Jeżeli system nadal obsługuje ważne procesy i przechowuje potrzebne dane, pełne przepisanie nie powinno być pierwszym odruchem. Najpierw warto ustalić, gdzie naprawdę powstaje problem: w całej architekturze, jednym module, modelu danych, integracji czy sposobie wdrażania zmian.
Budowa od zera ma sens wtedy, gdy istotnych części nie da się bezpiecznie zachować albo ograniczenia starego rozwiązania uniemożliwiają osiągnięcie celu biznesowego. W pozostałych przypadkach lepszym początkiem bywa stabilizacja systemu, wymiana najbardziej kłopotliwego modułu lub kontrolowana migracja etapami.
Ostateczna decyzja wymaga sprawdzenia konkretnego kodu, danych i procesu pracy. Sam wiek aplikacji ani nazwa technologii nie wystarczają.
„Przepiszmy wszystko” brzmi prościej, niż wygląda
Stary system potrafi irytować. Wdrożenia trwają długo, jedna poprawka narusza inną funkcję, a dokumentacja kończy się kilka lat wcześniej. Nowa aplikacja obiecuje porządek, ale razem z bałaganem łatwo usunąć reguły biznesowe, których nikt już nie opisuje, choć codziennie korzystają z nich pracownicy i klienci.
Trzeba też odtworzyć dane, uprawnienia, raporty, integracje i wyjątki obsługiwane dotąd ręcznie. Jeśli te elementy nie zostaną rozpoznane przed rozpoczęciem prac, nowy system może być czystszy technicznie, a jednocześnie gorzej pasować do firmy.
Nowy kod nie ma wartości tylko dlatego, że jest nowy. Powinien rozwiązać konkretny problem: ograniczyć ryzyko, ułatwić zmianę, poprawić stabilność albo uprościć pracę użytkowników.
Cztery możliwe kierunki
| Kierunek | Kiedy warto go rozważyć | Co trzeba zabezpieczyć |
|---|---|---|
| Stabilizacja i dalszy rozwój | Główna część systemu działa, a awarie i koszt zmian skupiają się w kilku miejscach. | Krytyczne procesy, kopie danych, testy najważniejszych ścieżek, wdrożenia i widoczność błędów. |
| Etapowa wymiana modułu | Jeden fragment blokuje rozwój, ale pozostała część aplikacji nadal ma wartość. | Granice danych i integracji oraz okres, w którym stary i nowy moduł działają obok siebie. |
| Kontrolowana migracja | Ograniczenia starej platformy lub modelu danych są fundamentalne, ale przejście można podzielić na etapy. | Porównanie danych, kolejność przełączania procesów, ciągłość działania i możliwość powrotu. |
| Budowa od zera | Wartościowych części nie da się zachować albo ich ograniczenia uniemożliwiają osiągnięcie celu. | Pełny zakres funkcji, ukryte reguły z wielu lat, migrację danych, pracę równoległą i plan wycofania. |
Ta tabela pomaga uporządkować rozmowę, ale nie zastępuje audytu. Ten sam objaw, na przykład wolne wdrażanie zmian, może wynikać z architektury aplikacji, braku testów, źle przygotowanego procesu publikacji albo kilku problemów jednocześnie.
Cztery pytania przed wyborem
- Czy system poprawnie obsługuje kluczowe procesy i dane?
- Które miejsca powodują najwięcej awarii, ręcznej pracy albo kosztownych poprawek?
- Czy używana technologia nadal otrzymuje poprawki bezpieczeństwa i może działać w utrzymywanym środowisku?
- Czy da się oddzielić moduły i wymieniać je bez zatrzymania całej firmy?
Jeśli problem dotyczy jednego obszaru, nie ma powodu automatycznie odtwarzać całej aplikacji. Jeżeli jednak systemu nie da się uruchomić w powtarzalnym środowisku, jego kluczowe zależności nie są już wspierane, a dane i moduły są ze sobą nierozerwalnie związane, zakres nowej budowy może okazać się rozsądniejszy.
Jeżeli decyzję przyspieszyła informacja o krytycznej luce PHP, najpierw oddziel pilną aktualizację środowiska od dalszej modernizacji. Opisuje to poradnik „Krytyczne luki w PHP z października 2026: co zrobić ze starą aplikacją?”.
Co sprawdzić przed podjęciem decyzji
Ocena powinna objąć nie tylko kod. Potrzebne są odpowiedzi dotyczące całego sposobu działania aplikacji:
- które procesy nie mogą zostać przerwane;
- gdzie znajdują się dane i jak wykonuje się ich kopie;
- jakie systemy zewnętrzne wymieniają informacje z aplikacją;
- które role i uprawnienia są rzeczywiście używane;
- jak dziś wygląda testowanie, wdrożenie, monitoring i powrót do poprzedniej wersji;
- które obejścia stały się częścią codziennej pracy;
- jaki mierzalny rezultat ma dać pierwszy etap.
Bez tego łatwo porównać cenę naprawy kilku widocznych problemów z ceną niepełnej wersji nowego systemu. To nie jest uczciwe porównanie. Nowa realizacja musi uwzględniać także migrację, integracje, zachowanie danych, okres przejściowy i odbiór najważniejszych procesów.
Kiedy modernizacja jest rozsądniejsza
Etapowa modernizacja ma mocne podstawy, gdy system nadal działa, zawiera wartościowe dane, ma aktywnych użytkowników i pozwala wyznaczyć granice między modułami. W takim przypadku można najpierw ustabilizować krytyczne miejsca, dodać ochronę najważniejszych zachowań i poprawić obserwację błędów.
Następnie wymienia się elementy, które najbardziej blokują firmę. Każdy etap powinien mieć własny zakres, kryterium odbioru i sposób wycofania. Dzięki temu decyzja o kolejnym kroku opiera się na tym, czego dowiedzieliśmy się o rzeczywistym systemie, a nie na założeniach z początku projektu.
Kiedy budowa od zera ma sens
Nowy system warto poważnie rozważyć, gdy obecna platforma nie jest już wspierana, model danych uniemożliwia potrzebny rozwój, wymagania firmy zmieniły się zasadniczo albo bezpieczne rozdzielenie aplikacji kosztowałoby więcej niż kontrolowane zastąpienie.
Nie oznacza to jednak jednego wielkiego przełączenia. Nawet przy nowej budowie można najpierw przenieść jeden proces, porównać wyniki i dopiero później rozszerzać zakres. Migracja danych, okres równoległego działania i droga powrotu są częścią projektu, a nie zadaniami do dopisania tuż przed publikacją.
Przykład z portfolio: różne etapy rozwoju Tempus
Portfolio Domin Software dokumentuje kilka zakresów prac wykonanych dla sklepu Tempus. Obejmowały one czyszczenie istniejącego kodu i rozwój dedykowanych modułów, aktualizację silnika i warstwy graficznej, a także migrację z sStore do PrestaShop wraz z przeniesieniem produktów i klientów.
Ten przykład nie oznacza, że każda aplikacja powinna przejść tę samą drogę. Pokazuje natomiast, że „rozwijać czy przepisać” nie zawsze jest jedną decyzją na cały okres życia systemu. W jednym etapie wartość może mieć naprawa i dalszy rozwój, a w innym potrzebna jest kontrolowana migracja do nowej podstawy.
Opisane zakresy można sprawdzić w portfolio Domin Software. Nie przedstawiamy ich jako dowodu konkretnego wyniku sprzedażowego ani jako gotowej recepty dla innej firmy.
OBIBOOK: naprawa poprzedzająca przebudowę
W projekcie OBIBOOK najpierw naprawiliśmy import CSV i działanie na urządzeniach mobilnych. Pełna przebudowa katalogu książek była późniejszym, odrębnym etapem. Przykład pokazuje, dlaczego naprawa potrzebna dziś i decyzja o dalszym rozwoju nie muszą mieć tego samego zakresu.
Most zamiast jednego skoku
Przy większej zmianie stary i nowy system mogą przez pewien czas działać obok siebie. Wybrane procesy kieruje się do nowego modułu, dane przenosi partiami, a wyniki porównuje przed rozszerzeniem zakresu. Użytkownicy mogą przechodzić grupami zamiast jednego dnia zmieniać całe środowisko pracy.
Takie podejście jest zgodne z ideą Strangler Fig opisaną przez Martina Fowlera. Nie gwarantuje prostego projektu, ale pomaga ograniczyć ryzyko jednorazowego odtworzenia wszystkiego i daje możliwość sprawdzania kolejnych etapów.
Gdzie może pomóc DominPress
Jeżeli zmiana dotyczy stron publicznych, treści, formularzy albo nowych modułów internetowych, DominPress może zostać dołączony jako nowa warstwa bez natychmiastowej wymiany całego zaplecza firmy. Nie jest jednak automatyczną odpowiedzią na każdy stary system. Wybór rozwiązania powinien wynikać z procesów, danych, integracji i planu dalszego utrzymania.
Co opisać w pierwszej wiadomości
Do wstępnej rozmowy przygotuj:
- krótki opis systemu i jego użytkowników;
- najważniejszy proces, którego nie można zatrzymać;
- konkretny problem, który dziś blokuje rozwój lub powoduje błędy;
- używaną technologię i wersję, jeśli je znasz;
- listę najważniejszych integracji;
- oczekiwany rezultat pierwszego etapu;
- informację, czy istnieją aktualne kopie, środowisko testowe i dokumentacja.
Nie wysyłaj haseł, kluczy, kopii produkcyjnej bazy ani rzeczywistych danych klientów. Na początku wystarczy opis problemu i informacje, które pozwolą ustalić, czy potrzebna jest krótka konsultacja, audyt techniczny czy od razu możliwe jest wydzielenie pierwszego etapu prac.
Jeśli modernizacja wiąże się ze zmianą wykonawcy, zobacz również jak rozpocząć przejęcie aplikacji przez nowego programistę. Opisujemy tam informacje potrzebne przed przekazaniem kodu i kont.
Ustalmy właściwy kierunek dla istniejącego systemu
Nie zakładamy z góry, że aplikację trzeba przepisać. Najpierw sprawdzamy, co nadal ma wartość, co rzeczywiście blokuje firmę i jak ograniczyć ryzyko zmiany. Zakres takiej pracy opisuje usługa modernizacji systemów.
Jeżeli chcesz zacząć od konkretnego przypadku, opisz problem w istniejącym systemie.