Decyzja o wymianie systemu często pojawia się wtedy, gdy każda zmiana trwa długo, awarie wracają, a wiedza o rozwiązaniu pozostaje w głowach kilku osób. Nie oznacza to jednak automatycznie, że całość trzeba napisać od nowa. Najpierw należy rozdzielić problemy produktu, architektury, danych i sposobu dostarczania zmian.
Modernizacja ma sens, gdy rdzeń nadal tworzy wartość
Jeżeli system obsługuje właściwy proces, zawiera ważne reguły biznesowe i można wydzielać jego najbardziej problematyczne elementy, stopniowa modernizacja zwykle ogranicza ryzyko. Można poprawiać testy, interfejsy, bezpieczeństwo i architekturę, jednocześnie utrzymując ciągłość działania.
Nowe rozwiązanie jest uzasadnione, gdy zmienił się problem
Budowa od nowa staje się rozsądna, gdy obecny system utrwala nieaktualny model działania, nie pozwala spełnić wymagań bezpieczeństwa albo koszt każdej kolejnej zmiany rośnie mimo lokalnych napraw. Nadal nie powinien to być jeden duży skok. Potrzebny jest plan migracji danych, funkcji i użytkowników oraz moment, w którym stare rozwiązanie można bezpiecznie wyłączyć.
Dobra decyzja kończy się wskazaniem pierwszego zakresu, a nie tylko wyborem „stare albo nowe”. Może nim być wydzielenie jednego procesu, zabezpieczenie najbardziej ryzykownego obszaru lub prototyp nowej części rozwiązania z wykorzystaniem rzeczywistych danych.