Tabella di marcia per la migrazione da Monolith a microservizi: modernizzare le app aziendali

Michael Labutin

5 aprile 2025 12 min

Se siete qui, è probabile che il vostro sistema monolitico stia diventando più un peso che una risorsa. Cicli di rilascio lenti, problemi di scalabilità e un'architettura rigida rendono più difficile stare al passo. Più la vostra applicazione diventa grande, più diventa frustrante. Le nuove tecnologie non si integrano senza problemi, l'agilità ne risente e l'affidabilità inizia a diminuire.

I microservizi possono cambiare le cose rendendo il sistema modulare, accelerando le implementazioni e consentendo di scalare esattamente ciò che serve quando serve. Ma c'è un problema: la migrazione non consiste solo nel dividere il codice. Se non la si pianifica correttamente, si rischia di ritrovarsi con una maggiore complessità, incubi di integrazione e costi imprevisti.

In questo articolo vi illustrerò una tabella di marcia reale per passare dal monolite ai microservizi. Niente scemenze: solo passi pratici, lezioni duramente acquisite da i nostri architetti di soluzionie le strategie che funzionano davvero. Immergiamoci.

Fasi della migrazione da un'architettura monolitica a un'architettura a microservizi

Fase 1: Pianificazione di una migrazione da monolite a microservizi

Ho visto molte aziende pensare che i microservizi siano la soluzione magica, per poi ritrovarsi con una maggiore complessità, flussi di lavoro interrotti e costi alle stelle. E se c'è una cosa che ho imparato è che buttarsi a capofitto nella tecnologia senza un piano solido è una strada veloce verso il caos.

La tentazione è quella di iniziare a smontare un monolite e a creare servizi, ma prima ancora di toccare il codice, lavoriamo con i clienti per definire il perché, il quando e il come della migrazione. In questo modo, ogni passo in avanti produce effettivamente valore.

Stabilire gli obiettivi giusti: perché si sta migrando?

Ogni volta che i clienti si rivolgono a noi per passare da un sistema monolitico a uno a microservizi, chiedo che cosa li spinga a passare. Le risposte variano, ma il più delle volte sento dire: perché i loro concorrenti lo stanno facendo. E onestamente, questa non è una buona ragione. Passare ai microservizi senza un obiettivo chiaro di solito porta solo a più grattacapi, non a un vero progresso.

Quindi, prima di fare il grande passo, chiedetevi:

Cosa spera di ottenere?
Avete considerato alternative all'uso dei microservizi?
Come si fa a sapere se la transizione sta funzionando?

Se non siete 100% sicuri, non preoccupatevi. Vi aiuteremo a definire in anticipo le metriche chiave e i risultati di business, in modo che ogni decisione tecnologica sia utile.

Microservizi: adatti a tutti? Non sempre

I microservizi offrono modularità, scalabilità indipendente e innovazione più rapida. Ma non sono una pallottola d'argento. Alcune aziende si trovano bene con un monolite, soprattutto se la loro applicazione è semplice, stabile e non cambia molto.

Immaginate un piccolo portale per i dipendenti o un sistema di inventario utilizzato solo da una manciata di persone. Se funziona bene e non ha bisogno di aggiornamenti costanti, suddividerlo in microservizi potrebbe aggiungere un sacco di complessità senza alcun vantaggio reale.

Ecco perché non spingiamo i microservizi solo per il gusto di farlo. Analizziamo invece le vostre esigenze specifiche e se i microservizi porteranno dei vantaggi reali. Se è così, bene: li adottiamo. In caso contrario, troviamo un modo migliore di procedere.

Valutare il monolite: sapere con cosa si ha a che fare

Una volta deciso che i microservizi sono la mossa giusta, ci piace fare un check-up completo del sistema per vedere come tutto è collegato. Cerchiamo i punti di rallentamento, i potenziali problemi di dipendenza e dove risiedono tutti i dati critici.

Saltare questa fase è rischioso. Se non sapete cosa c'è sotto il cofano, potreste accidentalmente far cadere l'intero sistema come un domino. Mappando ciò che funziona, ciò che è in ritardo e ciò che potrebbe rompersi, creiamo un piano di migrazione intelligente che affronta prima le aree più critiche, riducendo al minimo i rischi, evitando i tempi di inattività e rendendo la transizione il più agevole possibile.

Scegliere la giusta strategia di migrazione

