Molte aziende gestiscono da anni o decenni applicazioni stabili Delphi che modellano il nucleo dei loro processi: gestione ordini, produzione, assistenza, logistica, fatturazione, gestione dispositivi, flussi di lavoro documentali. In questi sistemi non c’è solo codice, ma un funzionamento solido fatto di regole di dominio, modello dei dati, guida all’utente e esperienza operativa. Proprio questo rende la modernizzazione impegnativa: il valore reale raramente risiede nell’interfaccia, ma nella logica di dominio consolidata.
Se la modernizzazione viene intesa come «ricostruire da zero», la perdita è inevitabile. Non perché le nuove tecnologie siano intrinsecamente sbagliate, ma perché conoscenze implicite del sistema legacy — casi particolari, dati storici, eccezioni di processo, dettagli normativi — durante la migrazione spesso non vengono ricostruite completamente. Il risultato sono costosi errori di regressione, tempi di processo modificati, problemi di accettazione e un progetto che si protrae più del previsto.
Tuttavia, Delphi si può modernizzare molto bene senza perdere la logica di dominio. La chiave è un approccio controllato e graduale: prima creare trasparenza (architettura, dati, rischi), poi disaccoppiare (UI, accesso ai dati, logica di dominio), quindi modernizzare (driver DB, Unicode/64-Bit, API, servizi, multiplatform) — garantendo nel contempo la continuità operativa. Questo contributo descrive pattern di modernizzazione pragmatici, insidie tipiche e una procedura che funziona in ambienti B2B con alta criticità di processo.
Perché la modernizzazione di Delphi raramente è un «progetto tecnico»
Nella realtà le modernizzazioni non falliscono per una flag del compilatore mancante, ma per ipotesi errate sul comportamento del sistema. Le applicazioni Delphi ampliate nel tempo contengono spesso:
- Regole di dominio in eventi GUI (OnClick, OnExit, OnValidate), spesso distribuite su molti form
- Statement SQL «vicini alla superficie» e ottimizzati da anni per una specifica base dati
- Bypass per dati storici, casi particolari, varianti cliente o logica multi-tenant
- Processi batch che in pratica girano a orari fissati e hanno dipendenze
- Integrazioni con ERP, DMS, CRM o macchine, scarsamente documentate
- Conoscenza tacita sotto forma di routine operative: «Se errore X, prima verificare Y»
Chi parte con un rewrite in modalità Big-Bang deve rigenerare tutta quella conoscenza — inclusi gli errori che la soluzione vecchia non presenta più da tempo. L’approccio migliore è trattare la logica di dominio come un asset: prima isolare, poi mettere in sicurezza, poi modernizzare.
Modernizzare senza perdita di logica: obiettivo e principi guida
Un quadro obiettivo sostenibile per sistemi B2B non è un «tutto nuovo», ma un’architettura che abiliti il cambiamento. Caratteristiche tipiche:
- Responsabilità separate (UI, dominio/logica di business, accesso ai dati, integrazioni)
- Testabilità e misurabilità (test di regressione, logging, monitoring, build riproducibili)
- Sostituibilità incrementale (modernizzare la UI senza rifare subito il modello dati; migrare il DB senza riscrivere la UI)
- Capacità API (REST-Server o livello di servizio per collegare portali, mobile, integrazioni)
- Operabilità (Windows- e Linux-Services, deployment chiari, strategia di rollback)
In Delphi questo traguardo è particolarmente raggiungibile, perché è possibile riutilizzare unit e classi di dominio esistenti mentre si modernizza l’esterno: accesso ai dati da BDE verso BDE-Ablösung con connessione nativa, nuovi endpoint REST, nuovi moduli UI, nuovi deployment.
Inventario: cosa va realmente preservato?
Prima di «toccare» il codice, conviene fare un inventario strutturato. L’obiettivo non è una documentazione completa, ma una base decisionale solida.
1) Mappa della logica di dominio invece di un maratona di lettura codice
Si è dimostrata pratica una mappa della logica di dominio con le seguenti prospettive:
- Use-case: Quali flussi core sono critici per il business? (es. creare ordine, fattura, storno, reso, assistenza macchine, contratto di manutenzione)
- Regole: Quali validazioni, calcoli, automi di stato esistono?
- Varianti: Tenant, configurazioni cliente, regole specifiche per paese
- Interfacce: Import/Export, ERP/DMS/CRM, dispositivi/protocolli
- Batch/Job: esecuzioni notturne, report, riconciliazioni dati
Dalla mappa nascono pacchetti di modernizzazione prioritizzati: cosa deve rimanere stabile, cosa può cambiare, cosa può essere posticipato.
2) Rendere visibili i debiti tecnici
Debiti tecnici tipici in vecchi sistemi Delphi:
- Dipendenze Borland BDE/Paradox
- Stringhe ANSI/mancata migrazione Unicode
- Solo 32-Bit, componenti di terze parti obsolete
- Logica di form monolitica, variabili globali, unit con effetti collaterali
- Confini di transazione non chiari e «SQL ovunque»
L’arte sta nel non «ripulire» questi punti in modo dogmatico, ma nel ordinarli in una sequenza che minimizzi i rischi e massimizzi il valore per il business.
Disaccoppiamento dell’architettura: la leva contro la perdita di logica
La ragione più comune della perdita di logica è la mescolanza di UI, accesso ai dati e regole di dominio. La modernizzazione inizia quindi con il disaccoppiamento — non con un «nuovo framework UI».
Architettura Layer-3 come stato obiettivo pragmatico
Per molte applicazioni Delphi esistenti una Layer-3 Architektur funziona molto bene:
- Presentation Layer: VCL/FMX-Forms, ViewModel/Presenter, validazione limitata all’UI (formato, campi obbligatori)
- Business Layer: modelli di dominio, servizi, regole, logica di stato, calcoli
- Data/Integration Layer: repository, parti SQL/ORM, adapter di interfaccia, client REST, messaging
Il valore aggiunto: la logica di dominio diventa testabile e riutilizzabile. Successivamente un portale cliente, un REST-Server o un Windows- und Linux-Services possono usare esattamente gli stessi servizi di dominio. In questo modo modernizzate „la pelle“ senza reinventare il nucleo logico.
Strangulation Pattern: abbracciare gradualmente il sistema legacy
Un pattern di migrazione consolidato è lo Strangulation Pattern: le nuove funzionalità nascono già nella nuova struttura (es. servizio di dominio + repository), mentre i form esistenti vengono convertiti progressivamente. Il mondo vecchio rimane operativo, ma viene sostituito pezzo per pezzo dalla nuova implementazione.
È importante invertire attivamente le dipendenze: non più «il form chiama SQL», ma «il form chiama il service», e il service prende le decisioni. Questa piccola inversione spesso produce il guadagno più significativo.
Modernizzare l’accesso ai dati: BDE-Ablösung e pianificare con cura FireDAC
Un passo centrale nella modernizzazione è la BDE-Ablösung. Le aziende sottovalutano spesso che non si tratta solo di driver, ma di semantica SQL, transazioni, locking, tipi di dato e comportamento in caso di errore. Stack Delphi moderni puntano tipicamente su BDE-Ablosung mit nativer Anbindung con driver nativi (ad es. per MariaDB/MySQL, PostgreSQL, SQL Server).
Cosa si decide realmente durante la migrazione
- Database target: si rimane sul DB esistente? Ha senso una ristrutturazione (es. Paradox/Firebird verso MariaDB o PostgreSQL)?
- Modello transazionale: dove iniziano/terminano le transazioni? Quali use-case devono essere atomici?
- Concurrency/Locking: ottimistico vs. pessimista, gestione dei deadlock, strategie di retry
- Dialetto SQL: funzioni di data, comportamento delle stringhe, gestione dei NULL, case-sensitivity
- Performance: indici, piani di query, paging, inserimenti batch
La logica di dominio è strettamente legata al comportamento dei dati. Chi migra «di fianco» rischia discrepanze sottili nella pratica: arrotondamenti, ordinamenti, limiti di data, conflitti di lock. Per questo il livello dati deve entrare presto nel piano di modernizzazione, incluso il percorso di migrazione e la strategia sui dati di test.
Passi pragmatici per la migrazione a FireDAC
Invece di rifare l’applicazione tutta insieme, la seguente sequenza si è dimostrata efficace:
- Introdurre una layer di accesso ai dati (Repository/DAO) come facciata
- Convertire singoli use-case a FireDAC (es. prima le operazioni di lettura, poi quelle di scrittura)
- Uniformare il connection-handling, la gestione errori, il logging
- Spegnere gradualmente i componenti BDE dove la facciata è stabile
Così l’applicazione rimane sempre rilasciabile e si evita un lungo periodo di «mezzo lavoro».
Unicode, 64-Bit e dipendenze: trappole di modernizzazione nei dettagli
Molte modernizzazioni non falliscono per il concetto, ma per dettagli sottovalutati. Tre di questi sono particolarmente comuni nei progetti Delphi.
Migrazione a Unicode: non solo le stringhe, ma i flussi dati
In versioni molto vecchie di Delphi i sistemi provengono dal mondo ANSI. Una migrazione a Unicode riguarda allora:
- Tipi di stringa e conversioni (WideString/AnsiString/UnicodeString)
- Gestione di file e percorsi (API Windows, percorsi di rete)
- Import/Export (CSV, campi a lunghezza fissa, EDI, interfacce legacy)
- Ordinamento/collation nel database
È fondamentale identificare i flussi dati critici (es. testi delle fatture, descrizioni articoli, indirizzi internazionali) e impostare test di regressione dedicati. Unicode non è tanto una «ristrutturazione», quanto un processo di qualità continuo e trasversale.
Passaggio a 64-Bit: la memoria non è l’unico tema
Il passaggio a 64-Bit viene spesso ridotto alle «dimensioni dei puntatori». In pratica conta di più:
- Componenti di terze parti non disponibili in 64-Bit
- Dipendenze COM/ActiveX
- DLL e driver (barcode, dispositivi, crittografia, firma)
- Installer/deployment e percorsi di registry (WOW64)
Una strategia sensata è prima inventariare tutte le dipendenze esterne e definire alternative. A quel punto il passaggio a 64-Bit diventa pianificabile e non una sorpresa poco prima del rilascio.
Windows 11 ARM64: verificare presto invece che pagare tardi
Con Windows 11 ARM64 emerge una nuova classe di sistemi target. Anche se non tutte le aziende necessitano subito build native ARM64, è prudente verificarlo precocemente:
- Esistono dipendenze native (DLL, driver) che non girano su ARM64?
- L’applicazione si basa su emulazione, e questo è accettabile?
- Com’è strutturato l’installer, come funziona update/repair?
Nei progetti di modernizzazione questo spesso rimane un tema «tardivo» che diventa costoso. Meglio: inserirlo presto nella roadmap di piattaforma e chiarirne gli aspetti tecnici.
REST-Server e servizi: rendere utilizzabile la logica di dominio per portali e integrazione
Molte aziende non modernizzano Delphi per via dell’aspetto desktop «vecchio», ma perché sorgono nuove esigenze: portale clienti, accessi partner, processi mobile, integrazione con ERP/DMS/CRM, pipeline di reporting. Per questo servono interfacce chiare. Un REST-Server è spesso il ponte più praticabile.
API prima? Solo se permessi e logica di dominio seguono
Un’API è utile solo se applica la stessa logica di dominio del client. Altrimenti nascono due insiemi di regole: uno nel desktop, uno nel backend. Le conseguenze sono incoerenze e falle di sicurezza.
Per questo uno strato REST-Server dovrebbe appoggiarsi il più possibile ai servizi di dominio. Componenti tipici:
- Autenticazione/Autorizzazione (ruoli, tenant, permessi)
- DTO/serializzazione con regole di versioning chiare
- Concetto di transazione ed errore (stati HTTP, Problem-Details, logging)
- Idempotenza e concorrenza (per retry, elaborazione in coda)
Così il REST-Server diventa il punto di integrazione stabile — non un «secondo client».
Modernizzare Linux-Services e servizi Windows
I processi batch e le integrazioni in molte aziende girano come servizi Windows, job di task scheduler o perfino istanze desktop «nascoste». Durante la modernizzazione conviene consolidarli:
- Separare UI e logica in background
- Piani di esecuzione configurabili e parametri operativi chiari
- Logging pulito (log strutturati, correlazione per job/request)
- Opzione di eseguire i servizi sotto Linux (es. per deployment containerizzati)
Il vantaggio non è solo «moderno», ma operativo: operazioni riproducibili, meno interventi manuali, ricerca guasti più efficace.
Modernizzare la UI senza toccare il nucleo: VCL, FMX e approcci ibridi
Molti piani di modernizzazione partono dall’UI. Può essere sensato — purché sia chiaro il beneficio atteso. Quando la logica di dominio è disaccoppiata, l’UI può essere rinnovata con rischio molto più basso.
Modernizzare VCL gradualmente
VCL resta in molti scenari B2B una scelta robusta, soprattutto in ambienti con forte dipendenza da Windows e alta produttività desktop. Modernizzare può significare:
- Ridurre la logica UI (Presenter/ViewModel), spostare le regole di dominio nei servizi
- Pulire il parco componenti, consolidare controlli custom
- Migliorare la reattività (async, job in background, progress, cancel)
- Accessibilità migliorata, validazione coerente, messaggi di errore più chiari
Questo produce beneficio tangibile senza riscrivere l’interfaccia completamente.
Delphi Multiplatform: quando FMX ha senso
Se esistono requisiti multiplatform reali (Windows, macOS, eventualmente Linux nel contesto dei servizi), FMX può essere un’opzione. Fondamentale è l’aspettativa: multiplatform comporta lavoro di test e integrazione aggiuntivo (font, stampa, dialog OS, file system, packaging/deployment). I costi sono prevedibili se la logica di dominio è già in uno strato pulito.
Una via pragmatica frequente è ibrida: VCL resta per il client Windows, mentre nuove interfacce (portale, app mobile) consumano il REST-Server. In questo modo si ottiene multiplatform attraverso i confini di sistema, non tramite un singolo stack UI.
Testing e regressione: come «inchiodare» la logica di dominio
«Perdere la logica di dominio» significa nella pratica: il sistema produce risultati diversi nei casi limite. Questo raramente è subito evidente, ma è costoso. Perciò la testabilità non è un lusso, ma uno strumento di modernizzazione.
Use-case d’oro e dati di riferimento
Si è rivelato efficace un set di use-case «golden»: flussi reali e critici con dati definiti e risultati attesi (es. catena documentale da offerta a nota di credito, o ordine di manutenzione con ricambi e timbrature). Questi vengono stabiliti come test di regressione o almeno come script di test ripetibili.
Importante: non solo i percorsi di successo, ma anche i percorsi di errore tipici (conflitti di lock, permessi mancanti, anagrafiche incomplete, file di import duplicati).
Automazione dove ha il maggiore effetto leva
Non ogni progetto legacy ha bisogno subito dell’80% di copertura unit. Il ROI elevato si ottiene spesso su:
- Servizi di dominio (calcoli, regole, transizioni di stato)
- Accesso ai dati con contratti chiari (mapping, SQL, transazioni)
- Test API (auth, permessi, versioning)
L’obiettivo è stabilità durante le modifiche, non metriche accademiche.
Modello di lavoro pratico: un piano di modernizzazione per fasi
Dal punto di vista B2B la modernizzazione deve rimanere rilasciabile. Un piano tipico, orientato sui rischi:
Fase 1: Analisi, architettura obiettivo, Quick Wins (2–6 settimane)
- Mappa di sistema (moduli, database, interfacce, job, dipendenze)
- Matrice dei rischi (BDE, terze parti, 32/64-Bit, Unicode, deployment)
- Definizione dell’architettura obiettivo (Layer-3, livello servizi, strategia API)
- Quick Wins: stabilizzare il processo di build, migliorare il logging, ordinare il versioning
Fase 2: Disaccoppiamento della logica di dominio (continuo, incrementale)
- Identificare i domain services e estrarli dai form
- Introdurre facciate repository
- Istituire i primi test di regressione per use-case critici
Fase 3: Modernizzazione accesso ai dati/strato DB
- Introdurre FireDAC, stabilire concetto di connessione e transazione
- BDE-Ablösung modulare (o migrazione DB con esercizio in parallelo)
- Testare performance e comportamento di locking sotto carico
Fase 4: Dotare di REST-Server e integrare
- API con auth, permessi, versioning
- Collegare portali/integrazioni senza logica duplicata
- Consolidare servizi per batch e processi background
Fase 5: Decisioni di piattaforma e UI (64-Bit, ARM64, multiplatform)
- Build 64-Bit, sostituzione dipendenze
- Verificare/pianificare compatibilità ARM64
- Modernizzazione UI: refresh VCL o FMX/ibrido, basata sul valore per il business
L’ordine è scelto consapevolmente per ottenere trasparenza precocemente, stabilizzare il nucleo e solo dopo distribuire cambiamenti «visibili». In questo modo il rischio diminuisce e l’operatività resta prevedibile.
Anti-pattern tipici: cosa rende le modernizzazioni inutilmente costose
Alcuni schemi ricorrono sempre nelle verifiche e nei progetti di recupero:
- «Rifacciamo tutto e trasferiamo solo le feature»: quasi sempre provoca perdita di logica, perché i casi particolari mancano.
- API come mondo parallelo: le regole di business rimangono nel client e vengono reinventate nel backend.
- Cambio di database senza test semantici: stessi dati, comportamento diverso (NULL, ordinamento, logica sulle date).
- Gestione dipendenze troppo tardiva: 64-Bit/ARM64 fallisce per una piccola DLL subito prima del go-live.
- «Refactoring prima di avere un obiettivo»: molte modifiche, poco valore misurabile, alta regressione.
Il controprogetto è sempre lo stesso: prima chiarire architettura obiettivo e rischi, poi rifare in modo incrementale, testando e rendendo visibile la logica di dominio.
Conclusione: modernizzare significa preservare — e ampliare in modo mirato
Modernizzare Delphi senza perdere la logica di dominio non è una contraddizione, ma una disciplina. Le aziende non devono scegliere tra «tutto mantenere» e «tutto sostituire». Con una separazione architetturale pulita (es. Layer-3), una BDE-Ablösung controllata verso FireDAC, una strategia API tramite REST-Server e un piano chiaro per Unicode, 64-Bit e nuove piattaforme come Windows 11 ARM64 è possibile trasformare gradualmente un sistema consolidato in una struttura sostenibile per il futuro.
Il punto cruciale è trattare la logica di dominio come asset core: isolare, rendere testabile, poi modernizzare. Così nasce un’architettura che supporta portali, servizi e requisiti multiplatform senza mettere a rischio l’operatività.
Se state pianificando una modernizzazione Delphi e volete integrare logic, accesso ai dati e operatività in modo pulito, parliamo di un percorso di migrazione realistico: https://net-base-software-gmbh.de/kontakt/