Prodotto Quantica
Entangle migra il tuo iSeries su cloud moderno — AWS o GCP — conservando la logica business. Max 60 giorni lavorativi dalla discovery al cutover completo. Niente più hardware IBM, niente più licenze per terminal, niente più dipendenza da un developer RPG che andrà in pensione tra 3 anni.
Non vuoi dismetterlo subito? C'è anche Entangle Bridge — il mainframe resta acceso con un'API davanti.
Il problema
IBM Power, rinnovi annuali, contratti di manutenzione, licenze per terminal. Sono tipicamente 15–40 k€/anno di sola infrastruttura prima ancora di parlare di sviluppatori.
RPG, CL, DB2/400. Trovare un developer decente richiede mesi. Quando il vostro va in pensione, siete bloccati.
Niente integrazioni moderne, niente mobile, niente AI. Il tuo business cresce, il gestionale no — e diventa un limite competitivo.
Cosa facciamo
Entangle non è un rewrite da manuale. Analizziamo cosa fa davvero il tuo AS/400, mappiamo entità e programmi critici, ricostruiamo l'equivalente su stack moderno. La logica business è preservata, tradotta in codice leggibile, versionato su Git. Il risultato è un sistema che fa le stesse cose — meglio e a meno.
Scegliamo in base al tuo stack esistente e al budget. Niente lock-in vendor, tutto portabile.
Tecnologie mainstream. Il tuo prossimo sviluppatore le conosce già — zero corso su RPG.
Terraform, versionato. Il tuo sistema è riproducibile, non un mistero installato 20 anni fa da qualcuno che non c'è più.
Test di shadow run: ogni modulo nuovo viene confrontato contro il mainframe (stesso input → stesso output) prima del cutover.
ETL da DB2/400 a Postgres con validazione row-by-row. Niente dato perso, niente sorprese post-cutover.
Il mainframe resta in produzione in parallelo finché non spegni tu. Rollback disponibile in qualsiasi momento.
Come funziona
Non spegniamo il mainframe il primo giorno. Lo sostituiamo modulo per modulo, con test di parità e rollback sempre disponibile.
Giorni 1–5
Inventariamo librerie, tabelle, programmi RPG, job scheduler. Individuiamo il "perimetro critico" — cosa serve davvero al business e cosa può essere dismesso.
Giorni 6–25
Ricostruiamo i moduli critici su stack cloud. Ogni modulo nuovo gira in parallelo al mainframe in "shadow mode" — stesso input, verifica stesso output.
Giorni 20–40
ETL da DB2/400 a Postgres in parallelo al rebuild. Validazione row-by-row, riconciliazione saldi. Il dato viene normalizzato e documentato.
Giorni 41–55
Modulo per modulo, utente per utente. Il mainframe resta acceso finché non dai il via allo spegnimento. Rollback sempre disponibile.
Giorni 56–60
Documentazione, runbook, training al tuo team. Poi zero vendor IBM, zero licenze per terminal, zero hardware. Il risparmio parte subito.
Cosa puoi fare dopo
IBM Power dismesso, licenze terminal cancellate, manutenzione annullata. ROI tipicamente entro 6 mesi.
API REST di default — app per agenti, portale clienti, dashboard gestionali moderni. Niente più terminal 5250.
CRM, e-commerce, marketplace, PSP. Parli HTTP/JSON — il resto del mondo pure.
Dati in Postgres = dati leggibili da LLM. Copilot verticali per venditori, magazzino, amministrazione. Senza esporre nulla fuori.
La fatturazione elettronica emette direttamente dai tuoi dati nuovi, nessun ponte fragile. SDI, conservazione, scadenziari in un unico sistema.
Il tuo prossimo developer conosce già lo stack. Nessun onboarding di 6 mesi su RPG, nessun single-point-of-failure umano.
Opzione alternativa
Se il business case per la dismissione completa non c'è (volumi molto elevati, vincoli regolamentati, tempi non giusti) — ti mettiamo uno strato API REST e MCP davanti al mainframe. Non è il prodotto principale, ma è un ponte che ti libera subito: app mobile, portale clienti, integrazione Quantica Leap, agenti AI che leggono i dati. Il tuo RPG resta dov'è, la produzione non si ferma.
Il layer è esterno, parla DB2/400 nativo e chiama programmi. Il tuo codice legacy resta intatto.
Riserva massima di 30 giorni lavorativi dalla firma al primo rilascio. Tipicamente 15–20 giorni.
Il giorno che vuoi davvero spegnere il mainframe, il Bridge diventa il contratto di Entangle pieno — senza buttare il lavoro fatto.
In sintesi: Entangle è uscita dal mainframe, Entangle Bridge è convivenza migliorata. Se sei indeciso, ne parliamo in discovery — spesso il Bridge è un passo 1 della migrazione completa.
Tempi e prezzo
Ogni AS/400 è diverso per volume, tabelle, logica esposta. Non esiste un prezzo di listino — ma esiste un prezzo fisso dopo la discovery e una deadline dura a 60 giorni lavorativi, con fatturazione ripartita a milestone settimanali.
2–3 giorni lavorativi, gratuita. Mappiamo il tuo sistema e ti diamo un piano di delivery + quotazione chiusa.
Massimo 60 giorni lavorativi dalla firma al cutover. Quotazione chiusa, fatturazione a milestone — niente progetti infiniti.
30 giorni lavorativi riservati, di solito meno. Quotazione unica, senza fasi multiple.
FAQ
Max 60 giorni lavorativi dalla firma del contratto al cutover completo. Il mainframe resta in parallelo durante tutto il processo — rollback sempre disponibile. Se il tuo sistema è particolarmente esteso (>1000 tabelle o logica RPG molto stratificata) concordiamo in discovery un secondo sprint da 30 gg per ottimizzazione post-cutover, ma l'operatività è già sul cloud a giorno 60.
No. Ogni modulo nuovo gira in "shadow mode" (stesso input al mainframe e al nuovo sistema, confronto automatico degli output) per settimane prima del cutover. La migrazione dati è validata row-by-row.
Li ricostruiamo su scheduler moderni (cron, Step Functions, Cloud Scheduler). Stesso comportamento, logging migliore, rollback più semplice.
Non proprio. Preserviamo la logica business — tradotta in codice leggibile e versionato. Il "come" cambia, il "cosa fa" no. Dove troviamo codice RPG stratificato da 30 anni con regole non più valide, semplifichiamo (con il tuo ok).
Discutiamo insieme: dipende dal tuo stack esistente (se già usi Office365/Azure, il tuo team fa meno fatica su Azure — anche se non è AWS/GCP pure, lo supportiamo), dai dati che devi gestire, dal budget. Nessun lock-in: è tutto portabile.
No. Il Bridge è spesso la "fase 0" di una migrazione completa: ti libera subito sul lato applicativo (mobile, integrazioni) mentre pianifichiamo il rebuild. Il codice del Bridge resta utile anche dopo, come API gateway.
Sì. Post-migrazione Leap legge i dati dal nuovo Postgres nativamente. Con Bridge, Leap chiama le API REST davanti al mainframe. In entrambi i casi nessuna doppia digitazione.
Discovery gratuita di 2–3 giorni, poi quotazione chiusa. Senza obblighi.
Prenota discovery gratuita →