Ormai avrete capito che non sono un fan dell'abbattimento di un intero monolite da un giorno all'altro. È troppo rischioso, troppo disordinato e di solito non vale la pena di stressarlo. Invece, opto per un approccio graduale che vi permetta di ottenere risultati rapidi mantenendo stabili le vostre operazioni.

Una delle mie strategie preferite è il pattern Strangler Fig, che lascia coesistere il vecchio sistema e i nuovi microservizi finché non si è pronti per il passaggio completo.

Il Branch by Abstraction è utile quando si devono apportare modifiche all'interno del monolite stesso: aggiungiamo un livello, spostiamo i componenti uno per uno e ritiriamo il vecchio materiale senza far saltare tutto.

Se l'affidabilità è fondamentale, Parallel Run mantiene in funzione entrambi i sistemi, confrontando i risultati prima di impegnarsi completamente.

E se non si può intervenire sul monolite, Change Data Capture ci permette di tenere traccia delle modifiche al database per mantenere sincronizzati i microservizi.

Non esiste un unico metodo migliore: tutto dipende dalla vostra configurazione. Il nostro team sceglie anche quali parti migrare per prime, concentrandosi su quelle che avranno l'impatto maggiore. Ad esempio, un sistema di checkout per l'e-commerce che gestisce migliaia di ordini giornalieri o un motore di analisi dei dati che si aggiorna costantemente, dovrebbero essere migrati per primi. In questo modo, si ottengono rapidamente benefici reali e si mantengono le operazioni in ordine.

Allineamento di team e processi

Incorporare i microservizi significa anche modificare il modo in cui lavorano i team. Invece di un team enorme che gestisce un monolite, suggerisco di passare a team più piccoli e interfunzionali, ognuno dei quali è proprietario di un microservizio specifico. In questo modo, le decisioni vengono prese più rapidamente e ognuno sa esattamente di cosa è responsabile.

Inoltre, i nostri esperti introducono i principi DevOps e l'automazione fin dal primo giorno, in modo che l'introduzione di nuove funzionalità avvenga senza problemi.

"Passare da un monolite a un microservizio non è solo una modifica tecnologica: colpisce la velocità di sviluppo, la stabilità del sistema e la capacità di scalare. Senza un piano preciso, i costi possono salire alle stelle e le integrazioni possono trasformarsi in un vero e proprio mal di testa. Innowise rende la transizione fluida ed efficiente, in modo che possiate mantenere l'agilità e concentrarvi sulla crescita della vostra azienda".

Dmitry Nazarevich

CTO

Fase 2: Identificazione e definizione dei microservizi

Una volta tracciata la strategia di migrazione, la prossima grande domanda è capire come spezzare il monolite in microservizi senza fare confusione. Ho visto aziende cercare di disaccoppiare tutto in una volta o scegliere moduli a caso da separare. In entrambi i casi, questo porta a perdite di tempo, dipendenze interrotte e mesi di frustrante rielaborazione.

La mia regola generale è: mantenere l'attenzione sul business. Ciò significa che ogni microservizio deve corrispondere a una funzione aziendale reale, non a un pezzo di codice casuale.

Trovare i confini naturali del servizio

Una delle insidie più comuni che vediamo è la suddivisione di un monolite in livelli tecnici. Cioè separare il frontend, il backend e il database in servizi diversi. Questo è un modo infallibile per ritrovarsi con microservizi strettamente accoppiati e troppo chiacchieroni che non scalano bene. Invece, utilizziamo il Domain-Driven Design (DDD) e i contesti delimitati per suddividere le cose in un modo che abbia davvero senso.

Prendiamo una piattaforma di e-commerce. Invece di dividerla in un generico servizio di front-end e in un servizio di back-end, la separiamo in funzioni aziendali reali come l'elaborazione degli ordini, la gestione dell'inventario, i pagamenti e la gestione degli utenti. Ogni servizio possiede la propria logica e i propri dati, mantenendoli accoppiati in modo da poter scalare in modo indipendente ed evolvere senza rompere tutto il resto.

Privilegiare i servizi per la migrazione

Non sono un fan dell'approccio "big bang". Cercare di migrare tutto in una volta è solo fonte di problemi. Invece, ci concentriamo su cosa interrompere per primo, esaminando:

Dipendenze minime. I moduli meno aggrovigliati sono più facili da staccare senza rompere tutto.
Impatto sul business. Tutto ciò che è legato ai ricavi o all'esperienza del cliente di solito passa in primo piano.
Cambiamenti frequenti. I servizi che vengono aggiornati continuamente traggono il massimo vantaggio dalla flessibilità dei microservizi.

