Contatti

Parla con la nostra AI

Sistema di qualifica · EWEBITE Attivo
EW
Questo non è un form di contatto.
Sono qui per capire se ci sono le condizioni per lavorare insieme — non con tutti ha senso farlo.
EW
Legacy Migration
Laravel
Database Engineering
Sviluppo Software & Legacy Migration

Hitachi Rail

Modernizzazione di un sistema gestionale industriale con vincolo di retrocompatibilità totale. Un database non conforme agli standard moderni, tre sistemi attivi in parallelo, zero tolleranza alle interruzioni operative.

Cliente

Hitachi Rail

Attività

Sviluppo web app Laravel

Periodo

2018

Tipo Progetto

Progressive WebApp Custom

Project Overview

Hitachi Rail gestiva la manutenzione del proprio parco macchine in uno stabilimento produttivo a Reggio Calabria attraverso un software costruito anni prima, nel frattempo diventato obsoleto e non più espandibile.
Il sistema funzionava — ma non era accessibile da mobile, non era manutenibile nel tempo e non aveva margine per crescere.

La richiesta non era sostituirlo. Era sostituirlo senza fermarlo. La nuova piattaforma doveva affiancare quella esistente, prenderne progressivamente le funzioni e non interrompere nulla di ciò che già girava. Tre sistemi attivi in parallelo, zero tolleranza alle interruzioni, tempi stringenti.

Il vincolo reale non era tecnologico. Era di metodo: intervenire su un sistema in produzione, senza documentazione strutturata del preesistente, con la certezza che qualsiasi errore avrebbe avuto impatto diretto sull'operatività dello stabilimento.

Il punto di partenza

- Software gestionale legacy attivo, non espandibile e non accessibile da dispositivi mobili
- Struttura dati costruita con logiche datate, non modificabile senza rischio di compromettere i sistemi ancora in uso
- Tre applicativi attivi in parallelo da gestire durante la transizione: il gestionale web, un programma desktop e un'app mobile Android
- Nessuna documentazione tecnica del sistema esistente
- Scadenze immediate

La strategia

Il punto critico era uno: il database esistente non poteva essere toccato. Qualsiasi modifica alla struttura dei dati avrebbe rischiato di bloccare i sistemi ancora attivi. La soluzione non era aggirare il problema — era costruire intorno ad esso.
Il team ha scelto di adattare il nuovo software alla struttura dati esistente, non il contrario. La nuova piattaforma è stata progettata per leggere, interpretare e scrivere dati rispettando le logiche del vecchio sistema — traducendo internamente le incoerenze storiche senza esporle al nuovo front-end e senza alterare nulla di ciò che i sistemi legacy si aspettavano di trovare.
Per garantire che ogni aggiornamento non rompesse funzioni critiche già operative, è stata costruita una copertura di test sistematica: ogni rilascio veniva verificato prima di andare in produzione. Il risultato è stato un passaggio di consegne progressivo e controllato — un sistema moderno, accessibile anche da smartphone, che conviveva con quello vecchio fino alla sua dismissione completa.

Zero interruzioni operative

durante l'intera fase di transizione: i sistemi legacy sono rimasti attivi e funzionanti in parallelo alla nuova piattaforma per tutta la durata del progetto.

Tre sistemi legacy dismettibili in sequenza

web app, applicativo desktop e app mobile Android — grazie a un'architettura progettata per la sostituzione progressiva, non la sostituzione immediata.

Presentazione al LaravelDay 2018

(Verona, 29–30 novembre 2018): il caso è stato selezionato come esempio di applicazione non convenzionale del framework a livello nazionale, davanti alla community italiana degli sviluppatori Laravel.

Capire cosa non si può toccare — e cucire
il software direttamente addosso.

01. Mappare prima di costruire

Prima di scrivere una riga di codice, il team ha analizzato la struttura del database esistente e identificato i vincoli reali: quali campi non potevano cambiare, quali formati dovevano essere rispettati, quali funzioni del sistema legacy erano intoccabili. La progettazione è partita dai limiti, non dagli obiettivi.

02. Adattare il framework, non il dato

La retrocompatibilità è stata ottenuta configurando Laravel per riconoscere e rispettare le logiche del database originale, non modificando il database. Questo ha separato nettamente il layer applicativo da quello dei dati, rendendo la nuova piattaforma estendibile senza rischi per i sistemi attivi.

03. Rendere ogni rilascio verificabile

In un sistema produttivo attivo, ogni aggiornamento è un rischio. La suite di test di regressione ha trasformato ogni rilascio da operazione ad alto rischio a processo controllato — garantendo che le nuove funzionalità non compromettessero le funzioni critiche già operative.

Parliamo di cosa ti ostacola oggi dal crescere online con un progetto serio