Molte guide affermano che la migrazione di un help desk richiede dalle 4 alle 12 settimane. Questo intervallo si riferisce a un progetto pianificato e testato manualmente, con il trasferimento programmato da zero. Con uno strumento di migrazione collaudato, la maggior parte di queste settimane non si verifica mai: la mappatura richiede pochi minuti tramite una procedura guidata, l'esecuzione del test richiede pochi minuti e il trasferimento viene eseguito in background mentre il team continua a lavorare.
Il vero fattore determinante sono le piattaforme. Zendesk consente 200 richieste API al minuto con il piano Team e 2.500 con il piano Enterprise Plus (Zendesk Documentazione per sviluppatori). Halo limita l'utilizzo delle API a 300 chiamate ogni cinque minuti (HaloPolitica di utilizzo equo). Dal 2 marzo 2026, Atlassian applica un sistema di misurazione Jira Cloud basato su una quota oraria a punti (Atlassian Developer). Di seguito sono riportati i tempi tipici per tipo di progetto, volume di dati e piattaforma, oltre alle fasi che compongono un progetto di migrazione.
Quanto tempo richiede un progetto di migrazione dell'help desk, dall'inizio alla fine?
Il trasferimento dei dati è solo una fase. La maggior parte del progetto consiste nella preparazione e nella verifica, quindi è fondamentale pianificare l'intera tempistica, non solo l'esecuzione.
Preparazione Help Desk Migration : 10 passaggi prima del lancio
Iniziate definendo gli obiettivi del progetto e verificando i dati esistenti, quindi pulite i dati, configurate la piattaforma di destinazione e testate la mappatura dei campi; ogni passaggio contribuisce a prevenire ritardi e problemi relativi ai dati. Ecco una panoramica delle principali fasi di migrazione e delle relative tempistiche tipiche.
| Fase | Cosa fare | Tempo tipico |
|---|---|---|
| 1. Definire l'ambito e gli obiettivi | Concordate i motivi del trasferimento, la piattaforma di destinazione e la data di messa in produzione | 1-2 giorni |
| 2. Allineare il team | Nomina un responsabile del progetto, fornisci istruzioni agli agenti e ai manager e concorda una finestra temporale per il passaggio al nuovo sistema | 1–3 giorni |
| 3. Verifica i tuoi dati | Elenca ciò che possiedi: biglietti, contatti, aziende, allegati, campi personalizzati, macro | 2–5 giorni |
| 4. Decidi cosa migrare | Contrassegna i dati come da spostare, da spostare in seguito o da archiviare. I ticket chiusi più vecchi spesso possono essere lasciati fuori in sicurezza | 1-2 giorni |
| 5. Pulire i dati | Unisci i duplicati, chiudi i ticket obsoleti, rimuovi i file inutili | 2–7 giorni |
| 6. Preparare l'obiettivo | Configura campi personalizzati, agenti e automazioni in modo che i record importati abbiano un posto dove essere inseriti | 3–10 giorni |
| 7. Eseguire una migrazione di prova | Eseguire un test su un campione, verificare la mappatura dei campi e gli allegati e correggere eventuali problemi | 1–3 giorni |
| 8. Migrazione completa | Trasferimento di tutti i record (da poche ore a diversi giorni, a seconda del volume e dei limiti dell'API) | 1–5 giorni |
| 9. Passaggio | Sposta i record creati dall'esecuzione completa e cambia agente | 1 giorno |
| 10. Verifica e supporto | Confronta i conteggi dei record, verifica a campione i dati e forma gli agenti | 1-2 settimane |
In generale: la maggior parte dei progetti di migrazione completi richiede dalle 2 alle 6 settimane, e il trasferimento dei dati spesso dura meno di una settimana. Le fasi dalla 3 alla 6 possono sovrapporsi, quindi iniziare la preparazione in anticipo è il modo migliore per abbreviare il progetto.
Il processo di migrazione: tempistiche di migrazione stimate in base alle dimensioni e alla complessità del progetto
La tabella seguente riassume i tempi di ogni fase di un progetto per tre scenari comuni. I tempi di trasferimento provengono dai nostri registri. Le altre fasi rappresentano intervalli di pianificazione basati sulle durate delle singole fasi descritte più avanti in questo articolo.
| Scenario | Configurazione e dimostrazione | Correzioni di test e mappatura | Migrazione completa (trasferimento) | Delta e passaggio | Totale tipico |
|---|---|---|---|---|---|
| Configurazione standard di piccole dimensioni: meno di 10.000 record, pochi campi personalizzati. | 15–30 min | 1–2 ore | ~35 minuti (9 su 10 entro ~4,5 ore) | 1–2 ore | Circa 1 giorno |
| Di medie dimensioni con campi personalizzati: da 10.000 a 100.000 record, diverse repliche della demo. | 1–2 ore | 1–3 giorni | ~4 ore (9 su 10 entro ~1 giorno) | 2–4 ore | 2–5 giorni |
| Azienda o fusione di più help desk: oltre 1 milione di record, oggetti personalizzati, target a basso limite | 1-2 giorni di pianificazione | 3–7 giorni | Circa 2 giorni (9 su 10 entro circa 8,5 giorni) | mezza giornata | 2-6 settimane |
Nella maggior parte dei casi, un progetto di grandi dimensioni richiede tempo per la revisione e le decisioni, non per l'utilizzo effettivo della macchina. Ecco perché i maggiori risparmi si ottengono testando precocemente e mantenendo l'ambito del progetto circoscritto. I suggerimenti per velocizzare il progetto che seguono riguardano entrambi gli aspetti.
Tempi tipici di migrazione dei dati in base al volume dei dati
La tabella seguente mostra la durata del trasferimento dati nelle esecuzioni Help Desk Migration osservate, raggruppate in base al numero di record trasferiti. Le colonne indicano il numero di esecuzioni, l'intervallo coperto dalla metà centrale delle esecuzioni, la mediana e il tempo entro il quale 9 esecuzioni su 10 sono state completate.
| Volume dei dati (record) | Corse | Intervallo tipico (50% centrale) | Mediano | 9 su 10 finiscono entro |
|---|---|---|---|---|
| Piccolo: meno di 10.000 | 496 | 15 minuti – 1,5 ore | ~35 minuti | ~5 ore |
| Medio: 10.000 – 100.000 | 572 | 1,5 h – 11 h | ~4 ore | ~1 giorno |
| Grande: da 100.000 a 1 milione | 457 | 5 ore – 1 giorno | ~12 ore | ~2 giorni |
| Molto grande: oltre 1 milione | 263 | 21 ore – 5 giorni | ~46 ore | ~8,5 giorni |
Si tratta di durate osservate durante migrazioni reali, non calcolate con una formula. Coprono i percorsi da API ad API, indipendentemente dal piano tariffario utilizzato da ciascun cliente. Le origini dati CSV, databasee caselle di posta elettronica hanno velocità diverse e sono escluse. Lo stesso trasferimento di 30.000 record può richiedere un'ora o quasi un giorno, a seconda delle piattaforme descritte nella sezione successiva.
Tempo di migrazione per piattaforma (limiti API)
Il limite API di ciascuna piattaforma determina la velocità con cui i record possono essere letti (esportati) o scritti (importati). La tabella elenca 13 piattaforme con i relativi limiti API documentati per i livelli standard e superiori, oltre ai tempi di esportazione e importazione osservati per migrazioni di circa 100.000 record.
| Piattaforma | Limite API (standard / livello superiore) | Esportazione, circa 100.000 record | Importazione, circa 100.000 record | Note |
|---|---|---|---|---|
| Zendesk | 200 / 2.500 giri/minuto | 7 ore | 24 ore | Obiettivo comune più veloce |
| Freshdesk | 100 / 700 giri/minuto | 6,5 ore | 23 ore | Veloce in entrambe le direzioni |
| Freshservice | 100 / 500 giri/minuto | 17 h | 23 ore | Lenta come fonte; la velocità di esportazione aumenta a malapena con il volume |
| Jira Service Management | basato su punti (quota oraria) | 25 ore | 25 ore | L'obiettivo comune più lento in assoluto: ~1.250 record/h per qualsiasi dimensione |
| Intercom | 10.000 giri/minuto per applicazione; velocità superiore su richiesta | 5 ore | 5 ore | Veloce in entrambe le direzioni; i limiti vengono conteggiati in intervalli di 10 secondi |
| HubSpot Service Hub | 600 / 1.140 giri/minuto | 1 ora | 6 ore | Esportazione molto veloce |
| Salesforce Service Cloud | giornaliero: circa 100.000 richieste al giorno | 30 ore | 70 ore | Limite giornaliero; rallenta bruscamente oltre 1 milione di record (vedi sotto) |
| Zoho Desk | crediti giornalieri | 2,5 ore | 13 ore | Crediti giornalieri; ampia diffusione |
| ServiceNow | configurabile dall'amministratore | 2 ore | 19 h | Dipende dai limiti dell'istanza stessa |
| Halo | 60 giri al minuto (300 giri/minuto / 5 minuti) | 4,5 ore | 12 ore | Limite minimo documentato nella tabella |
| Pylon | non documentato | n/d (solo target) | 23 ore | Conferma il limite con Pylon |
| Front | 50 / 200 giri/minuto | 32 ore | 20 ore | Partite a basso limite, tempi lenti |
| Gorgias | 120 giri/minuto (40 richiesti / 20 secondi) | n / a | 19 h | bersaglio lento |
I limiti delle API sono stati verificati rispetto alla documentazione per sviluppatori di ciascun fornitore nel novembre 2026. I fornitori modificano spesso questi limiti e la maggior parte vende piani tariffari superiori o componenti aggiuntivi, quindi controlla il tuo piano prima di pianificare una migrazione. Per ottenere una cifra esatta per i tuoi dati,
Help Desk Migration di Relokia ha completato la migrazione Freshservice di Vanta a Jira Service Management in soli 21 giorni, trasferendo oltre 128.000 ticket e preservando al contempo il contesto storico, gli allegati e l'integrità del registro delle attività. Ecco come ci siamo riusciti:
Vanta: oltre 128.000 ticket migrati in soli 21 giorni
Help Desk Migration di Relokia ha completato la migrazione Freshservice di Vanta a Jira Service Management in soli 21 giorni, trasferendo oltre 128.000 ticket e preservando al contempo il contesto storico, gli allegati e l'integrità del registro delle attività. Ecco come ci siamo riusciti:
Dall'avvio del progetto al suo completamento con successo in soli 21 giorni, Vanta ha migrato oltre 128.000 ticket, 512.000 commenti, 86.000 allegati e oltre 4.200 richiedenti e agenti da Freshservice a Jira Service Management, preservando il contesto storico e l'integrità completa della traccia di controllo.
Il rispetto delle tempistiche stringenti è stato possibile grazie a opzioni di migrazione automatizzate, configurazioni personalizzate e un approccio iterativo. Le immagini incorporate sono state trasferite come allegati dei ticket, mentre i tag personalizzati basati sui campi Gruppo hanno mantenuto i record migrati organizzati e facilmente identificabili.
Il pacchetto di supporto Premium includeva la migrazione successiva, dando a Vanta il tempo di applicare le personalizzazioni, convalidare i risultati e completare il trasferimento finale senza estendere la tempistica del progetto di 21 giorni.
Quali fattori influenzano la durata di una migrazione dati?
I limiti delle API definiscono il tetto massimo. Altri quattro fattori determinano quanto una migrazione si avvicina a tale limite e quanto tempo richiede il progetto.
- Numero di record. Ogni ticket contiene i relativi commenti; un ticket può includere centinaia o migliaia di commenti, e ogni commento fa parte del trasferimento. Il volume definisce il valore di riferimento.
- Allegati. Ogni file viene caricato separatamente, quindi il numero di allegati può essere più importante del numero di ticket. Un account di grandi dimensioni con pochi allegati può completare la migrazione più velocemente rispetto a un account più piccolo pieno di screenshot e PDF. Il numero di file è inoltre difficile da stimare in anticipo, il che rende le migrazioni con molti allegati le più difficili da prevedere.
- Il piano tariffario prevede livelli di servizio per entrambe le parti. La maggior parte dei fornitori adegua i limiti delle API al piano: maggiore è il piano, maggiore è il numero di chiamate API consentite. Ad esempio, Freshservice offre un numero di richieste che va da 100 al minuto con il piano Starter a 500 con il piano Enterprise, con pacchetti aggiuntivi che arrivano fino a 2.000 (Freshservice documentazione API).
- Unire più help desk in uno solo. Il consolidamento non è una singola migrazione, ma diverse migrazioni verso la stessa destinazione. Ogni origine viene eseguita come una migrazione a sé stante e ogni esecuzione successiva alla prima raggiunge una destinazione che contiene già i dati. I nostri ingegneri tecnici possono valutare i requisiti di migrazione e determinare se un approccio di migrazione parallelo (multithread) o sequenziale garantisca i risultati più efficienti in termini di tempo. Mayvik ha migrato i dati da Freshdesk, Zendesk, Desk.com e Groove a Help Scout in questo modo.
La nostra guida alle sfide relative alla migrazione dei dati dell'assistenza clienti elenca tutto ciò che può rallentare un progetto, insieme alle relative soluzioni.
Cronologia della migrazione dei dati, passo dopo passo
Il tempo di trasferimento è solo una parte di un progetto di migrazione. La cronologia riportata di seguito illustra l'intero processo e la durata media di ciascuna fase.
Passaggio 1: Mappa i tuoi dati ed esegui una migrazione di prova (15-30 minuti)
Ecco quindi le principali opzioni da considerare nella scelta di una modalità di trasferimento dati:
Una demo gratuita richiede in genere dai 15 ai 30 minuti. Nella procedura guidata di migrazione, si collegano le piattaforme di origine e di destinazione (è necessario l'accesso amministrativo a entrambe). Successivamente, si selezionano i record da trasferire, si associano agenti e gruppi e si mappano i campi relativi a organizzazione, cliente, ticket e articolo. I passaggi di mappatura esatti variano a seconda della coppia di piattaforme da migrare. È inoltre possibile scegliere opzioni automatizzate predefinite per personalizzare l'importazione.
La demo richiede più tempo se la configurazione preliminare alla migrazione non è stata completata. Prima di iniziare, raccogli le credenziali di accesso per entrambe le piattaforme, crea i profili e i gruppi degli agenti corrispondenti nella piattaforma di destinazione e configura i campi personalizzati dei ticket necessari. In presenza di molti campi personalizzati, è consigliabile prevedere più cicli di mappatura anziché uno solo.
Passaggio 2: Esaminare i risultati della demo (da pochi minuti a 2 ore)
Esaminare una demo richiede un paio di minuti. Testare i risultati di una migrazione dati completa richiede almeno 1-2 ore. La demo rispecchia la migrazione completa, quindi se qualcosa non viene migrato nella demo, non verrà migrato nemmeno nella migrazione completa. Esegui nuovamente la demo tutte le volte necessarie per ottimizzare la mappatura.
Verifica che:
- I commenti hanno gli autori corretti
- I biglietti vengono assegnati agli agenti corretti
- I campi personalizzati contengono i valori corretti
- aziende e clienti sono collegati
- Gli allegati arrivano con i loro nomi
- Gli articoli sono collocati nelle sezioni e categorie corrette
- Condividere l'accesso alla migrazione permette al tuo team di contribuire alla convalida.
Condividere l'accesso alla migrazione permette al tuo team di contribuire alla convalida.
Fase 3: Preparare il team e l'help desk di destinazione (meno di 2 ore)
Iniziate l'inserimento degli agenti il prima possibile. La durata dipende dal numero di agenti e dalla piattaforma di destinazione. La fase di transizione in sé è breve:
- Disattiva le automazioni sul dispositivo di destinazione oppure richiedi un tag: 5-30 minuti
- Il team di supporto smette di lavorare sulla sorgente: 5 minuti
- Disattivare i canali di comunicazione sulla fonte: 5–15 minuti
- Attivare i canali di comunicazione con il target: da 15 minuti a 1 ora
Passaggio 4: Eseguire la migrazione completa (da ore a giorni)
Questo è il tempo di trasferimento mostrato nelle tabelle relative al volume e alla piattaforma. Il tuo team può continuare a lavorare nell'help desk di origine mentre il processo è in corso. Puoi monitorare l'avanzamento nella tabella dei record, che mostra i record recuperati e trasferiti, e riceverai un'e-mail al termine della migrazione. Se l'esecuzione deve avvenire al di fuori dell'orario lavorativo, la migrazione a intervalli ti consente di mettere in pausa e riprendere la migrazione completa in coordinamento con il nostro team.
Passaggio 5: Eseguire una migrazione delta per i nuovi record
I ticket creati o aggiornati nell'origine durante la migrazione completa possono essere spostati in un passaggio successivo con la migrazione Delta, disponibile nel piano Premium. Convalida il risultato prima di passare agli agenti di destinazione.
8 modi per velocizzare la migrazione dei dati
Per velocizzare la migrazione di un help desk, ITSM o RMM, è possibile adottare diverse misure per ridurre i tempi di trasferimento dei dati, semplificare la preparazione ed evitare ritardi inutili. Dall'ottimizzazione dei limiti API e la pulizia dei dati di origine alla semplificazione della mappatura dei campi e all'utilizzo della migrazione parallela, l'approccio giusto può rendere l'intero progetto più rapido e prevedibile. Considera i seguenti metodi per accelerare la migrazione senza compromettere l'accuratezza dei dati o la continuità operativa.
- Richiedi al fornitore un aumento temporaneo del limite API. Intercom accetta richieste di aumento del limite, Freshdesk vende chiamate API aggiuntive e Zendesk offre un componente aggiuntivo High Volume API che porta i piani idonei a 2.500 richieste al minuto.
- Salta gli allegati. L'opzione "Salta gli allegati" sposta i record senza
i file. Escludi gli allegati da tutti i ticket o dai ticket aggiornati più di 6, 12 o 24 mesi fa. Riduci i tempi di migrazione e i costi di archiviazione trasferendo solo i file necessari al tuo team. Ideale per migrazioni di grandi dimensioni, file obsoleti e per evitare il superamento dello spazio di archiviazione disponibile. - Filtra i record vecchi o irrilevanti. Meno record significano meno chiamate API. Non è necessario migrare tutto sulla nuova piattaforma. Utilizza le opzioni di filtro nella procedura guidata di migrazione per selezionare i record da trasferire ed escludere i dati irrilevanti, come tutti i ticket o i ticket aggiornati più di sei mesi fa. Se i filtri standard non soddisfano le tue esigenze, puoi richiedere opzioni di filtro aggiuntive al nostro team tecnico. Ti aiuteranno a configurare filtri personalizzati in base all'ambito della migrazione, in modo da trasferire solo i dati necessari, ridurre le chiamate API e risparmiare tempo.
- Migrazione multithread con Help Desk Migration. Esegui la migrazione in parallelo. Il trasferimento asincrono multithread viene eseguito come thread paralleli, inviando molte richieste contemporaneamente anziché una alla volta, riducendo così i tempi di attesa delle risposte. Abbinalo a un limite API più elevato, poiché le richieste parallele vengono comunque conteggiate. È disponibile nei piani Premium ed Enterprise.
- Durante la migrazione, è consigliabile aggiornare il piano tariffario. Un piano superiore sulla piattaforma più lenta solitamente aumenta il limite API per tutta la durata della migrazione.
- Migra prima i record più recenti. Trasferisci prima i ticket più recenti in modo che il tuo team possa dare priorità ai problemi attivi dei clienti mentre i record più vecchi vengono migrati in background. Questa opzione è ideale per finestre di inattività limitate, supporto ininterrotto, budget ristretti e per testare i ticket attivi prima del passaggio definitivo. Disponibile solo per la migrazione completa.
- Utilizzate la migrazione Delta per il passaggio alla nuova piattaforma. Trasferite i ticket creati o aggiornati nella sorgente dopo la migrazione completa, assicurandovi che la nuova piattaforma disponga dei dati più recenti prima del lancio. Questo riduce al minimo i tempi di inattività e previene lacune nei dati. Disponibile con il piano Premium.
- Utilizza la migrazione a intervalli per adattarla all'orario di lavoro. Metti in pausa la migrazione completa durante le ore di punta e riprendila in seguito. Puoi mettere in pausa fino a cinque volte, per un massimo di cinque giorni ogni volta, in accordo con il nostro team.
Per le migrazioni complesse, i nostri Servizi di Migrazione Gestita offrono supporto specializzato in pianificazione, personalizzazioni, mappatura dei dati, limiti API e convalida, per garantire una transizione senza intoppi e con interruzioni minime.
Pandora: Migrazione aziendale completata in sole 4 settimane
In sole 4 settimane, senza interruzioni del servizio, Pandora ha completato una migrazione a livello aziendale da Zendesk a Salesforce Service Cloud, consolidando i dati dell'assistenza clienti di oltre 6.500 punti vendita e 37.000 dipendenti in tutto il mondo.
La migrazione ha trasferito l'intera cronologia dei ticket e dei clienti, le registrazioni delle chiamate, gli allegati, le note interne, le conversazioni collaterali e i flussi di lavoro aziendali, preservando al contempo le relazioni tra i dati.
Per rispettare le tempistiche del progetto, il team ha utilizzato un approccio iterativo con cinque migrazioni di prova per convalidare la mappatura dei campi e le configurazioni prima del trasferimento finale. I trigger del backend Salesforce sono stati temporaneamente disabilitati per evitare blocchi del sistema e garantire una transizione senza intoppi.
Migrazione manuale, automatizzata o gestita: un confronto delle tempistiche
Uno script creato da un team, uno strumento di migrazione self-service e un servizio di migrazione gestito si differenziano principalmente per il tempo impiegato prima e dopo il trasferimento, non durante il trasferimento stesso.
| Criterio | Manuale (script personalizzato) | Strumento automatizzato (self-service) per Help Desk Migration | Servizio di migrazione gestito dal team di supporto tecnico e assistenza Help Desk Migration |
|---|---|---|---|
| Tempo di preparazione | Da settimane a mesi di studio di entrambe le API | Bastano pochi minuti per connettersi e configurare la mappa tramite una procedura guidata | Il nostro team definisce l'ambito del progetto e mappa i dati insieme a te |
| Test | Costruito e replicato dal tuo team | Dimostrazione della migrazione su un esempio, da ripetere se necessario | Esecuzione di dimostrazioni e piano di validazione del progetto |
| Gestione dei limiti API | Il tuo codice deve limitare e riprovare | Integrato nello strumento | Predisposto, più richieste di limite del fornitore pianificate in anticipo |
| Campi personalizzati, filtri, unioni | Qualunque cosa costruisca la tua squadra | Mappatura standard e opzioni automatizzate, con possibilità di filtraggio. Richiedi filtri personalizzati o ulteriori personalizzazioni per la migrazione al nostro team tecnico, in modo da adattare il processo alle tue esigenze specifiche in termini di dati e progetto. | Filtraggio personalizzato, mappatura personalizzata, consolidamento da più fonti |
| Durata tipica del progetto | Da settimane a mesi | Da poche ore a qualche giorno | Da pochi giorni a qualche settimana, a seconda della portata |
| Costo | Tempo di ingegneria, spesso nascosto | Prezzi basati sul volume dei dischi e sulle opzioni, pacchetto di supporto (prezzi) | Preventivo calcolato in base al volume dei record, alle opzioni e al pacchetto di supporto (servizi di migrazione). |
Un servizio gestito non significa necessariamente codice personalizzato per ogni progetto. Il team di Help Desk Migrationutilizza lo stesso motore collaudato dello strumento self-service, quindi la velocità del trasferimento rimane invariata, ma la pianificazione, la mappatura e la convalida non sono più a carico del vostro team.
per vedere come si comportano i tuoi record sul tuo percorso, oppure parla con un esperto di un progetto aziendale o multi-sorgente.
FAQ
Dai nostri registri, le migrazioni di oltre 1 milione di record hanno richiesto in media circa 46 ore. La metà delle migrazioni si è conclusa in un periodo compreso tra 21 ore e 5 giorni, e 9 su 10 in circa 8,5 giorni. Un target con un limite di tempo ridotto, come Jira Service Management richiederebbe circa un mese, mentre un target con un limite giornaliero, come Salesforce Service Cloud, porterebbe la durata dell'operazione nella parte alta di questo intervallo. Aggiungendo da qualche giorno a una settimana per la mappatura e i test relativi al trasferimento, un progetto da 1 milione di ticket si completa solitamente in una o tre settimane, non in tre mesi.
Questi intervalli di tempo descrivono in genere l'intero progetto con un approccio manuale o personalizzato: settimane di pianificazione, una migrazione di prova con script, il trasferimento e settimane di controllo qualità. Con uno strumento di migrazione collaudato, la mappatura e il test richiedono da pochi minuti a qualche giorno, e il trasferimento stesso richiede solo poche ore per la maggior parte degli account. I progetti molto ampi o che coinvolgono più fonti richiedono comunque un'attenta pianificazione, ma una tempistica misurata in mesi di solito implica una notevole quantità di lavoro manuale.
Sì. Ogni allegato corrisponde a un caricamento separato, quindi un account pieno di file potrebbe richiedere più tempo rispetto a un account più grande con pochi file. Gli articoli della knowledge base sono generalmente pochi rispetto ai ticket, ma le immagini incorporate e la struttura degli articoli (sezioni e categorie) aumentano i tempi di mappatura e verifica. Se gli allegati rallentano il trasferimento, l'opzione "Salta allegati" sposta i record senza i file.
Per i dati dell'help desk in Salesforce Service Cloud (casi, contatti e articoli della knowledge base), ZendeskdaSalesforce le migrazioni Salesforceinizia a rallentare il processo: ZendeskdaSalesforce di queste dimensioni hanno richiesto in media 3,4 giorni. Questi dati non coprono una migrazione completa di Sales Cloud CRM. Consulta la nostra Salesforce Service Cloud sulla migrazione per i record supportati.
La migrazione parallela viene eseguita in più thread, inviando molte richieste contemporaneamente per ridurre i tempi di attesa delle risposte. È particolarmente utile per account di grandi dimensioni con molti tipi di record, e meno efficace se si è già raggiunto il limite API del fornitore; in tal caso, è consigliabile aumentare prima il limite. I record correlati, come i ticket e i relativi richiedenti, vengono comunque creati nell'ordine corretto e una migrazione di prova consente di verificare il risultato prima dell'esecuzione completa.
Sì. Gli agenti continuano a lavorare nell'help desk di origine mentre è in corso la migrazione completa, perché il trasferimento legge i dati tramite API senza bloccare l'account. Disattiva prima le automazioni nella destinazione, in modo che i ticket importati non inviino email ai clienti. La guida alla migrazione senza tempi di inattività descrive la sequenza di transizione.
I ticket creati o aggiornati nel sistema di origine dopo l'avvio della migrazione completa non vengono elaborati in quella fase. Una migrazione differenziale li sposta in una fase successiva, molto più breve, consentendo agli operatori di passare al sistema di destinazione con una cronologia completa. La migrazione differenziale è disponibile con il piano Premium. La checklist generale per la migrazione dei dati mostra dove si colloca la migrazione differenziale nel processo di transizione.
Sì, con la migrazione a intervalli. È possibile sospendere la migrazione completa fino a cinque volte, per un massimo di cinque giorni ogni volta, e riprenderla in coordinamento con il Help Desk Migration . Ad esempio, è possibile evitare di sovraccaricare le API durante le ore di punta dell'assistenza. La migrazione a intervalli non è la stessa cosa della migrazione incrementale, che sposta i record creati dopo l'esecuzione principale. Le istruzioni per la sospensione e la ripresa sono disponibili nella sezione di aiuto "Per iniziare".
Durante una migrazione di prova, la procedura guidata di migrazione mostra una barra di avanzamento con la percentuale di dati di esempio trasferiti. Durante la migrazione completa dei dati, una tabella dei record mostra quanti record sono stati recuperati e trasferiti. Riceverai un'e-mail al termine della migrazione di prova o completa.
Confronta la destinazione con la sorgente: conteggio dei record per tipo, autori dei commenti, assegnatari dei ticket, valori dei campi personalizzati, allegati e categorie di articoli. Controlla un campione di ticket vecchi, recenti e con molti allegati, quindi attiva trigger, automazioni e notifiche nella destinazione. Raccogli feedback dagli agenti durante i loro primi giorni nel nuovo help desk. La checklist post-migrazione elenca tutti i controlli.
Innanzitutto, controlla la tabella delle piattaforme: un'esecuzione lenta verso una destinazione con limiti bassi come Jira Service Management, Haloo Front è spesso normale. Se il conteggio dei record nella tabella di avanzamento non si è mosso per diverse ore, un limite giornaliero dell'API o un token scaduto potrebbero aver messo in pausa l'esecuzione. In tal caso, contatta il nostro team di supporto fornendo il tuo ID di migrazione in modo che possano controllare i log.