Questo approccio ci aiuta a ottenere vittorie rapide e a mostrare il valore iniziale, rendendo più facile l'acquisizione da parte del team. Ad esempio, in un sistema HR aziendale, l'elaborazione delle buste paga potrebbe essere un ottimo microservizio, poiché gestisce calcoli complessi e specifici per ogni regione. Ma un elenco statico di aziende? Probabilmente non vale la pena di spendere di più e può rimanere nel monolite per un po' di tempo.

Evitare la trappola del monolite distribuito

L'ultima cosa che vogliamo è convertire il monolite in microservizi e ritrovarci con un gruppo di servizi che dipendono troppo l'uno dall'altro. Per evitare questo problema, noi:

Definire API chiare (REST, gRPC o event-driven) in modo che i servizi comunichino senza problemi e senza inutili tira e molla.
Assicuratevi che ogni servizio sia proprietario dei propri dati: niente database condivisi che creano colli di bottiglia.
Mantenere le dipendenze al minimo, in modo che i servizi possano essere aggiornati senza interrompere tutto il resto.

Mantenendo i servizi accoppiati in modo lasco, possiamo aggiornarli o modificarli senza preoccuparci di rompere tutto il resto.

Coinvolgere i team

Come ho detto prima, i microservizi brillano davvero quando ogni team è proprietario del proprio servizio dall'inizio alla fine. Si ottiene un feedback più rapido, una maggiore responsabilità e un minor numero di scambi tra i team. Noi di Innowise aiutiamo le aziende a organizzare i loro team in modo che sviluppatori, operativi, QA e tutti gli altri possano lavorare insieme senza problemi.

Scomponete il vostro monolite in microservizi e superate i picchi di traffico.

Fase 3: Gestione dei dati nei microservizi

Dopo aver diviso il vostro monolite in microservizi, la prima domanda che ci si pone è di solito: cosa ne facciamo dei dati? In una configurazione monolitica, tutto è legato a un unico grande database, che funziona fino a quando non funziona. In una configurazione a microservizi, quel database condiviso diventa rapidamente un collo di bottiglia, rallentando tutto e rendendo impossibile scalare i servizi in modo indipendente.

Per questo motivo, io propendo per un modello di dati decentralizzato, in cui ogni microservizio possiede i propri dati. Se fatto bene, permette a ogni servizio di crescere, adattarsi e scalare senza inciampare continuamente l'uno nell'altro.

Abbandonare il database monolitico

Un database massiccio e completo potrebbe sembrare la soluzione più semplice, ma in una configurazione a microservizi si trasforma rapidamente in un collo di bottiglia. Ogni servizio ha esigenze diverse e stipare tutto in un unico database crea solo ostacoli. Scalare diventa difficile, le dipendenze si accumulano e anche piccole modifiche possono causare problemi a livello di sistema.

Ecco perché ci siamo divisi in microservizi più piccoli, specifici per ogni servizio:

Controlla i propri dati. Niente più conflitti o modifiche accidentali da parte di altri team.
Scala da sola. I servizi non devono lottare per le risorse del database.
Può cambiare liberamente. L'aggiornamento di un servizio non rischierà di interrompere l'intero sistema.

In questo modo, tutto è più flessibile, i team non si pestano i piedi a vicenda ed evitano il collo di bottiglia del database che rallenta tutti.

Migrazione dei dati

Muovere i dati da un monolite non è un momento di svolta. Una migrazione a strappo è rischiosa, quindi preferisco un approccio incrementale, suddividendo la migrazione passo dopo passo.

Di solito, ciò significa creare nuove tabelle o database per ogni microservizio e mantenerli sincronizzati con il vecchio sistema utilizzando il Change Data Capture (CDC) o la doppia scrittura. In questo modo, ogni servizio assume gradualmente la proprietà dei propri dati, senza tempi di inattività e senza spiacevoli sorprese.

Mantenere la coerenza dei dati

In un monolite, c'è un unico grande database condiviso e transazioni ACID che assicurano che tutto si aggiorni (o fallisca) insieme. Con i microservizi, invece, ogni servizio gestisce i propri dati, quindi gli aggiornamenti non avvengono istantaneamente in tutto il sistema.

