Il tuo agente funziona. I lead vengono qualificati, i ticket smistati, le fatture scorrono senza intoppi. Il builder no-code o il workflow n8n che hai messo in piedi tre mesi fa ha dimostrato il concetto — e ora comincia a mostrare le prime crepe.
I tempi di risposta si sono allungati. Un aggiornamento di un’API di terze parti ha rotto due flussi lo scorso martedì, e il tuo team ha passato mezza giornata a correggere manualmente le configurazioni dei nodi. I rate limit della piattaforma sono diventati un vero collo di bottiglia nelle ore di punta, e la funzionalità che ti serve adesso — interrogare un database interno proprietario, concatenare più step decisionali con memoria — si trova appena fuori da quello che il builder UI riesce a esprimere in modo pulito.
Questo è il momento della migrazione. Decidere se e come migrare dalla tua piattaforma no-code di agenti AI a un’architettura custom è una scelta consequenziale. Fatta bene, conserva tutto quello che hai dimostrato e aggiunge tutto quello che ti serve. Fatta male, si trasforma in una riscrittura che costa il doppio del tempo e brucia mesi di apprendimento iterativo.
I Segnali che Giustificano la Migrazione (Non Solo la Tentano)
Voler avere più controllo non è una ragione sufficiente per ricostruire tutto. Il codice custom ha costi reali: sviluppo iniziale più lungo, maggiore ownership dell’infrastruttura e nessun vendor a cui rivolgersi quando qualcosa si rompe. Quindi, prima di migrare, verifica se stai davvero toccando i limiti strutturali — o se la piattaforma ha ancora margine.
Segnali strutturali che meritano attenzione:
- Profondità di integrazione. Il tuo workflow deve leggere o scrivere su sistemi interni (ERP, database proprietari, API legacy) con cui la piattaforma non riesce ad autenticarsi in modo pulito, o per cui stai lavorando intorno ai limiti con passaggi intermedi fragili.
- Volume e affidabilità. L’agente gestisce abbastanza transazioni da far sì che i rate limit della piattaforma o gli SLA di infrastruttura condivisa degradino le prestazioni in modo significativo. Se un backup della coda durante un lunedì mattina affollato ti costa entrate reali, il problema è strutturale, non incidentale.
- Complessità della logica. Il workflow che ti serve prevede logica condizionale ramificata, ragionamento multi-step con stato condiviso, o memoria tra sessioni — e esprimerlo in modo pulito nella piattaforma non è possibile o richiede workaround che i futuri manutentori non capiranno. I builder puramente no-code (Zapier e strumenti simili) hanno i vincoli più stretti; le piattaforme low-code come n8n hanno aggiunto memoria nativa e orchestrazione stateful, ma anche lì la logica multi-agent complessa spesso supera quello che l’editor visuale riesce a esprimere chiaramente.
- Residenza dei dati o compliance. I tuoi requisiti legali o di protezione dei dati (nLPD, GDPR) limitano i trasferimenti di dati transfrontalieri in modi che potrebbero rendere certe piattaforme cloud non conformi — o che, in pratica, richiedono che i dati rimangano in una giurisdizione specifica. Regole settoriali come le linee guida FINMA o la normativa sanitaria possono imporre requisiti di localizzazione più severi rispetto a queste leggi di base.
- Costi a scala. I prezzi della piattaforma che funzionavano a 500 esecuzioni mensili dell’agente appaiono diversi a 50.000. Se i costi per task si accumulano più velocemente del valore che generano, la matematica del TCO è cambiata.
Nessuno di questi segnali, da solo, è una crisi. Due o tre insieme sono un campanello d’allarme su cui vale la pena agire.
Per un’analisi più approfondita di ciò che guida il calcolo build-vs-buy in primo luogo, il framework Build vs Buy per gli agenti AI copre la decisione iniziale in dettaglio. Questo articolo parte dal momento in cui quella decisione pende verso il custom.
Cosa Conservare, Cosa Ricostruire
L’istinto quando si migra è quello di ripartire da zero — una codebase pulita, un’architettura corretta, nessuno dei workaround disordinati. Resisti. Il tuo prototipo esistente contiene qualcosa di prezioso: un modello validato del workflow reale, comprensivi di tutti i casi limite che la realtà ti ha lanciato contro.
Cosa portare avanti:
- La business logic — le regole condizionali, le soglie di escalation e le decisioni di routing che il tuo team ha affinato attraverso l’iterazione. Documenta ogni ramo non ovvio prima di toccare il codice.
- Il layer dei prompt — se hai ottimizzato i system prompt e gli esempi few-shot per il tuo dominio specifico, sono risultati conquistati con fatica. Migrarli con cura e testa gli output rispetto alla tua baseline prima di considerare definitiva qualsiasi versione.
- La tassonomia dei fallimenti — ogni volta che il prototipo si è comportato male e qualcuno se ne è accorto, hai imparato qualcosa. La tua checklist di QA per la build custom dovrebbe essere costruita direttamente da quegli incidenti.
Cosa tipicamente va ricostruito correttamente:
- Autenticazione e gestione dei secret — le piattaforme no-code — in particolare le configurazioni self-hosted — spesso archiviano le credenziali in modi che potrebbero non soddisfare i tuoi standard di sicurezza specifici per la produzione. Ricostruisci questo aspetto a partire dal secret store della tua infrastruttura fin dall’inizio.
- Gestione degli errori e retry — i builder di piattaforme astraggono i modi in cui le cose vanno storte. Il codice custom ti costringe ad essere esplicito su cosa succede quando una chiamata API va in timeout, un modello restituisce una risposta malformata o una coda si intasa. Quella esplicitezza è un vantaggio una volta che ce l’hai.
- Osservabilità — probabilmente hai una logging minimale dal prototipo. Il codice custom significa che puoi strumentare esattamente ciò che conta: latenza per step, consumo di token per esecuzione, tassi di errore per categoria. Questo è il punto in cui i team di migrazione più spesso sotto-investono, e quello di cui più spesso si pentono.
Una Migrazione a Stadi che Non Blocca la Produzione
La strategia di migrazione più rischiosa è quella in cui porti tutto offline e ricostruisci in parallelo per due mesi, poi fai un unico cutover. Evitala. Un approccio a stadi richiede più tempo per la pianificazione, ma quasi sempre consegna risultati più veloci con un rischio inferiore.
Una sequenza di migrazione che funziona:
-
Congela il prototipo. Smetti di aggiungere funzionalità alla versione sulla piattaforma. Ora è un’implementazione di riferimento, non un prodotto. È più facile a dirsi che a farsi — gli stakeholder continueranno a richiedere miglioramenti — ma lo scope creep su un sistema che stai sostituendo moltiplica il costo della migrazione.
-
Estrai e documenta la logica canonica. Prima di scrivere una riga di codice custom, scrivi una specifica di ciò che l’agente dovrebbe fare: input, rami decisionali, output, condizioni di errore. Trattala come la source of truth su cui entrambe le versioni dovrebbero concordare.
-
Ricostruisci prima l’infrastruttura core, poi la logica. Configura l’ambiente custom — hosting, CI/CD, logging, secret — prima di portare qualsiasi logica di workflow. Migrare la logica su un’infrastruttura instabile produce bug sottili difficili da tracciare.
-
Esegui in shadow la versione custom. Instrada il traffico di produzione reale su entrambi i sistemi simultaneamente, con la versione sulla piattaforma che gestisce le risposte effettive e la versione custom che gira in silenzio. Confronta gli output. Quando i tassi di accordo sono alti e il tasso di fallimento della tua versione custom è accettabile, sei pronto a fare lo switch.
-
Spostamento graduale del traffico. Inizia inviando il 5–10% del traffico alla versione custom mentre la piattaforma gestisce il resto. Monitora le regressioni nelle tue metriche chiave per almeno un ciclo di lavoro completo prima di aumentare la quota. Un picco di errori alle 2 di notte di un mercoledì potrebbe non emergere finché non sei in produzione da una settimana.
-
Decommissiona deliberatamente. Mantieni la versione sulla piattaforma in modalità sola lettura o standby per 30 giorni dopo il cutover completo. È un’assicurazione economica contro i casi limite che emergono solo in scenari a bassa frequenza.
Il Cambiamento Operativo che Nessuno Pianifica
Quando migri dalla piattaforma no-code di agenti AI al codice custom, non stai solo cambiando tecnologia — stai cambiando chi ha la responsabilità operativa.
Su una piattaforma, il vendor gestisce l’affidabilità dell’infrastruttura, gli aggiornamenti di versione per i connettori LLM sottostanti e la maggior parte dei patch di sicurezza. Sul codice custom, tutto questo ricade sul tuo team o sul tuo partner di sviluppo.
È gestibile, ma deve essere esplicito. Prima di migrare, rispondi a queste domande:
- Chi monitora l’agente in produzione? Quali sono le soglie di alerting?
- Qual è il processo di incident response quando l’agente inizia a comportarsi male su scala?
- Chi gestisce il rapporto con il provider del modello, e come viene assorbita una modifica all’API del modello?
I team che saltano queste conversazioni spesso se ne accorgono nel peggior momento possibile — durante un incidente in produzione il venerdì pomeriggio.
L’articolo Gestire gli agenti AI in produzione copre il playbook operativo in dettaglio. Vale la pena leggerlo prima di completare il piano di migrazione, non dopo.
Quanto Tempo Richiede Davvero?
Dipende dalla complessità dell’agente e da quanto bene è documentato il prototipo. Per un workflow a singolo agente di complessità moderata — un agente di lead qualification che gira su un CRM, ad esempio — una migrazione a stadi richiede tipicamente da quattro a otto settimane, incluse shadow-run e spostamento del traffico.
Quella tempistica si allunga se il prototipo ha casi limite non documentati, se le integrazioni custom richiedono di negoziare l’accesso API con i proprietari dei sistemi interni, o se la revisione di compliance per il nuovo ambiente di hosting richiede più tempo del previsto.
Saltare la fase di shadow-run per comprimere il calendario è un errore comune. Due settimane di operazione parallela costano poco rispetto a un incidente in produzione che nessuno ha colto in fase di test.
Il Lock-In della Piattaforma Durante la Migrazione
La finestra di migrazione è il momento in cui sei più esposto al lock-in della piattaforma. Dipendi dalla piattaforma per il traffico in produzione mentre la versione custom è in costruzione. Se il vendor cambia i prezzi, limita l’accesso API o subisce un’interruzione in quella finestra, le tue opzioni sono limitate.
Mappa esattamente da cosa dipendi nella piattaforma — e quali dipendenze sono facili da replicare rispetto a quelle difficili — prima di iniziare. L’articolo AI Agent Platform Lock-In mappa in dettaglio le specifiche categorie di rischio.
Quando la Migrazione Non È la Risposta Giusta
La migrazione non è sempre la scelta giusta, anche quando stai incontrando attrito. Due scenari in cui rimanere sulla piattaforma (o passare a una diversa) ha più senso che andare custom:
Il workflow è genuinamente semplice. Se il tuo agente fa una cosa sola, in modo affidabile, e la piattaforma la gestisce senza limitazioni significative, l’overhead operativo del codice custom non è giustificato. Le piattaforme guadagnano il loro costo a complessità bassa o media.
Il business case non si è stabilizzato. Se il workflow sta ancora cambiando significativamente ogni mese — input diversi, logica decisionale diversa, output diversi — il costo di mantenere una codebase custom mentre i requisiti cambiano è alto. Prima dimostra la stabilità sulla piattaforma. L’articolo Quando i Builder No-Code di Agenti AI Toccano il Soffitto offre un framework utile per distinguere “abbiamo raggiunto il limite” da “non abbiamo ancora costruito il workflow giusto”.
Migrare con un Partner o In-House
Una migrazione di questo tipo è realizzabile in-house se hai ingegneri con esperienza in AI/ML in produzione e disponibilità di banda. La maggior parte delle PMI non ha entrambe le cose allo stesso tempo.
Lavorare con un partner di sviluppo ha un vantaggio specifico in questa fase: un team che ha già migrato agenti dalle piattaforme al codice custom ha già incontrato la maggior parte dei failure mode — e ha i template, gli strumenti di test e i runbook operativi già costruiti. Quella conoscenza istituzionale comprime una migrazione di 12 settimane in 6.
In Orange ITS, abbiamo strutturato lo sviluppo di agenti AI custom esattamente attorno a questo tipo di engagement di migrazione: partendo dal tuo prototipo esistente, estraendo ciò che funziona, ricostruendo ciò che non funziona e consegnando un sistema in produzione con piena osservabilità e un handover operativo che il tuo team può gestire autonomamente.
Pronto a Pianificare la Tua Migrazione?
Se la tua piattaforma di agenti sta mostrando le crepe descritte sopra — e vuoi una valutazione onesta di cosa comporterebbe una migrazione per il tuo setup specifico — una chiamata di 30 minuti con il nostro team è il punto di partenza giusto.
Analizzeremo il tuo workflow attuale, identificheremo i segnali strutturali più rilevanti nel tuo contesto e ti daremo una visione realistica di se la migrazione ha senso ora, più avanti o per niente.
Prenota una chiamata con Orange ITS — niente slide, niente pitch commerciale, solo una conversazione tecnica sul tuo sistema reale.