Wiele firm od lat lub dekad eksploatuje stabilne Delphi-aplikacje odwzorowujące rdzeń procesów: obsługa zleceń, produkcja, serwis, logistyka, rozliczenia, zarządzanie urządzeniami, workflow dokumentów. W tych systemach nie ma jedynie kodu, lecz trwała koordynacja reguł domenowych, modelu danych, prowadzenia użytkownika i doświadczenia eksploatacyjnego. To właśnie czyni modernizację wymagającą: rzeczywista wartość rzadko leży w interfejsie, lecz w wypracowanej logice fachowej.
Jeśli modernizację rozumie się jako „zbudować od nowa”, utrata funkcjonalności jest wpisana w scenariusz. Nie dlatego, że nowe technologie są z natury złe, lecz dlatego, że ukryta wiedza z systemu legacy — przypadki szczególne, dane historyczne, wyjątki procesowe, detale regulacyjne — przy migracji często nie da się w pełni odtworzyć. Efektem są kosztowne regresje, zmiany czasów procesów, problemy z akceptacją i projekt trwający dłużej niż zakładano.
Delphi da się jednak dobrze zmodernizować bez utraty logiki fachowej. Kluczem jest kontrolowane, etapowe podejście: najpierw uzyskać przejrzystość (architektura, dane, ryzyka), potem rozdzielić obowiązki (UI, dostęp do danych, logika domenowa), następnie modernizować (sterowniki bazy danych, Unicode/64-bit, API, serwisy, multiplatformowość) — przy jednoczesnym zabezpieczeniu bieżącego działania. Ten artykuł opisuje praktyczne wzorce modernizacji, typowe pułapki oraz podejście działające w środowiskach B2B o wysokiej krytyczności procesów.
Dlaczego modernizacja Delphi rzadko jest „projektem technicznym”
W praktyce modernizacje nie zawodzą z powodu brakującego flagi kompilatora, lecz z powodu błędnych założeń dotyczących zachowania systemu. Delphi-aplikacje, rozbudowywane przez lata, często zawierają:
- Reguły fachowe w zdarzeniach GUI (OnClick, OnExit, OnValidate), często rozproszone po wielu formularzach
- Zapytania SQL „blisko powierzchni” i przez lata zoptymalizowane pod jedną konkretną bazę
- Sposoby obchodzenia problemów związanych z danymi historycznymi, przypadki specjalne, warianty klientów lub logikę wielodostępności
- Procesy wsadowe działające w praktyce o określonych porach i posiadające zależności
- Integracje z ERP, DMS, CRM lub maszynami, które są słabo udokumentowane
- Cicha wiedza w postaci rutyn operacyjnych: „Jeśli błąd X, to najpierw sprawdź Y”
Kto zaczyna od przebudowy typu Big Bang, musi tę wiedzę na nowo wytworzyć — łącznie z błędami, których stary system już od dawna nie popełnia. Lepsze podejście traktuje logikę fachową jako aktywo: najpierw izolować, potem zabezpieczać, następnie modernizować.
Modernizacja bez utraty logiki: cel i zasady przewodnie
Trwały obraz docelowy dla systemów B2B to nie „wszystko na nowo”, lecz architektura umożliwiająca zmiany. Typowe cechy:
- Oddzielone odpowiedzialności (UI, domena/logika fachowa, dostęp do danych, integracje)
- Testowalność i mierzalność (testy regresji, logowanie, monitoring, odtwarzalne buildy)
- Stopniowa wymienialność (modernizacja UI bez jednoczesnej przebudowy modelu danych; migracja DB bez przepisywania UI)
- API-owość (REST-serwer lub warstwa serwisów do podłączania portali, mobilnych rozwiązań, integracji)
- Operacyjność (Windows-i Linux-usługi, jasne deploye, strategia rollback)
W Delphi jest to szczególnie osiągalne, ponieważ można dalej wykorzystywać istniejące Units i klasy domenowe, modernizując otoczenie: dostęp do danych z BDE na BDE-Ablösung mit nativer Anbindung, nowe REST-punkty końcowe, nowe moduły UI, nowe mechanizmy wdrożeniowe.
Inwentaryzacja: co naprawdę musi pozostać?
Zanim „dotknie się” kodu, opłaca się przeprowadzić ustrukturyzowaną inwentaryzację. Celem nie jest pełna dokumentacja, lecz solidna podstawa do decyzji.
1) Mapa logiki fachowej zamiast maratonu czytania kodu
Praktycznie sprawdza się mapa logiki fachowej z następującymi perspektywami:
- Use-Case’y: Które procesy są krytyczne biznesowo? (np. założenie zlecenia, faktura, storno, zwrot, serwis maszyn, umowa serwisowa)
- Reguły: Jakie walidacje, obliczenia, automaty stanów istnieją?
- Warianty: Konfiguracje klientów, zasady specyficzne dla kraju, wielodostępność
- Interfejsy: Import/eksport, ERP/DMS/CRM, urządzenia/protokóły
- Batch/Jobs: nocne uruchomienia, raporty, synchronizacje danych
Z tej mapy wynikają zpriorytetyzowane pakiety modernizacyjne: co musi pozostać stabilne, co może się zmienić, co może poczekać.
2) Uczyń widocznymi długi technologiczne
Typowe długi technologiczne w starszych systemach Delphi:
- Borland BDE/zależności Paradox
- ANSI-stringi/brak migracji do Unicode
- Tylko 32-bit, przestarzałe komponenty stron trzecich
- Monolityczna logika formularzy, globalne zmienne, Units generujące efekty uboczne
- Niejednoznaczne granice transakcji i „SQL wszędzie”
Sztuka polega na tym, by tych punktów nie „czyścić” dogmatycznie, lecz ustawić w kolejności minimalizującej ryzyko i maksymalizującej wartość biznesową.
Rozdzielenie architektury: dźwignia przeciw utracie logiki
Najczęstszą przyczyną utraty logiki jest mieszanie UI, dostępu do danych i reguł fachowych. Modernizacja zaczyna się zatem od rozdzielenia — nie od „nowego frameworku UI”.
Layer-3 architektura jako pragmatyczny stan docelowy
Dla wielu aplikacji Delphi sprawdza się bardzo dobrze Layer-3 Architektur:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, walidacja jedynie blisko UI (format, pola obowiązkowe)
- Business Layer: modele domenowe, serwisy, reguły, logika stanów, obliczenia
- Data/Integration Layer: repozytoria, części SQL/ORM, adaptery interfejsów, klienci REST, messaging
Korzyść: logika fachowa staje się testowalna i wielokrotnego użytku. Później portal klienta, REST-serwer lub Linux-usługa mogą korzystać z tych samych serwisów domenowych. W ten sposób modernizujecie „powłokę” bez wynajdywania logiki na nowo.
Strangulation Pattern: stopniowe „objęcie” starego systemu
Sprawdzony wzorzec migracji to Strangulation Pattern: nowe funkcje powstają już w nowej strukturze (np. serwis domenowy + repozytorium), podczas gdy istniejące formularze są sukcesywnie przebudowywane. Stara część pozostaje działająca, lecz krok po kroku zastępowana nową.
Ważne jest aktywne odwrócenie zależności: nie „formularz wywołuje SQL”, lecz „formularz wywołuje serwis”, a serwis decyduje. Ta niewielka zmiana często przynosi największe korzyści.
Modernizacja dostępu do danych: BDE-Ablösung i planowanie FireDAC
Centralnym krokiem modernizacyjnym jest BDE-Ablösung. Firmy często nie doceniają, że nie chodzi tu tylko o sterowniki, lecz o semantykę SQL, transakcje, blokowania, typy danych i zachowanie w błędach. Nowoczesne stacki Delphi typowo opierają się na BDE-Ablosung mit nativer Anbindung z natywnymi sterownikami (np. dla MariaDB/MySQL, PostgreSQL, SQL Server).
Co naprawdę trzeba zdecydować przy przełączeniu
- Cele bazy danych: Czy pozostawać przy istniejącej bazie? Czy sensowna jest przebudowa bazy (np. z Paradox/Firebird do MariaDB lub PostgreSQL)?
- Model transakcyjny: Gdzie zaczynają/kończą się transakcje? Które use-case’y muszą być atomowe?
- Współbieżność/blokowania: Optymistyczna kontra pesymistyczna, obsługa deadlocków, strategie retry
- Dialekt SQL: funkcje daty, zachowanie stringów, obsługa NULL, czułość na wielkość liter
- Wydajność: indeksy, plany zapytań, stronicowanie, wsadowe inserty
Logika fachowa jest ściśle powiązana z zachowaniem danych. Kto migruje „przy okazji”, ryzykuje subtelne różnice: zaokrąglenia, sortowania, granice dat, konflikty blokad. Dlatego warstwa danych powinna znaleźć się wcześnie w planie modernizacji, łącznie ze ścieżką migracji i strategią testów danych.
Pragmatyczne kroki do migracji FireDAC
Zamiast przebudowy całej aplikacji naraz, sprawdza się następująca kolejność:
- Wprowadzenie warstwy dostępu do danych (Repository/DAO) jako fasady
- Przełączanie pojedynczych use-case’ów na FireDAC (np. „odczyty” najpierw, „zapisy” później)
- Ujednolicenie obsługi połączeń, obsługi błędów, logowania
- Stopniowe wyłączanie komponentów BDE tam, gdzie fasada jest stabilna
Dzięki temu aplikacja pozostaje w każdym momencie dostarczalna, a unikacie długiego okresu „połowicznej gotowości”.
Unicode, 64-bit i zależności: szczegółowe pułapki modernizacji
Wiele modernizacji nie pada z powodu koncepcji, lecz z powodu niedocenionych detali. Trzy z nich są w projektach Delphi szczególnie częste.
Migracja do Unicode: nie tylko typy string, lecz przepływy danych
W bardzo starych wersjach Delphi systemy pochodzą ze świata ANSI. Migracja do Unicode obejmuje wtedy:
- Typy stringów i konwersje (WideString/AnsiString/UnicodeString)
- Obsługę plików i ścieżek (Windows-API, ścieżki sieciowe)
- Import/eksport (CSV, pola stałej długości, EDI, interfesje legacy)
- Sortowanie/kollacja w bazie danych
Kluczowe jest zidentyfikowanie krytycznych przepływów danych (np. treści faktur, nazwy artykułów, międzynarodowe adresy) i przygotowanie testów regresyjnych. Unicode to mniej „przebudowa”, a bardziej proces jakościowy obejmujący całość.
Przejście na 64-bit: pamięć to nie jedyny temat
Przejście na 64-bit często sprowadza się do „rozmiaru wskaźników”. W praktyce częściej chodzi o:
- Przestarzałe komponenty stron trzecich bez wsparcia 64-bit
- Zależności COM/ActiveX
- DLL i sterowniki (kod kreskowy, urządzenia, kryptografia, podpis)
- Instalator/deployment i ścieżki rejestru (WOW64)
Sensowna strategia to najpierw zinwentaryzować wszystkie zewnętrzne zależności i zdefiniować alternatywy. Wówczas krok 64-bit staje się planowalny — i nie jest niespodzianką tuż przed wydaniem.
Windows 11 ARM64: sprawdź wcześnie, zamiast płacić później
Z Windows 11 ARM64 pojawia się nowa klasa docelowych systemów. Nawet jeśli nie każda firma od razu potrzebuje natywnych buildów ARM64, warto wcześnie zbadać:
- Czy są natywne zależności (DLL, sterowniki), które na ARM64 nie działają?
- Czy aplikacja opiera się na emulacji i czy to jest akceptowalne?
- Jak wygląda instalator, aktualizacja/naprawa?
W projektach modernizacyjnych to typowy „późny“ temat generujący koszty. Lepiej: uwzględnić go wcześniej w roadmapzie platformowej i technicznie wyjaśnić.
REST-serwer i usługi: udostępnienie logiki fachowej dla portali i integracji
Wiele firm modernizuje Delphi nie dlatego, że aplikacja desktopowa wygląda staro, lecz dlatego, że pojawiają się nowe potrzeby: portal klienta, dostępy partnerów, procesy mobilne, integracja z ERP/DMS/CRM, pipeline’y raportowe. Do tego potrzeba jasnych interfejsów. REST-serwer jest często najpraktyczniejszym pomostem.
API najpierw? Tylko jeśli prawa i logika domenowa też idą za nim
API jest użyteczne tylko wtedy, gdy egzekwuje tę samą logikę fachową co klient. W przeciwnym razie powstają dwa zestawy reguł: jeden w desktopie, drugi w backendzie. Konsekwencją są niespójności i luki bezpieczeństwa.
Dlatego REST-warstwa powinna w miarę możliwości bezpośrednio opierać się na serwisach domenowych. Typowe komponenty:
- Uwierzytelnianie/autoryzacja (role, wielodostęp, prawa)
- DTO/serializacja z jasnymi zasadami wersjonowania
- Koncept transakcji i błędów (kody HTTP, Problem-Details, logowanie)
- Idempotencja i współbieżność (dla retry, przetwarzania kolejek)
Dzięki temu REST-serwer staje się stabilnym punktem integracji — a nie „drugim klientem”.
Modernizacja Linux-usług i Windows usług
Procesy wsadowe i integracje w wielu firmach działają jako Windows Services, zadania w Task Scheduler lub nawet „ukryte” instancje desktopowe. Przy modernizacji warto je skonsolidować:
- Oddzielenie UI od logiki w tle
- Konfigurowalne harmonogramy i jasne parametry operacyjne
- Porządne logowanie (logi strukturalne, korelacja per job/request)
- Opcja uruchamiania serwisów jako Linux (np. dla wdrożeń konteneryzowanych)
Zaletą nie jest tylko „nowoczesność”, lecz operacyjność: powtarzalny tryb działania, mniej ręcznej interwencji, łatwiejsze diagnozowanie błędów.
Modernizacja UI bez ruszania rdzenia: VCL, FMX i podejścia hybrydowe
Wiele planów modernizacyjnych zaczyna się od UI. To ma sens — pod warunkiem że wiadomo, co ma to przynieść. Jeśli logika fachowa jest rozdzielona, odnowienie UI można przeprowadzić przy niższym ryzyku.
Stopniowa modernizacja aplikacji VCL
VCL w wielu scenariuszach B2B pozostaje solidnym wyborem, szczególnie tam, gdzie środowisko jest silnie Windows-centryczne i wymagana jest wysoka produktywność desktopowa. Modernizacja może oznaczać:
- Redukcję logiki UI (Presenter/ViewModel), przeniesienie reguł fachowych do serwisów
- Porządkowanie biblioteki komponentów, konsolidację własnych kontrolek
- Poprawę responsywności (Async, zadania w tle, postęp, anulowanie)
- Dostępność, spójna walidacja, lepsze komunikaty o błędach
To przynosi wymierne korzyści bez konieczności przepisywania całego interfejsu.
Delphi Multiplatform: kiedy FMX ma sens
Jeśli istnieją prawdziwe wymagania multiplatformowe (Windows, macOS, ew. Linux w kontekście usług), FMX może być opcją. Kluczowe są oczekiwania: multiplatformowość oznacza dodatkową pracę testową i integracyjną (czcionki, druk, dialogi OS, system plików, pakowanie/deployment). Koszty są kalkulowalne, jeśli logika fachowa jest już umieszczona w czystej warstwie.
Częstym, pragmatycznym podejściem jest hybryda: VCL pozostaje dla klienta Windows, natomiast nowe frontend’y (portal, aplikacja mobilna) łączą się przez REST-serwer. Multiplatformowość powstaje w granicach systemu, a nie poprzez jedyny stack UI.
Testowanie i regresja: jak „przypiąć” logikę fachową
„Utrata logiki fachowej” oznacza w praktyce: system w przypadkach brzegowych daje inne wyniki. Z reguły nie jest to od razu widoczne, ale kosztowne. Dlatego testowalność nie jest luksusem, lecz narzędziem modernizacyjnym.
Złote use-case’y i dane referencyjne
Sprawdza się zestaw „złotych” use-case’ów: rzeczywiste, krytyczne przebiegi z określonym stanem danych i oczekiwanymi wynikami (np. łańcuch dokumentów od oferty do nota-korekty albo zlecenie serwisowe z częściami zamiennymi i ewidencją czasu). Służą one jako testy regresji lub przynajmniej powtarzalne skrypty testowe.
Ważne: nie tylko ścieżki sukcesu, lecz także typowe ścieżki błędów (konflikty blokad, brak uprawnień, niekompletne dane główne, zduplikowany plik importu).
Automatyzacja tam, gdzie daje największy efekt
Nie każdy projekt legacy potrzebuje od razu 80% pokrycia testami jednostkowymi. Wysoki ROI osiąga się często przy:
- Serwisach domenowych (obliczenia, reguły, zmiany stanów)
- Dostępie do danych z jasno określonymi kontraktami (mapowanie, SQL, transakcje)
- Testach API (uwierzytelnianie, uprawnienia, wersjonowanie)
Celem jest stabilność przy zmianach, nie akademickie metryki.
Model działania w praktyce: plan modernizacji etapami
Z perspektywy B2B modernizacja musi pozostać dostarczalna. Typowy plan, zorientowany na ryzyko:
Etap 1: Analiza, architektura docelowa, szybkie usprawnienia (2–6 tygodni)
- Mapa systemu (moduły, bazy danych, interfejsy, zadania, zależności)
- Macierz ryzyka (BDE, dostawcy zewnętrzni, 32/64-bit, Unicode, deployment)
- Definicja architektury docelowej (Layer-3, warstwa serwisów, strategia API)
- Szybkie usprawnienia: stabilizacja procesu budowania, poprawa logowania, porządek w kontroli wersji
Etap 2: Rozdzielenie logiki fachowej (ciągły, inkrementalny)
- Zidentyfikowanie serwisów domenowych i wydzielenie ich z formularzy
- Wprowadzenie fasad repozytoriów
- Pierwsze testy regresji dla krytycznych use-case’ów
Etap 3: Modernizacja dostępu do danych/warstwy DB
- Wdrożenie FireDAC, ustanowienie koncepcji połączeń i transakcji
- Modułowa BDE-Ablösung (lub migracja bazy z równoległym trybem pracy)
- Testy wydajności i zachowania blokad pod obciążeniem
Etap 4: Doposażenie REST-serwera i integracji
- API z uwierzytelnianiem, uprawnieniami, wersjonowaniem
- Podłączanie portali/integracji bez dublowania logiki
- Konsolidacja serwisów dla batch i procesów w tle
Etap 5: Decyzje platformowe i UI (64-bit, ARM64, multiplatformowość)
- Build 64-bit, zastąpienie zależności
- Sprawdzenie/planowanie zgodności ARM64
- Modernizacja UI: odświeżenie VCL lub FMX/hybrydowo, w oparciu o wartość biznesową
Kolejność jest świadomie tak dobrana, aby najpierw uzyskać przejrzystość, potem ustabilizować rdzeń, a dopiero później wprowadzać „widoczne” zmiany na szeroką skalę. W ten sposób zmniejsza się ryzyko, a eksploatacja pozostaje planowalna.
Typowe antywzorce: co niepotrzebnie winduje koszty modernizacji
Pewne wzorce pojawiają się w audytach i projektach ratunkowych regularnie:
- „Budujemy na nowo i przenosimy tylko funkcje”: niemal zawsze prowadzi do utraty logiki, ponieważ brak jest obsługi przypadków szczególnych.
- API jako równoległy świat: reguły biznesowe pozostają w kliencie, a backend wymyśla je na nowo.
- Zmiana bazy bez testów semantycznych: te same dane, ale inne zachowanie (NULL, sortowanie, logika dat).
- Zarządzanie zależnościami za późno: 64-bit/ARM64 upada przy drobnej DLL tuż przed Go-Live.
- „Refactoring najpierw” bez obrazu docelowego: wiele zmian, niewiele mierzalnej wartości, wysoka regresja.
Przeciwdziałanie jest zawsze takie samo: najpierw jasno określić architekturę docelową i ryzyka, potem przebudowywać inkrementalnie, testować logikę fachową i uczynić ją widoczną.
Wniosek: modernizować to zachować — i celowo rozszerzać
Modernizacja Delphi bez utraty logiki fachowej nie jest sprzecznością, lecz dyscypliną. Firmy nie muszą wybierać między „wszystko zachować” a „wszystko wymienić”. Dzięki czystemu rozdziałowi architektury (np. Layer-3), kontrolowanej BDE-Ablösung w kierunku FireDAC, strategii API opartej o REST-serwer oraz jasnemu planowi dla Unicode, 64-bit i nowych platform jak Windows 11 ARM64 można stopniowo przeprowadzić wyewoluowany system do struktury gotowej na przyszłość.
Kluczowe jest traktowanie logiki fachowej jako kluczowego aktywa: izolować, uczynić testowalną, potem modernizować. W ten sposób powstaje architektura wspierająca portale, serwisy i wymagania multiplatformowe bez narażania bieżącej eksploatacji.
Jeśli planujecie Delphi Modernisierung i chcecie podczas tego procesu spójnie połączyć logikę fachową, dostęp do danych i operacje eksploatacyjne, porozmawiajcie z nami o realistycznej ścieżce migracji: https://net-base-software-gmbh.de/kontakt/