Invece di aggiornamenti diretti, i servizi parlano attraverso la messaggistica asincrona. Se viene effettuato un ordine, il servizio Ordini lancia un evento e il servizio Inventario si mette in ascolto per regolare le scorte. Questa configurazione permette di far funzionare le cose senza intoppi, anche se un servizio si blocca temporaneamente.

Naturalmente, ciò significa gestire la coerenza in modo intelligente. Innowise utilizza operazioni idempotenti per evitare i duplicati, meccanismi di retry per gestire gli intoppi e code di lettere morte per individuare gli errori. In questo modo, i dati rimangono accurati, anche quando le cose non vanno come previsto.

Fase 4: implementazione e integrazione

Bene, ora che abbiamo stabilito chiari confini di servizio e un solido piano di migrazione dei dati, è il momento di rimboccarsi le maniche e trasformare la strategia in azione. Vediamo come fare per ottenere questo risultato.

Costruire microservizi scalabili e resilienti

Il nostro team di sviluppo costruisce microservizi utilizzando strumenti moderni come Spring Boot e Node.js, assicurandosi che siano costruiti per scalare e gestire le sfide del mondo reale. Per far sì che le cose funzionino senza intoppi, utilizziamo modelli di progettazione intelligenti come gli interruttori per gestire i picchi di traffico e la degradazione aggraziata per evitare guasti a cascata. In questo modo, anche se un servizio ha un intoppo, il resto del sistema continua a funzionare senza problemi.

Mantenere viva l'eredità (per ora)

Spegnere il monolite durante la notte? Non è il caso. Al contrario, creiamo livelli di integrazione utilizzando API RESTful e broker di messaggi come RabbitMQ o Apache Kafka per mantenere sincronizzati i nuovi microservizi e i sistemi esistenti. Questi agiscono come ponti che permettono a tutto di comunicare senza problemi, senza interrompere i flussi di lavoro.

E quando è opportuno, introduciamo anche gateway API per potenziare e rendere sicure le interazioni, garantendo una transizione fluida e senza tempi di inattività.

Adozione della containerizzazione

Containerizziamo i vostri microservizi con Docker in modo che siano veloci, flessibili e facili da gestire. Con Kubernetes che gestisce l'orchestrazione, il ridimensionamento durante i periodi di attività o l'implementazione di aggiornamenti in ambienti diversi è un gioco da ragazzi. Questa configurazione mantiene tutto coerente, prevedibile ed efficace dal punto di vista dei costi, in modo che le operazioni IT non si sentano mai come un tiro mancino.

Automazione con le pipeline CI/CD

Il nostro team ha creato pipeline CI/CD con strumenti come Jenkins, GitLab CI o CircleCI per gestire automaticamente i test, la costruzione e le distribuzioni. Niente più aggiornamenti manuali o esercitazioni dell'ultimo minuto. I bug vengono individuati in anticipo, i rilasci sono più rapidi e il sistema rimane solido come una roccia.

Costruiamo un ecosistema di microservizi a tolleranza d'errore per la vostra azienda.

Fase 5: Test, distribuzione e monitoraggio

Senza le giuste protezioni, anche il sistema meglio progettato può incontrare colli di bottiglia, guasti imprevisti o semplicemente bloccarsi nel momento peggiore. Ecco perché il nostro team adotta un approccio senza scorciatoie, automatizzando tutto e individuando i problemi prima che diventino reali.

Test automatizzati

Il test non è solo la fase finale, ma fa parte dell'intero processo. Il nostro team GLP utilizza suite di test automatizzati a più livelli per individuare tempestivamente i guasti, in modo che nulla vada perso.

Test unitario. Ogni microservizio viene controllato con JUnit, Mocha e PyTest. Se c'è qualcosa che non va, lo notiamo subito.
Test di integrazione. API, dipendenze e flusso di dati devono sincronizzarsi. I nostri esperti utilizzano Postman, REST-assured e WireMock per assicurarsene.
Test del contratto. I microservizi devono rispettare le regole. Con Pact li teniamo sotto controllo, evitando che si interrompano le connessioni tra i servizi.
Test end-to-end. Eseguiamo scenari reali, dall'interfaccia utente fino al backend, utilizzando Selenium, Cypress e Playwright. In questo modo, l'intero sistema funziona come previsto.
Test di carico e di stress. Il nostro team spinge il sistema ai suoi limiti con JMeter, Gatling e Locust per vedere come si comporta in caso di traffico intenso.

Implementazioni prive di rischi

