Migrazione dei dati per i fornitori di servizi gestiti: il tuo PSA, non quello dei tuoi clienti
Cercando "migrazione dati per fornitori di servizi gestiti" troverete un articolo dopo l'altro su come spostare le caselle di posta dei clienti in Microsoft 365.
Questa pagina illustra il tuo PSA, i tuoi ticket, il tuo service desk: il sistema su cui gestisci la tua attività. In qualità di MSP, questi dati appartengono a decine, a volte centinaia, di clienti contemporaneamente, pertanto l'isolamento per singolo cliente, la continuità della fatturazione e una transizione silenziosa sono fondamentali in questo contesto. Scopri come funziona la pianificazione della migrazione specifica per il settore e applicala alla migrazione di un PSA MSP, dove la posta in gioco è ancora più alta.
Parliamone e definiamo un piano.
Non è richiesta alcuna carta di credito Installazione rapida
Scelto da oltre 60.000 aziende
Tipologie di migrazione dati: cosa viene trasferito in una migrazione PSA
Il passaggio a PSA non è una semplice migrazione di ticket con passaggi aggiuntivi. Dietro le quinte, un singolo ticket si collega a bacheche, code, campi personalizzati, policy SLA e configurazioni, che devono essere mantenute anche dopo la migrazione. Ecco una panoramica più completa, partendo dai dati dell'help desk e seguendo l'ordine in cui la maggior parte degli MSP li elabora:
| Record stabilito | Cosa include | Cosa guardare in un film | nota di isolamento per ciascun cliente |
|---|---|---|---|
| Assistenza e ticket PSA | Casi, ticket, discussioni sui ticket, bacheche, code, stati, tag, campi personalizzati | Le strutture delle bacheche e delle code raramente corrispondono in modo identico tra le diverse piattaforme | I biglietti devono mantenere il corretto rapporto con l'azienda o il cliente |
| Inserimento delle ore lavorate e contratti | Registri orari, registri contrattuali, configurazioni, riferimenti di fatturazione | Lo stato di fatturazione in genere non viene trasferito insieme al record, vedi sotto | I termini del contratto rimangono specifici per un singolo cliente e non si applicano a clienti diversi |
| Base di conoscenza | Articoli, categorie, visibilità per cliente rispetto alla visibilità interna, allegati degli articoli | Le impostazioni di visibilità richiedono una decisione, non solo una regola di mappatura | Gli articoli condivisi richiedono una decisione esplicita su quali client possono accedervi |
| Dati del cliente e di contatto | Aziende, contatti, siti, gerarchia organizzativa, struttura degli agenti e dei gruppi | Questa è la spina dorsale da cui partono le chiavi della migrazione | Dove l'isolamento ha successo o fallisce per primo |
| File multimediali e allegati | Immagini incorporate, allegati, limiti di dimensione e conservazione | I limiti di dimensione del bersaglio possono essere più stretti di quelli della sorgente | Gli allegati ereditano l'isolamento dal ticket o dal record a cui appartengono |
| Cronologia email | Thread in entrata e in uscita collegati ai ticket, conservazione dell'intestazione | La conservazione dell'intestazione varia notevolmente a seconda della coppia di piattaforme | I thread rimangono isolati finché esiste il ticket principale |
| Registri delle chiamate e registrazioni | Registrazioni telefoniche e link di registrazione allegati ai biglietti | I link di registrazione a volte puntano a un sistema di terze parti che si muove separatamente | Stessa dipendenza degli allegati |
Si tratta di sette set di record, non uno solo. I ticket sono l'ancora: rappresentano la parte più consistente ed è facile confondere un cambio di PSA con una migrazione di ticket. Ma ognuno degli altri sei set di record ha un proprio isolamento per cliente da proteggere durante il trasferimento. Le registrazioni orarie e i contratti hanno un valore finanziario che i ticket non hanno. I dati del cliente sono la spina dorsale su cui si basa tutto il resto. Persino elementi comuni come allegati e registri delle chiamate ereditano il loro isolamento dal ticket o dal record a cui sono collegati. Nessuno di questi è facoltativo solo perché nessuno lo ha menzionato per primo.
Ciò che viene effettivamente trasferito dipende da ciò che la piattaforma di origine rilascerà e da ciò che la piattaforma di destinazione è in grado di intercettare. Considera questa tabella come un documento preliminare da valutare prima di impegnarti in una soluzione definitiva.
Piattaforme di migrazione supportate per aziende MSP
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
Verifica la presenza di errori di battitura nel nome o lasciaci un messaggio.
Perché l'isolamento per singolo cliente è il vero requisito, non il numero di ticket
L'isolamento non è una funzionalità che si può semplicemente attivare. Dipende da come i dati vengono mappati e verificati durante la migrazione. Questo è ciò che distingue la migrazione dell'help desk di un MSP da un progetto a tenant singolo: i dati appartengono a più clienti, quindi la mappatura e la convalida devono essere eseguite per ciascun cliente, non una sola volta per l'intero set di dati.
Questo singolo fattore allunga i tempi di un progetto più di quanto non faccia il volume dei record. Una migrazione che coinvolge 40 clienti con volumi di dati moderati può richiedere più tempo per la definizione dell'ambito e la convalida rispetto a una migrazione di un singolo cliente con molti più record. Ogni cliente necessita di una propria revisione e convalida della mappatura prima del passaggio alla nuova configurazione.
L'isolamento non è qualcosa che una piattaforma ti concede gratuitamente. Deriva da decisioni prese durante la fase di mappatura e viene confermato tramite validazione per ogni singolo cliente prima del passaggio al nuovo sistema, non è dato per scontato solo perché entrambe le piattaforme utilizzano la dicitura "multi-tenant" nelle loro pagine di marketing.
Come si presenta la mappatura intenzionale in Autotask PSA
Quindi, cosa significa concretamente "progettato intenzionalmente"? In Autotask PSA, ogni contatto deve essere collegato a un'azienda. Non ci sono scorciatoie. I contatti indipendenti presenti nel sistema di origine vengono assegnati a un'azienda durante la mappatura, senza essere lasciati a se stessi.
Autotask PSA inoltre non consente di modificare l'azienda di un contatto dopo la sua creazione, ed è proprio per questo che una migrazione di prova per verificare l'assegnazione aziendale è fondamentale, soprattutto se si stanno unendo account.
Per quanto riguarda la reportistica, la convalida avviene tramite la dashboard in tempo reale della Migration Wizard, che traccia ticket, agenti, contatti e aziende come entità separate durante il trasferimento, e si conclude con un report su cosa è stato trasferito, cosa non è stato trasferito e perché. Nulla di tutto ciò è automatico. Si tratta di una regola di mappatura e di una dashboard che qualcuno consulta effettivamente, un'affermazione meno azzardata rispetto a "l'isolamento è integrato", ma più veritiera.
Ecco come si presenta la mappatura per singolo cliente: Migrazione da ConnectWise
Prendiamo ConnectWise PSA come esempio concreto. Ogni ticket, contatto e record di configurazione nella ConnectWise migrazione viene associato a un'azienda, e un'azienda si suddivide in sedi per i clienti che operano in più sedi. Durante una migrazione, queste relazioni devono essere mappate correttamente per ciascun cliente.
Questo aspetto diventa ancora più importante quando la piattaforma di origine ha diversi clienti raggruppati sotto un unico record aziendale condiviso. Si tratta di un problema da risolvere prima dell'inizio della migrazione, non durante il suo svolgimento. Nessuno strumento è in grado di separare autonomamente i dati dei clienti misti; per farlo sono necessarie una persona, una decisione e una mappatura accurata. La stessa disciplina si applica alla migrazione dei dati per le aziende di servizi IT in generale; l'isolamento non è una prerogativa esclusiva degli MSP, ma in questo caso assume un'importanza maggiore.
Un altro mito da sfatare: il multi-tenancy è una funzionalità del prodotto, non il risultato di una migrazione. Una piattaforma multi-tenant significa che può ospitare clienti separati senza che questi si vedano a vicenda durante il funzionamento. Non dice nulla sul fatto che i record vengano trasferiti nella posizione corretta durante una migrazione tra due piattaforme multi-tenant. È proprio in questo punto che le affermazioni dei fornitori diventano imprecise. Se qualcuno vi propone una migrazione, chiedetegli a quale aspetto di questa discrepanza si riferisce.
Convalidare ogni cliente prima del passaggio
In pratica, la convalida per singolo cliente prima del passaggio al nuovo sistema significa verificare singolarmente i record mappati di ciascun cliente, anziché campionare l'aggregato:
Per un MSP con pochi clienti, quell'assegno si esaurisce rapidamente. Per uno con decine o centinaia di clienti, è la parte del progetto che consuma più tempo, più ancora del trasferimento dei dati in sé.
Un buon consiglio da seguire è quello di convalidare ogni client separatamente prima del passaggio alla nuova versione. Se qualcosa non va, è possibile annullare la migrazione di quel client senza influire sui client che hanno già superato la convalida. Questo permette di isolare i problemi e di gestire più facilmente l'intera migrazione.
Le questioni relative alla sicurezza e alla conformità sono tra le prime che i fornitori di servizi gestiti (MSP) devono considerare nella valutazione di un partner per la migrazione, ed è giusto che sia così. Leggete Help Desk Migrationla politica di sicurezza di insieme a qualsiasi approccio di isolamento proposto dal fornitore per la vostra specifica migrazione.
I record di PSA che hanno un prezzo allegato
La migrazione dell'help desk di un MSP non si ferma ai ticket. Un PSA (Product Service Account) contiene registrazioni delle ore lavorate e dati contrattuali insieme ai ticket, e queste due categorie hanno un peso finanziario che i ticket semplicemente non hanno. Perdere traccia della cronologia di un ticket significa avere un bel grattacapo con il servizio. Perdere traccia dello stato di fatturazione di una registrazione delle ore lavorate significa ritrovarsi, tre settimane dopo il passaggio al nuovo sistema, con una grossa fetta di ore fatturabili del mese precedente che non sono mai state contabilizzate. Qualsiasi titolare di un MSP vi dirà che queste due situazioni sono ben diverse.
| Tipo di record | Si muove direttamente | Necessita di mappatura | Ha conseguenze sulla fatturazione |
|---|---|---|---|
| Biglietti | SÌ | A livello di campo, solitamente semplice | NO |
| Inserimento orario | Come registrazioni | Sì, la struttura varia da coppia a coppia | SÌ |
| Contratti | Parzialmente | Vedi il segnaposto qui sotto | SÌ |
| Configurazioni | Parzialmente | Dipende dal modello di asset | A volte |
| Aziende | SÌ | Isolamento critico, vedi sopra | NO |
| Contatti | SÌ | Collegato alla mappatura aziendale | NO |
| Siti | SÌ | Collegato alla mappatura aziendale | NO |
| Politica SLA | Raramente uno a uno | Solitamente ricostruiti, non spostati | NO |
| Campi personalizzati | NO | Impostazione manuale sul bersaglio | A volte |
| Allegati | SÌ | Le dimensioni e i limiti di ritenzione variano | NO |
Inserimento orario rispetto allo stato di fatturazione
Le registrazioni delle ore lavorate vengono solitamente migrate come record, ma non come stato di fatturazione, e il motivo è strutturale: lo stato di fatturazione risiede in genere nel livello finanziario della piattaforma, non nel ticket o nella registrazione delle ore lavorate stessa. Autotask PSA lo spiega bene. Una registrazione delle ore lavorate associata a un ticket necessita di approvazione e contabilizzazione prima di diventare una riga fatturabile. Le attività svolte e il tempo impiegato vengono migrati correttamente con il record. Se qualcuno l'abbia già approvata, contabilizzata o fatturata, questa è una questione a parte.
Un problema che di solito viene risolto nel flusso di fatturazione della piattaforma di destinazione, anziché essere trasferito automaticamente.
Opzioni della procedura guidata e sfumature della piattaforma
Help Desk Migration elenca "Migra voci di tempo" come opzione selezionabile nella procedura guidata di migrazione, descritta come il trasferimento dei record utilizzati dagli agenti per registrare il tempo dedicato ai ticket. Si tratta di un'opzione reale e supportata, non di una richiesta speciale per un lavoro personalizzato. Ciò che la descrizione pubblicata non specifica è se lo stato di approvazione, contabilizzazione o fatturazione venga trasferito con questa operazione per la specifica coppia di piattaforme.
Si tratta di una lacuna reale nelle informazioni pubbliche, quindi considera il comportamento generale relativo allo stato di fatturazione descritto sopra come affidabile e rivolgi la domanda specifica sul flag della coppia direttamente al tuo specialista di migrazione.
Contratti come oggetti personalizzati
I contratti vengono trattati allo stesso modo. Né l'elenco dei campi pubblicato da ConnectWise PSA né quello di Autotask PSAincludono i contratti come tipo di record standard. I campi documentati da ConnectWise PSA riguardano membri, contatti, aziende e ticket. Quelli di Autotask PSAriguardano agenti, aziende, contatti e ticket. I contratti rientrano invece nella migrazione degli oggetti personalizzati, la stessa categoria di asset e garanzie, e vengono gestiti tramite i Servizi professionali anziché attraverso il flusso standard di mappatura dei campi.
In breve: i contratti non vengono automaticamente inclusi nella migrazione dei ticket. È necessario prevederli come progetto a sé stante.
Struttura di contatto tra azienda e azienda
Help Desk Migration sposta i record dei ticket e dei contatti tra le piattaforme PSA, preservando la struttura azienda-contatto che mantiene separati i record di ciascun cliente e trattando la riconciliazione dello stato di fatturazione come una fase distinta rispetto allo spostamento dei record sottostanti. Se la tua valutazione dipende dal comportamento specifico dei flag di fatturazione per la tua coppia di piattaforme, è opportuno verificarlo direttamente prima di definire l'ambito.
Per i dettagli specifici della piattaforma, consultare la Autotask PSA documentazione sull'importazione dei dati
Fai da te, gestito o personalizzato: come scegliere la migrazione più adatta per i fornitori di servizi gestiti
Esistono tre modi per migrare l'help desk nelle operazioni MSP, e la scelta di quello più adatto dipende più dal numero di clienti che dal volume dei record:
Migration Wizard, self-service
Ideale per piccole aziende di servizi gestiti (MSP), con pochi clienti e che devono migrare una coppia di piattaforme ben supportate, senza complesse mappature per singolo cliente. È sufficiente definire i campi, eseguire una migrazione di prova, analizzarla e infine eseguire la migrazione completa in autonomia.
Servizio gestito
Questa è la soluzione predefinita per la maggior parte dei progetti MSP, perché la mappatura per singolo cliente, che coinvolge decine o centinaia di clienti, è un processo che richiede confronto, non una semplice lista di controllo da compilare in autonomia. Questo è Help Desk Migrationdi il servizio di migrazione gestita: definiamo l'ambito del progetto insieme a voi, creiamo la mappatura, eseguiamo una migrazione di prova per la revisione e infine gestiamo la migrazione vera e propria.
Consulenza
Per i casi più complessi: dati di origine insoliti, oggetti personalizzati, diverse piattaforme di origine da consolidare contemporaneamente o un problema di sequenziamento in parallelo a un progetto separato lato client.
Gli strumenti nativi di importazione PSA meritano un plauso. La maggior parte delle piattaforme PSA dispone di un CSV o di uno strumento di importazione nativo e, per un set di dati pulito e ben strutturato proveniente da un'unica fonte, questo strumento svolge egregiamente il suo lavoro. Dove, quindi, si rivela davvero utile un servizio di migrazione gestito? Nei casi in cui un importatore nativo non è stato progettato: mappatura per singolo cliente su larga scala, riconciliazione dei dati di fatturazione tra piattaforme con modelli finanziari differenti e convalida che verifica i dati di ciascun cliente singolarmente anziché campionare l'aggregato e considerarlo valido.
Immaginate due MSP uno accanto all'altro. Uno gestisce due clienti e un volume di ticket modesto su piattaforme ben documentate con mappature quasi uno a uno. In questo caso, il self-service è una soluzione ideale. L'altro gestisce 50 clienti e il numero totale di record potrebbe sembrare inferiore sulla carta rispetto a quello dell'MSP con due clienti. Ma non importa. 50 clienti significano 50 mappature e 50 convalide, perché questo carico di lavoro aumenta con il numero di clienti, non con il numero di righe, e non si riduce come accade per la migrazione di un singolo tenant quando il volume diminuisce.
Nessuna API nella tua fonte? Questo cambia completamente la prospettiva fin dal primo giorno. Alcune configurazioni PSA più vecchie o fortemente personalizzate esportano solo in formato CSV, il che è fattibile, ma modifica la quantità di progetto che è possibile automatizzare rispetto a quella che viene mappata manualmente.
Per una versione specifica della piattaforma, Halo Service Solutions la migrazione e ConnectWise a Freshdesk la migrazione rappresentano due delle coppie di piattaforme tra cui gli MSP si spostano più frequentemente.
Passaggio senza lasciare alcuna interruzione di servizio visibile
Il passaggio definitivo è il momento in cui la migrazione dell'help desk per le operazioni MSP diventa reale: non è possibile utilizzare una finestra di manutenzione che i clienti noteranno.
Questo vincolo è il motivo per cui il passaggio di consegne appare come un'operazione parallela anziché un singolo momento di accensione/spegnimento: entrambe le piattaforme rimangono attive per un certo periodo dopo l'esecuzione della migrazione principale e una migrazione Delta sposta tutto ciò che è stato creato o aggiornato in quel lasso di tempo: nuovi ticket, risposte, registrazioni orarie, prima di disattivare definitivamente la piattaforma di origine.
Gestire due piattaforme contemporaneamente ha una conseguenza che va pianificata appositamente: gli operatori devono lavorare su entrambi i sistemi durante il periodo di sovrapposizione e lo schema di numerazione deve essere coerente su entrambi. Questa è una decisione da prendere in anticipo, non un dettaglio da definire il giorno del passaggio.
Nello specifico, due decisioni, entrambe programmate prima dell'inizio del passaggio di consegne
Innanzitutto, la numerazione dei ticket: la piattaforma di destinazione può mantenere la numerazione di origine o deve iniziare una propria sequenza?
Dipende molto dalla piattaforma di destinazione. I campi dei ticket documentati di Autotask PSAelencano sia l'ID che il numero del ticket come campi separati, quindi il numero di origine ha un posto dove essere inserito. I campi documentati di ConnectWise PSA elencano l'ID, ma non un campo separato per il numero del ticket, il che significa che viene inserito come valore anziché riprodurre necessariamente la sequenza di ConnectWise. Se i tuoi clienti notano i numeri dei ticket, verificalo specificamente per la piattaforma di destinazione prima di definire l'ambito del progetto. La piattaforma che stai abbandonando non è un indicatore affidabile di quella a cui stai andando.
In secondo luogo: quando avverrà il passaggio al nuovo portale per i clienti? È una domanda apparentemente semplice, ma con conseguenze ben più gravi di quanto sembri. I clienti hanno salvato quell'URL tra i preferiti e vi hanno effettuato l'accesso innumerevoli volte. Pianificare il passaggio solo in un secondo momento, dopo che i dati sono già stati trasferiti, è esattamente il modo in cui una migrazione tecnicamente impeccabile si trasforma in una pessima esperienza per il cliente.
Non esiste una migrazione PSA senza tempi di inattività, e chiunque affermi il contrario sta cercando di vendere, non di descrivere. Ciò che è realistico, secondo l'esperienza di Help Desk Migration, è un impatto visibile pressoché nullo per il cliente, e quanto ci si avvicini a questo obiettivo dipende dal numero di clienti, dalla configurazione del portale e da come la piattaforma di destinazione gestisce la numerazione dei ticket. Un MSP i cui clienti inviano richieste solo via e-mail di solito ha una transizione più semplice rispetto a uno che utilizza un portale clienti molto frequentato. Un sistema in meno da migrare in tempo reale, un elemento in meno che può andare storto.
Quanto costa effettivamente la migrazione a un MSP e quanto tempo richiede?
La definizione dei prezzi per la migrazione dei dati in un MSP segue una logica diversa rispetto a un progetto a tenant singolo, e la domanda iniziale è sempre la stessa: quanto costerà e quanto tempo ci vorrà per completare il processo? Domanda legittima. Ecco cosa incide concretamente sul costo:
Il numero di clienti è la variabile che distingue un progetto MSP da uno a tenant singolo e, spesso, incide maggiormente su costi e tempi rispetto al volume grezzo dei record. Una migrazione a basso volume distribuita su 40 clienti può risultare più costosa e richiedere più tempo di una migrazione ad alto volume per una singola azienda, perché la mappatura e la convalida scalano in base al numero di clienti, non al numero di righe. L'inserimento dei tempi e la complessità dei contratti aggravano ulteriormente la situazione: un PSA con diverse tipologie di contratto e regole di fatturazione dettagliate per ciascun cliente richiede più tempo per la mappatura rispetto a uno con una struttura semplice e piatta, indipendentemente dal volume dei ticket.
Anche la presenza o meno di un'API nella fonte influisce direttamente sui costi e sulle tempistiche. L'accesso tramite API generalmente implica un percorso più automatizzato. Le fonti basate esclusivamente su CSVo fortemente personalizzate richiedono solitamente una mappatura manuale più accurata prima ancora dell'inizio della migrazione. Il prezzo della migrazione di Help Desk Migrationriflette queste variabili, non un costo fisso per record.
Analizziamo la questione con dati concreti, invece di girare intorno al problema. Help Desk Migration si basano sul numero di record, e la tariffazione non è lineare: più record si migrano, meno si paga per record. Con il piano Standard, senza personalizzazioni, una di 1.000 record costa 100 dollari. Una di 10.000 record costa 514 dollari. I calcoli favoriscono i volumi, ed è proprio per questo che 40 piccole migrazioni per cliente non risultano economicamente vantaggiose quanto un'unica grande migrazione per un singolo tenant.
I pacchetti di servizi variano in base alla complessità: Standard copre una migrazione completa una tantum, Premium gestisce fino a 50.000 record con supporto dedicato, mentre Signature ed Enterprise aggiungono la migrazione incrementale, la migrazione a intervalli, la migrazione multi-thread e un team di account dedicato per i progetti più grandi e multi-cliente.
Niente di tutto ciò sostituisce un preventivo reale. Help Desk Migration fornisce un prezzo definitivo solo dopo che una migrazione demo gratuita ha confermato la fattibilità del progetto.
, stima i costi di migrazione in base al numero di clienti e alle piattaforme che utilizzi, soprattutto se sei un MSP di piccole dimensioni, per il quale il self-service potrebbe essere la soluzione ideale. Hai un numero maggiore di clienti o una situazione più complessa? Una chiamata di valutazione preliminare ti fornirà un preventivo più preciso rispetto a una stima basata sul volume.
Due MSP, due migrazioni, due storie vere
Due storie reali di migrazione da MSP PSA dimostrano la validità del progetto meglio di qualsiasi promessa.
VestaTech si trasferisce in ConnectWise PSA
VestaTech, un'azienda di servizi IT e di sicurezza con sede ad Ardooie, in Belgio, parte del gruppo Vestagroup, aveva bisogno di migrare circa 2.000 ticket, clienti e relativi record di attività da Freshservice a ConnectWise PSA. Prima della migrazione, il team si affidava a uno script di esportazione interno e aveva già escluso l'importazione manuale, ritenendola eccessiva per un volume di dati così elevato. Il test iniziale ha rivelato alcuni errori minori, che VestaTech e il suo supporto hanno risolto prima della migrazione completa. Dopo aver analizzato i risultati del test, VestaTech ha affermato che nessun'altra soluzione si avvicinava minimamente alla qualità del servizio. La migrazione di VestaTech a ConnectWise rappresenta un ottimo esempio per le aziende di servizi che passano a un PSA completo. Dimostra un passaggio diretto alla nuova piattaforma anziché una fusione, una distinzione importante per il prossimo articolo.
ROIcode, che unisce due istanze di supporto in una sola
ROIcode, un'azienda di servizi e tecnologie informatiche con sede a Denver, in Colorado, aveva la necessità di unificare due sistemi di help desk separati, Kayako Classic e Zendeskbasato sul cloud Kayako , anziché disattivarne completamente uno dei due. L'unificazione degli account di ROIcode in Kayakoha consolidato entrambe le fonti di help desk in un'unica istanza, preservando al contempo l'intera cronologia del supporto aziendale fin dal primo giorno. Se il vostro team ha bisogno di unire gli account dopo un'acquisizione anziché cambiare completamente piattaforma, questo caso di studio dimostra come eseguire tale processo senza intoppi.
Percorsi di migrazione documentati rispetto ai risultati ottenuti dai clienti
Oltre alle storie di clienti specifici, Help Desk Migration ha documentato e mappato i percorsi di migrazione per le piattaforme PSA e RMM più utilizzate dagli MSP: SuperOps, Syncroe Atera, oltre a guide dettagliate per ConnectWise le migrazioni, Autotask PSA le migrazioni, la SuperOps checklist per la migrazione dei datie la Halo Service Solutions checklist per la migrazione dei dati.
È importante essere precisi sul significato di questi due tipi di prove, perché gli MSP che valutano un fornitore si accorgono subito quando la distinzione si fa sfumata. Una storia di successo di un cliente specifico, come quella di VestaTech o di ROIcode, rappresenta un risultato: un'azienda, una migrazione, un risultato, riportato una sola volta e non estrapolato ulteriormente. Un percorso di migrazione documentato è diverso. Indica che Help Desk Migration supporta quella coppia di piattaforme e che esiste già una mappatura per essa, non che un progetto di una particolare dimensione o complessità sia stato effettivamente eseguito su di essa. Entrambi gli elementi sono importanti. Nessuno dei due sostituisce l'altro, e qualsiasi pagina che li tratti come se fossero intercambiabili è una pagina di cui dovreste fidarvi meno.
La scalabilità è l'altra metà della questione della fiducia. Help Desk Migration ha completato oltre 60.000 migrazioni, supporta più di 100 piattaforme ed è conforme alle normative SOC 2 Type II e SOC 3 Nulla di tutto ciò sostituisce la storia di VestaTech o di ROIcode. Conferma semplicemente che la stessa disciplina dimostrata da entrambe è disponibile su larga scala, non come soluzione isolata.
Prima di iniziare a valutare la situazione, comincia da qui
Per un MSP, la migrazione va pianificata cliente per cliente, non come un unico grande set di dati.
Prima di procedere al passaggio al nuovo sistema, esegui gli stessi cinque controlli per ogni cliente:
Non riutilizzare la stessa mappatura per tutti i clienti senza prima verificarne le differenze. Un cliente con un volume di transazioni ridotto, una struttura aziendale diversa o campi personalizzati differenti potrebbero richiedere una mappatura diversa rispetto a un cliente di dimensioni molto maggiori.
SuperOps La checklist di migrazione dati Help Desk Migrationdi e Halo Service Solutions la checklist seguono la stessa struttura di connessione, configurazione, selezione, mappatura e test. Utilizza questo formato come punto di partenza per la tua checklist di migrazione specifica per ogni cliente.
La regola è semplice: un cliente, una revisione della mappatura, una convalida prima del passaggio al nuovo sistema.
Domande frequenti
Un help desk per MSP è il livello di ticketing e assistenza clienti all'interno di un PSA, o occasionalmente uno strumento autonomo, che i tecnici utilizzano per registrare, instradare e risolvere le richieste di diverse organizzazioni clienti da un'unica istanza. In genere si integra con la fatturazione, i contratti e la gestione delle risorse, anziché funzionare come strumento di supporto indipendente. Confronta i software ITSM per MSP se ne stai scegliendo uno o se ne stai riconsiderando l'adozione.
MSP è un modello di business: un'azienda che gestisce l'IT per altre aziende in base a un contratto. PSA è una categoria di software: una piattaforma di automazione dei servizi professionali che gestisce tale attività, integrando ticket, registrazioni orarie, contratti e fatturazione in un unico luogo. La maggior parte degli MSP utilizza un PSA anziché un help desk generico, perché un PSA include un livello finanziario che un help desk semplicemente non possiede. Si veda ConnectWise la migrazione per un esempio comune di questa categoria.
Per un MSP, il PSA funge da sistema operativo per il lavoro con i clienti. Ticket, registrazioni orarie, contratti e fatturazione vengono tutti tracciati in relazione a uno specifico cliente, sito o contatto, spesso anche in base ai dati RMM. Un help desk si ferma alla "risoluzione del ticket". Un PSA prosegue con "ore registrate" e "fattura generata". Per un esempio pratico di questa struttura, consultare Autotask PSA
Diverse fonti interpretano la questione in modo differente, ma la maggior parte dei framework suddivide la migrazione dei dati in migrazione dello storage, database , migrazione delle applicazioni e migrazione dei processi aziendali: un modello pensato per l'infrastruttura, non specificamente per i record PSA o dei ticket. Se è proprio questo che cercavi, descrive Help Desk Migrationil processo di la versione a livello di record applicabile ai dati del service desk.
Non esiste un unico strumento migliore. Dipende dalle piattaforme coinvolte, dalla presenza o meno di un'API nella piattaforma di origine e da quanta parte della migrazione richieda una mappatura personalizzata o una semplice corrispondenza dei campi. Per i dati specifici di PSA e help desk, confronta Help Desk Migrationdi i servizi di migrazione con lo strumento di importazione nativo della tua piattaforma di origine prima di prendere qualsiasi decisione.
La scelta della soluzione "migliore" dipende dal numero di clienti, dalla necessità di fatturazione e monitoraggio del tempo nativi e dal livello di approfondimento delle integrazioni richieste. Alcuni MSP utilizzano un PSA dedicato, ConnectWise confrontare o Autotask. Altri optano per un help desk più snello, integrato con un sistema di fatturazione separato. Prima di dare per scontato che un PSA completo sia l'unica strada percorribile, è consigliabile le diverse opzioni di help desk e ITSM pensate per gli MSP.
Oltre al PSA stesso, la suite di strumenti in genere include un software RMM per il monitoraggio e la gestione remota, una piattaforma di documentazione e, a volte, un livello di ticketing separato. Esempi di PSA e RMM per MSP includono ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOnee SherpaDesk, oltre a strumenti ITSM creati specificamente per il settore MSP come ManageEngine ServiceeDesk Plus MSP. Consulta la SuperOps sui concorrenti per un'analisi di una nuova soluzione all-in-one.
Un CRM tiene traccia della pipeline di vendita, dei contatti e delle trattative. Un PSA tiene traccia dell'erogazione dei servizi: ticket, tempo, contratti, fatturazione per i clienti già acquisiti, non per i potenziali clienti. Alcune piattaforme integrano entrambi, ma per un MSP, il PSA è solitamente il sistema di riferimento per le attività di assistenza, mentre un CRM, se presente, si concentra sull'acquisizione di nuovi clienti. Scopri come ConnectWise struttura questi dati.
"MSP nel cloud" si riferisce in genere a un fornitore di servizi gestiti che gestisce l'infrastruttura cloud di un cliente o la migrazione di un cliente a servizi cloud come Microsoft 365. Si tratta di un progetto diverso da quello trattato in questa pagina: la migrazione dei dati del proprio PSA e del service desk, anziché dell'ambiente cloud di un cliente. Per una risposta più approfondita a questa domanda, consultare Perché gli MSP cambiano piattaforma" .
I framework più comuni includono rehosting, replatforming, riacquisto, refactoring, dismissione, mantenimento e ricollocazione, un modello pensato per la migrazione di infrastrutture e applicazioni, non per i dati PSA o dei ticket. Se una ricerca sulla migrazione al cloud ti ha portato qui, scopri come funziona il processo di migrazione a livello di record, applicabile ai dati del service desk e PSA.