Zastąpienie aplikacji ScriptCase – krok po kroku zamiast budowy od zera

W skrócie: zastąpienie aplikacji ScriptCase nie oznacza budowania wszystkiego od nowa naraz. Sprawdza się stopniowe przejście: najpierw dokumentacja bazy danych i procesów, potem przenoszenie kolejnych obszarów do własnego kodu PHP, podczas gdy reszta starej aplikacji dalej działa. Baza danych zwykle zostaje. To wyraźnie zmniejsza ryzyko i koszty.

Wiele firm przez lata dobrze pracowało ze swoją aplikacją ScriptCase. W pewnym momencie pojawiają się jednak powody przeciw kolejnej aktualizacji: licencja nie ma być przedłużana, dawnego programisty już nie ma, projekt istnieje tylko jako wygenerowany kod albo aplikacja ma robić rzeczy, które w generatorze idą bardzo opornie.

Aktualizacja czy zastąpienie?

Aktualizacja jest zwykle tańsza, gdy projekt ScriptCase nadal istnieje, jest licencja, a aplikacja w zasadzie robi to, co powinna. Jak to zrobić, opisuję w artykule Aplikacja ScriptCase na PHP 8.

Zastąpienie opłaca się raczej wtedy, gdy:

• istnieje tylko wygenerowany kod, bez pliku projektu,
• w wygenerowanym kodzie zmieniono ręcznie tak dużo, że ponowne generowanie wszystko by nadpisało,
• koszty licencji nie odpowiadają korzyściom,
• aplikacja ma działać na telefonie, szybciej albo współpracować z innymi systemami,
• nikt w firmie nie umie już albo nie chce pracować w ScriptCase.

Dlaczego nie zbudować po prostu wszystkiego od nowa?

Wielka przebudowa brzmi kusząco, ale to najbardziej ryzykowna droga. W starych aplikacjach biznesowych jest dużo wiedzy, której nikt nie spisał: wyjątki przy rabatach, pola obowiązkowe dla wybranych klientów, raport potrzebny księgowości raz na kwartał. Przy budowie od zera część z tego z doświadczenia ginie. Wychodzi to na jaw dopiero, gdy stara aplikacja jest już wyłączona.

Jak przebiega stopniowe zastąpienie

1. Inwentaryzacja

Jakie aplikacje istnieją, kto z nich korzysta i jak często? W projektach ScriptCase to często dziesiątki formularzy, list i raportów. Z doświadczenia spora część z nich prawie nie jest używana i nie trzeba jej przenosić.

2. Dokumentacja bazy danych

Baza danych to najcenniejsza część aplikacji. Zwykle zostaje i jest poprawiana tylko tam, gdzie trzeba, np. przy brakujących indeksach albo zdublowanych danych. Dzięki temu stara i nowa aplikacja mogą przez jakiś czas działać równolegle na tych samych danych.

3. Wydzielenie logiki biznesowej

Własny kod w zdarzeniach i bibliotekach zawiera reguły firmy. Trzeba go przeczytać, udokumentować i przenieść do czystego, przetestowanego kodu PHP.

4. Przełączanie obszar po obszarze

Zaczyna się od obszaru, który jest wyraźnie wydzielony i odczuwalnie pomaga w codziennej pracy, np. przyjmowania zamówień. Gdy działa stabilnie, przychodzi kolej na następny. Użytkownicy przechodzą stopniowo, a nie jednego dnia.

5. Wyłączenie starej aplikacji

Dopiero gdy wszystkie używane funkcje są przeniesione, a raporty się zgadzają, aplikacja ScriptCase zostaje wyłączona. Kopia do odczytu zostaje jeszcze przez jakiś czas jako zabezpieczenie.

Czym zastąpić?

Ważniejsze od pytania o framework jest pytanie, kto będzie utrzymywał system za pięć lat. Zamiana jednego narzędzia low-code na inne często tylko przesuwa problem. Dobrze zorganizowany, udokumentowany kod PHP bez generatora może przejąć każdy doświadczony programista PHP. Pilnuję tego przy każdym takim projekcie, a Państwo dostają pełny kod źródłowy.

Ile to kosztuje

Zależy to głównie od tego, ile aplikacji jest naprawdę potrzebnych i ile logiki biznesowej siedzi we własnym kodzie. Dlatego zaczynam od inwentaryzacji, a potem podaję stałą cenę za każdy obszar albo rozliczam według stawki dziennej (650 € netto).

Profesjonalna pomoc

Znam ScriptCase od środka i piszę zastępstwo we własnym PHP, krok po kroku i bez przestoju w pracy firmy. Więcej w usługach migracja ScriptCase i modernizacja starego systemu.