Nessuno vuole che una release sbagliata faccia crollare il proprio sistema, frustri gli utenti o faccia crollare i ricavi. Ecco perché il nostro team mantiene le distribuzioni sicure, controllate e pronte per il rollback con strategie collaudate.

Rilascio di canarini. Invece di cambiare le carte in tavola per tutti in una volta sola, iniziamo in piccolo, distribuendo gli aggiornamenti prima a una piccola percentuale di utenti. Se tutto va bene, continuiamo. Se c'è qualcosa che non va, i nostri esperti lo risolvono prima che gli altri se ne accorgano.

Diciamo che un'azienda di vendita al dettaglio vuole lanciare un programma di fidelizzazione a punti, ma il suo sistema di ordini è troppo complesso per essere modificato in modo sicuro. Un'azienda di vendita al dettaglio vuole lanciare un programma di fidelizzazione a punti, ma il suo sistema di ordini è troppo complesso per essere modificato in modo sicuro. Per andare sul sicuro, lo testiamo prima con un piccolo gruppo. Se tutto va bene, lo lanciamo su scala più ampia.

Distribuzioni blu/verdi. Il nostro team gestisce due ambienti live contemporaneamente:
- Blu (versione attuale): la versione stabile in vigore;
- Verde (versione aggiornata): la nuova versione, testata e pronta all'uso.

Quando siamo sicuri che la versione verde è solida, cambiamo immediatamente il traffico. Se qualcosa va storto, torniamo al blu. Zero tempi morti, zero stress.

Ad esempio, una piattaforma di viaggi vuole aggiungere i prezzi in tempo reale, ma il fatto di interferire con il vecchio sistema potrebbe compromettere le prenotazioni. Invece di fare il passo più lungo della gamba, il nostro team si orienta verso il blu-verde, inviando prima un piccolo gruppo di utenti alla nuova configurazione. Se tutto va bene, passiamo a tutti. Se le cose vanno male, torniamo indietro all'istante.

Bandiere di funzionalità e test A/B. A volte, il roll-out a 100% di utenti non è la mossa giusta. I flag delle funzionalità ci permettono di attivare o disattivare le funzionalità in modo dinamico, in modo da poterle testare in produzione senza impattare su tutti. Usiamo anche i test A/B per confrontare più versioni di funzionalità in condizioni reali prima di impegnarci in un rilascio completo.

Immaginate un'azienda di e-commerce che lancia un motore di raccomandazione alimentato dall'intelligenza artificiale. Invece di attivare l'interruttore per tutti, usiamo i Feature Flag per attivarlo prima per i clienti abituali. Se il coinvolgimento e le vendite aumentano, lo espandiamo; in caso contrario, lo spegniamo immediatamente.

Allo stesso tempo, il nostro team esegue test A/B, confrontando il vecchio sistema con quello nuovo e monitorando le metriche chiave come il valore del carrello e i tassi di conversione. Questi dati ci aiutano a perfezionare l'IA prima di un lancio su larga scala.

Monitoraggio proattivo e registrazione in tempo reale

I microservizi producono tonnellate di dati, quindi tenere d'occhio la salute del sistema in tempo reale è un must. Il nostro team imposta un monitoraggio a più livelli con strumenti come Prometheus, Grafana e New Relic per monitorare la velocità, l'utilizzo della memoria e gli errori. In questo modo possiamo individuare i problemi prima che diventino un problema. Utilizzando ELK Stack, Fluentd e altri, raccogliamo anche tutti i log (in pratica, la traccia digitale delle vostre app) in un unico posto, in modo che nulla sfugga. E se qualcosa va storto, gli avvisi automatici fanno sì che i nostri tecnici se ne occupino al più presto.

Backup e ripristino dei dati

Siamo realisti: nessun sistema è 100% a prova di errore. L'hardware muore, il software si blocca e le minacce informatiche non smettono di evolversi. Ecco perché la protezione dei dati è indispensabile. Per questo il nostro team imposta strategie di backup automatizzate in modo che i vostri dati critici rimangano al sicuro e facili da recuperare.

