Andare via da Salesforce: migrare senza ricostruire tutto

Andare via da Salesforce non è soltanto un progetto di esportazione e importazione dati. In un'organizzazione che usa Salesforce da anni, una parte importante del comportamento operativo può vivere in oggetti custom, Flow, Flow Orchestration, Apex, validation rule, permessi, integrazioni e interfacce.

Per questo la domanda corretta non è soltanto “dove spostiamo i record?”, ma quale parte dell'architettura Salesforce dobbiamo davvero ricostruire?

1. Separare il CRM dai processi custom

Il primo inventario dovrebbe distinguere dati e funzionalità CRM native da processi aziendali costruiti sulla piattaforma. Account, contatti, opportunità e attività possono avere una destinazione diversa da onboarding, ordini, approvazioni, pratiche o processi operativi custom.

Questa separazione evita di assumere che ogni oggetto custom debba diventare un oggetto equivalente nella piattaforma successiva.

2. Non migrare soltanto i dati: mappare il comportamento

Salesforce consente l'esportazione dei dati e mette a disposizione strumenti come Data Export e Data Loader. Ma i CSV non descrivono da soli il comportamento dell'applicazione. Per ogni area vanno censiti almeno:

• oggetti, campi e relazioni;
• Flow e orchestrazioni;
• Apex e altra logica custom;
• validation rule e obbligatorietà;
• permessi e ruoli;
• integrazioni e credenziali;
• schermate o esperienze guidate;
• processi in corso e relativo stato.

3. Decidere cosa sostituire, cosa mantenere e cosa eliminare

Una migrazione è anche un'occasione di decomposizione. Alcune capacità possono essere trasferite a un nuovo CRM; altre possono restare in sistemi già esistenti; altre ancora possono diventare processi indipendenti dal CRM.

Questo terzo caso è quello in cui una piattaforma process-centric come Flowvenue diventa rilevante: il processo possiede una propria istanza, uno stato, requisiti correnti, regole, azioni e integrazioni, invece di essere ricostruito come insieme di personalizzazioni intorno a record CRM.

4. Migrare da Salesforce verso Flowvenue non significa copiare Salesforce

Un approccio 1:1 — oggetto per oggetto, Flow per Flow, schermata per schermata — rischia di trasferire anche la complessità accumulata. Il percorso alternativo è partire dal processo:

1. descrivere l'obiettivo operativo;
2. identificare le entità persistenti necessarie;
3. definire fasi, azioni, decisioni e requisiti;
4. collegare i sistemi che devono rimanere system of record;
5. migrare soltanto i dati realmente necessari;
6. testare il processo end-to-end prima del cutover.

5. Ricreare il data model Salesforce con un solo click

Flowvenue dispone già di un connettore nativo Salesforce pensato per ridurre il lavoro iniziale di migrazione. Il data model Salesforce può essere ricreato in Flowvenue con un solo click, evitando di dover ridisegnare manualmente da zero oggetti e struttura dati.

Dopo la replica del modello, i dati possono essere sincronizzati tramite flussi batch. Questo permette di mantenere Salesforce operativo durante la transizione mentre Flowvenue utilizza un modello coerente per costruire i nuovi processi.

6. Configurare migrazione e processi in linguaggio naturale

Il passaggio successivo può essere richiesto conversando: ad esempio predisporre un batch di sincronizzazione, definire quali dati mantenere allineati o costruire un processo che utilizzi gli oggetti importati. La combinazione tra connettore nativo, replica del data model, batch e linguaggio naturale trasforma la migrazione da progetto puramente tecnico a percorso progressivo.

Il modello operativo diventa: connect → replicate → synchronize → build by conversation → decouple progressively.

5. Gestire le istanze già in corso

Uno dei punti più delicati è il lavoro aperto. Non basta sapere che esiste un record: occorre capire dove si trova nel processo, quali attività sono già state completate, quali dati mancano e quale azione deve avvenire dopo.

Per questo la migrazione di processi richiede una strategia diversa dalla sola data migration. In alcuni casi conviene completare le istanze aperte sul sistema precedente; in altri è possibile ricostruire uno stato iniziale equivalente nel nuovo runtime.

6. Salesforce può restare durante la transizione

Uscire da Salesforce non deve necessariamente essere un “big bang”. Flowvenue può governare nuovi processi mentre Salesforce continua temporaneamente a mantenere dati o processi legacy. Le integrazioni consentono di spostare progressivamente il centro operativo senza pretendere che tutto cambi nello stesso giorno.

7. Misurare il Time-to-Process, non solo il costo della licenza

Nel confronto tra destinazioni alternative, oltre a licenze e costi di migrazione, è utile misurare quanto tempo e quante competenze servono per trasformare un requisito in un processo funzionante. Questa è la metrica che Flowvenue definisce Time-to-Process.

Una piattaforma più economica può comunque richiedere molti componenti, sviluppatori o specialisti. Viceversa, una migrazione architetturale può avere senso se riduce il costo di ogni successiva modifica del processo.

Checklist per lasciare Salesforce

• inventario oggetti e volumi dati;
• mappa delle relazioni e degli identificativi;
• inventario Flow, Orchestration e Apex;
• integrazioni e sistemi esterni;
• utenti, ruoli e permessi;
• report e dipendenze operative;
• processi e istanze aperte;
• requisiti di storico, audit e retention;
• strategia di cutover e rollback;
• test end-to-end dei processi prioritari.

Conclusione

Lasciare Salesforce non dovrebbe significare ricostruire automaticamente Salesforce altrove. Prima si separano dati CRM, logica applicativa e processi operativi; poi si sceglie l'architettura più adatta a ciascuna parte. Per alcuni scenari la destinazione sarà un altro CRM. Per altri, il passaggio più importante sarà rendere i processi indipendenti dal CRM.