Istantanee automatiche. Utilizziamo AWS RDS, Google Cloud SQL e Azure Backup per creare istantanee continue del vostro database. Se qualcosa si rompe, potete tornare immediatamente a una versione stabile con tempi di inattività minimi.
Storage geo-ridondante. Un solo backup non è sufficiente. I nostri esperti distribuiscono le copie in diversi centri dati, in modo che anche se uno di essi si blocca o viene colpito da un attacco informatico, i vostri dati siano sempre al sicuro e accessibili.
Backup incrementali e ripristino point-in-time. Invece di eseguire un backup enorme che richiede anni, utilizziamo backup intelligenti che catturano solo le modifiche recenti. Inoltre, grazie al ripristino point-in-time, siamo in grado di riavvolgere il vostro database a qualsiasi momento prima di un problema, salvandovi da cancellazioni accidentali o corruzione dei dati.
Ripristino in caso di catastrofe. Un solido piano di disaster recovery evita che i piccoli problemi si trasformino in vere e proprie crisi. Se qualcosa si guasta, i sistemi di failover automatici passano a un backup, in modo che l'azienda continui a funzionare senza intoppi.

Fase 6: ottimizzazione iterativa e scalatura

La migrazione da monoliti a microservizi non è solo un aggiornamento una tantum, ma richiede una cura continua per funzionare al meglio. Noi siamo qui per il lungo periodo, per garantire che la vostra configurazione rimanga agile, che si scalino senza problemi e che gestiscano anche i carichi più difficili.

Messa a punto delle prestazioni

Il nostro team tiene d'occhio ogni microservizio, modificando il codice, ottimizzando le query del database e ottimizzando il modo in cui i servizi comunicano per far sì che tutto funzioni velocemente.

Scalatura intelligente

Analizzando il traffico in tempo reale e i modelli di carico, i nostri specialisti regolano dinamicamente le risorse, assicurando che i servizi ad alta richiesta ricevano la spinta di cui hanno bisogno, senza eccedere nei costi.

Miglioramento continuo

Il vostro sistema deve crescere insieme alla vostra azienda. Il nostro team tiene traccia delle prestazioni in tempo reale, ascolta i feedback e apporta modifiche intelligenti per mantenere la vostra architettura sicura, efficiente e a prova di bomba.

Documentazione cristallina

Mentre perfezioniamo ed espandiamo i vostri microservizi, manteniamo tutto ben documentato. In questo modo, gli aggiornamenti e le migrazioni future non avranno problemi e il vostro team saprà esattamente cosa sta succedendo.

Proteggete la vostra applicazione aziendale con una migrazione intelligente dei microservizi.

Modernizzate le vostre applicazioni aziendali con le soluzioni Innowise

La migrazione da monolitico a microservizi è una mossa strategica per migliorare agilità, scalabilità e resilienza. Ma se ci si butta senza un piano sensato, si rischiano tempi di inattività, flussi di lavoro interrotti e costi alle stelle. Una migrazione intelligente richiede di definire i confini dei servizi, di gestire correttamente i dati e di seguire le best practice per la sicurezza e l'implementazione.

Innowise aiuta le aziende a compiere questo passaggio con fiducia. Con oltre 18 anni di esperienza in modernizzazione del software e sviluppo, ci occupiamo di tutto, dalla valutazione della vostra configurazione alla progettazione di una solida strategia di migrazione, fino alla costruzione di microservizi scalabili e al miglioramento delle prestazioni. I nostri architetti, ingegneri DevOps e sviluppatori utilizzano metodi collaudati per ridurre i rischi e massimizzare l'impatto, garantendo che i sistemi della vostra applicazione scalino e si evolvano insieme alla vostra azienda.

Michael Labutin

Responsabile soluzioni ERP

Michael conosce l'ERP dentro e fuori, dalla scelta del sistema giusto alla comprensione del suo funzionamento con il resto dello stack tecnologico. È la persona a cui ci si rivolge quando l'ERP deve risolvere problemi operativi reali, non crearne di nuovi.

Indice dei contenuti

Contattateci

Prenota una chiamata oppure compilate il modulo sottostante e sarete ricontattati una volta elaborata la vostra richiesta.

Nome

Azienda

Telefono

Messaggio

Inviaci un messaggio vocale

Allegare i documenti

Caricare il file

È possibile allegare 1 file di dimensioni massime di 2 MB. Formati di file validi: pdf, jpg, jpeg, png.

Facendo clic su Invia, l'utente acconsente al trattamento dei propri dati personali da parte di Innowise in base alla nostra Informativa sulla privacy per fornirvi informazioni pertinenti. Inviando il vostro numero di telefono, accettate che possiamo contattarvi tramite chiamate vocali, SMS e applicazioni di messaggistica. Potrebbero essere applicate tariffe per chiamate, messaggi e dati.