Migração de dados para fornecedores de serviços geridos: o seu PSA, não o dos seus clientes
Pesquise "migração de dados para fornecedores de serviços geridos" e encontrará diversos artigos sobre como migrar caixas de correio de clientes para o Microsoft 365.
Esta página aborda o seu PSA, os seus tickets, a sua central de serviços: o sistema que utiliza para gerir o seu negócio. Como MSP, estes dados pertencem a dezenas, por vezes centenas, de clientes em simultâneo, pelo que o isolamento por cliente, a continuidade da faturação e uma transição suave são mais importantes aqui do que em qualquer outro lugar. Veja como funciona o planeamento de migração específico do setor e, em seguida, aplique-o a uma migração de PSA de MSP, onde os riscos são mais elevados.
Sem cartão de crédito Setup rápido
Aprovado por mais de 60.000 empresas
Tipos de Migração de Dados: O que é migrado numa migração de PSA
A troca de um PSA não é uma simples migração de tickets com passos adicionais. Nos bastidores, um único ticket está ligado a tramas, filas, campos personalizados, políticas de SLA e definições que também precisam de ser migradas. Eis o âmbito completo, começando pelos dados do help desk, pela ordem em que a maioria dos MSPs os processa:
| Conjunto de recordes | O que inclui | O que ver num filme | Nota de isolamento por cliente |
|---|---|---|---|
| Suporte técnico e chamadas PSA | Casos, tickets, tópicos de tickets, frames, filas, estado, tags, campos personalizados | As estruturas de tabuleiro e fila raramente correspondem exatamente entre plataformas | Os bilhetes precisam de manter o relacionamento correto com a empresa ou com o cliente |
| Registos de tempo e contratos | Registos de tempo, registos de contrato, definições, referências de faturação | O estado de faturação normalmente não acompanha o registo, ver abaixo | Os termos do contrato permanecem específicos para cada cliente e não se aplicam a todos os clientes |
| Base de conhecimento | Artigos, categorias, visibilidade por cliente versus visibilidade interna, anexos de artigos | As definições de visibilidade requerem uma decisão, não apenas uma regra de mapeamento | Os artigos partilhados exigem uma decisão explícita sobre quais os clientes que podem aceder aos mesmos |
| Dados do cliente e de contacto | Empresas, contactos, sites, hierarquia organizacional, estrutura de agentes e grupos | Esta é a espinha dorsal sobre a qual assentam as restantes chaves da migração | Onde o isolamento tem sucesso ou falha primeiro |
| Media e anexos | Imagens incorporadas, anexos de ficheiros, limites de tamanho e retenção | Os limites de tamanho do alvo podem ser mais restritivos do que os da fonte | Os anexos herdam o isolamento do bilhete ou registo a que pertencem |
| Histórico de e-mails | Threads de entrada e saída ligados a tickets, preservação do cabeçalho | A preservação do cabeçalho varia bastante de acordo com o par de plataformas | Os tópicos permanecem isolados enquanto o ticket principal estiver ativo |
| Registos e gravações de chamadas | Registos telefónicos e links de gravação anexados aos bilhetes | Os links de gravação apontam por vezes para um sistema de terceiros que se move separadamente | Mesma dependência que os anexos |
São sete conjuntos de registos, e não apenas um. Os tickets são a âncora: representam a maior pilha, e é fácil confundir uma troca de PSA com uma migração de tickets. Mas cada um dos outros seis conjuntos de registos tem o seu próprio isolamento por cliente para o proteger durante a transferência. Os registos de tempo e os contratos têm um peso financeiro que os tickets não têm. Os dados do cliente são a espinha dorsal da qual tudo o resto depende. Até mesmo itens tão comuns como anexos e registos de chamadas herdam o seu isolamento do ticket ou registo ao qual estão ligados. Nenhum deles é opcional só porque ninguém os mencionou primeiro.
O que será de facto transferido depende do que a sua plataforma de origem irá libertar e do que a sua plataforma de destino consegue captar. Considere esta tabela como um documento de âmbito que avalia antes de se comprometer com a mudança.
Plataformas de migração suportadas para empresas de 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
Verifique se o nome está correto ou deixe-nos uma mensagem.
Porque é que o isolamento por cliente é o requisito real, e não a contagem de chamadas
O isolamento não é uma funcionalidade que possa simplesmente ativar. Depende de como os dados são mapeados e verificados durante a migração. É isto que diferencia a migração de um help desk de um MSP de um projeto de um único tenant: os dados pertencem a vários clientes, pelo que o mapeamento e a validação precisam de ocorrer para cada cliente, e não apenas uma vez para todo o conjunto de dados.
Este simples facto acrescenta mais tempo a um projeto do que o volume de registos em si. Uma migração que envolva 40 clientes com volumes de dados moderados pode demorar mais tempo a ser planeada e validada do que a migração de um único cliente com um número muito maior de registos. Cada cliente necessita da sua própria revisão e validação de mapeamento antes da transição.
O isolamento não é algo que uma plataforma oferece gratuitamente. Resulta de decisões tomadas durante o mapeamento e é confirmado através da validação de cada cliente antes da migração, não sendo apenas assumido porque ambas as plataformas utilizam a palavra "multi-inquilino" nas suas páginas de marketing.
Como funciona o mapeamento deliberado no Autotask PSA
Então, como é na prática o conceito de "construído deliberadamente"? No Autotask PSA, cada contacto necessita de estar ligado a uma empresa. Sem exceções. Os contactos independentes no seu sistema de origem são atribuídos a uma empresa durante o mapeamento, e não são deixados para se organizarem sozinhos.
Autotask PSA também não permite alterar a empresa de um contacto após a sua criação, e é exatamente por isso que uma migração de demonstração para verificar a atribuição da empresa é mais importante neste caso, especialmente se estiver a fundir contas.
Na parte de reporting, a validação é feita através do painel de controlo em tempo real do Assistente de Migração, rastreando tickets, agentes, contactos e empresas como entidades separadas durante a transferência e finalizando com um relatório sobre o que foi migrado, o que não foi e porquê. Nada disto é automático. Trata-se de uma regra de mapeamento e de um painel de controlo que alguém lê realmente, o que é uma afirmação menos precisa do que "o isolamento já está integrado", e mais verdadeira.
Como é o mapeamento por cliente: Migração do ConnectWise
Tomemos ConnectWise PSA como exemplo concreto. Cada ticket, contacto e registo de configuração na ConnectWise migração é consolidado numa empresa, e uma empresa divide-se em filiais para clientes com mais do que uma unidade. Durante a migração, estas relações precisam de ser mapeadas corretamente para cada cliente.
Isto torna-se ainda mais importante quando a plataforma de origem tem vários clientes agrupados sob um único registo de empresa partilhado. Este é um problema que deve ser resolvido antes do início da migração, e não durante a sua execução. Nenhuma ferramenta separa os dados dos clientes misturados por conta própria; isto exige uma pessoa, uma decisão e um mapeamento cuidadoso. A mesma disciplina aplica-se à migração de dados para empresas de serviços de TI em geral; o isolamento não é exclusivo dos MSPs, apenas tem um impacto maior neste caso.
Mais um mito que vale a pena desmistificar: a multilocação é uma característica do produto, não um resultado da migração. Uma plataforma ser multi-inquilino significa que pode alojar clientes distintos sem que estes se vejam enquanto a plataforma está a ser executada. Isto não diz nada sobre se os registos serão guardados no local certo durante uma migração entre duas plataformas multi-inquilino. É aí que as afirmações dos fornecedores se tornam vagas. Se alguém lhe estiver a vender uma migração, pergunte a que lado dessa lacuna se refere.
Valide cada cliente antes da migração
Na prática, a validação por cliente antes da migração significa verificar os registos mapeados de cada cliente individualmente, e não amostrar o agregado:
Para um MSP com poucos clientes, este pagamento é processado rapidamente. Para um com dezenas ou centenas, é a parte do projeto que consome mais tempo do que a própria transferência de dados.
Uma boa dica é validar cada cliente em separado antes da migração. Se algo falhar, pode reverter a migração desse cliente sem afetar os clientes que já foram validados. Isto mantém os problemas isolados e facilita o controlo geral da migração.
As questões de segurança e conformidade surgem logo no início para os MSP que avaliam um parceiro de migração, e com razão. Leia Help Desk Migrationa política de segurança da juntamente com qualquer abordagem de isolamento que o fornecedor proponha para a sua migração específica.
Os discos da PSA que vêm com um preço anexado
A migração do help desk de um MSP não se limita aos chamados. Um PSA (Public Service Agreement) armazena registos de tempo e contratos juntamente com os chamados, e estas duas categorias têm um peso financeiro que os chamados simplesmente não têm. Perder o controlo do histórico de uma chamada significa ter uma grande dor de cabeça com o serviço. Perder o controlo do estado de faturação de um registo de tempo significa que, três semanas após a migração, se depara com uma grande quantidade de horas faturáveis do mês passado que nunca foram convertidas em receita. Qualquer proprietário de um MSP dirá que estes são problemas completamente diferentes.
| Tipo de registo | Move-se diretamente | Mapeamento de necessidades | Tem consequências para a faturação |
|---|---|---|---|
| Ingressos | Sim | Ao nível de campo, geralmente simples | Não |
| Registos de tempo | Como registos | Sim, a estrutura varia de par para par | Sim |
| Contratos | Parcialmente | Veja o espaço reservado abaixo | Sim |
| Configurações | Parcialmente | Depende do modelo de ativos | Às vezes |
| Empresas | Sim | Isolamento crítico, ver acima | Não |
| Contatos | Sim | Ligado ao mapeamento da empresa | Não |
| Sites | Sim | Ligado ao mapeamento da empresa | Não |
| Políticas de SLA | Raramente um para um | Geralmente reconstruído, não movido | Não |
| Campos personalizados | Não | Configuração manual no alvo | Às vezes |
| Anexos | Sim | Os limites de tamanho e retenção variam | Não |
Registos de tempo versus estado de faturação
As entradas de tempo migram frequentemente como registos, mas não como estado de faturação, e a razão é estrutural: o estado de faturação reside normalmente na camada financeira da plataforma, e não no ticket ou na própria entrada de tempo. Autotask PSA explica isso muito bem. Uma entrada de tempo registada num ticket precisa de aprovação e lançamento antes de se tornar uma linha faturável. O que foi feito e quanto tempo demorou, isto migra com o registo sem problemas. Se alguém já aprovou, lançou ou faturou, é uma questão à parte.
Uma que é geralmente conciliada no próprio fluxo de trabalho de faturação da plataforma de destino, em vez de ser transferida automaticamente.
Opções do assistente e nuances da plataforma
Help Desk Migration lista "Migrar Registos de Tempo" como uma opção nomeada e selecionável no Assistente de Migração, descrita como a transferência dos registos que os agentes utilizam para registar o tempo gasto em chamadas. Esta é uma opção real e suportada, não um pedido especial de desenvolvimento personalizado. O que a descrição publicada não esclarece é se o estado de aprovação, publicado ou faturado é transferido juntamente com a migração para o seu par específico de plataformas.
Esta é uma lacuna honesta no que é público, por isso considere o comportamento geral do estado de faturação acima como sólido e a questão do sinalizador específico do par como algo a ser feito diretamente ao seu especialista em migração.
Contratos como objetos personalizados
Os contratos recebem o mesmo tratamento. Nem a lista de campos publicada ConnectWise PSA nem a do Autotask PSAincluem os contratos como tipo de registo padrão. Os campos documentados pelo ConnectWise PSA abrangem membros, contactos, empresas e chamadas. Os Autotask PSAabrangem agentes, empresas, contactos e chamadas. Os contratos enquadram-se na migração de Objetos Personalizados, a mesma categoria de ativos e garantias, e são geridos pelos Serviços Profissionais em vez do fluxo padrão de mapeamento de campos.
Resumindo: os contratos não são automaticamente incluídos na migração de tickets. Inclua-os no seu orçamento como um projeto separado e com um âmbito definido.
Estrutura de contacto da empresa
Help Desk Migration transfere registos de tickets e contactos entre plataformas PSA, preservando a estrutura de empresa para contacto que mantém os registos de cada cliente separados e trata a conciliação do estado de faturação como uma etapa distinta da transferência dos registos subjacentes. Se a sua avaliação depender do comportamento exato dos indicadores de faturação para o seu par específico, vale a pena confirmar isso diretamente antes de definir o âmbito.
Consulte a Autotask PSA documentação de importação de dados para obter detalhes específicos da plataforma.
Faça você mesmo, gerido ou personalizado: como escolher a migração ideal para fornecedores de serviços geridos
Existem três formas de migrar o help desk para operações MSP, sendo que a melhor opção para si depende mais da quantidade de clientes do que do volume de registos:
Assistente de Migração, self-service
Ideal para pequenas empresas de serviços geridos (MSPs), com poucos clientes, que necessitam de migrar um par de plataformas bem suportadas e sem mapeamento complexo por cliente. Define o âmbito dos campos, executa uma migração de teste, revê os resultados e, em seguida, realiza a migração completa por conta própria.
Serviço Gerido
A opção padrão para a maioria dos projetos MSP (managed service providers) é o mapeamento individual de clientes, que envolve dezenas ou centenas de clientes, uma vez que requer uma conversa, e não apenas o preenchimento de uma lista de tarefas. A Help Desk Migrationoferece um serviço de migração gerida: definimos o âmbito do projeto consigo, criamos o mapeamento, realizamos uma migração de teste para revisão e, em seguida, tratamos da migração propriamente dita.
Consultoria
Para os casos mais complexos: dados de origem invulgares, objetos personalizados, várias plataformas de origem para consolidar simultaneamente ou um problema de sequenciação em conjunto com um projeto separado do lado do cliente.
Os importadores nativos de PSA merecem aqui reconhecimento. A maioria das plataformas de PSA possui uma CSV e, para um conjunto de dados limpo e bem definido a partir de uma única fonte, esta ferramenta dá conta do recado na perfeição. Então, onde é que um serviço de migração gerido se justifica realmente? Nas áreas para as quais não foi concebido um importador nativo: mapeamento por cliente em grande escala, conciliação de registos de faturação entre plataformas com diferentes modelos financeiros e validação que verifica os dados de cada cliente individualmente, em vez de simplesmente amostrar o agregado e considerar o resultado satisfatório.
Imagine dois MSPs lado a lado. Um deles serve dois clientes e tem um volume moderado de chamadas em plataformas bem documentadas, com um mapeamento próximo de um para um. O self-service é uma ótima opção neste caso. O outro serve 50 clientes, e o seu número total de registos pode parecer menor no papel do que o do MSP com dois clientes. Mas isso não interessa. 50 clientes significam 50 mapeamentos e 50 validações, porque este trabalho escala com o número de clientes, e não com o número de linhas, e não diminui da mesma forma que o esforço de migração de um único locatário quando o volume cai.
Sem qualquer API na sua fonte de dados? Isto muda completamente o âmbito do projeto desde o início. Algumas configurações de PSA mais antigas ou altamente personalizadas apenas exportam em CSV, o que funciona, mas altera a quantidade de tarefas que podem ser automatizadas em comparação com a quantidade que precisa de ser mapeada manualmente.
Para uma versão específica da plataforma, Halo Service Solutions a migração e ConnectWise para Freshdesk a migração abrangem dois dos pares entre os quais os MSPs mais migram.
Corte sem deixar lacunas visíveis no serviço
A transição é onde a migração do help desk para as operações MSP se torna real: não pode aceitar uma janela de manutenção que os seus clientes irão notar.
Esta única restrição é a razão pela qual a transição parece uma operação paralela em vez de um simples "ligar e desligar": ambas as plataformas permanecem ativas durante um período após a execução da migração principal, e uma migração Delta move tudo o que foi criado ou atualizado nesse intervalo: novos tickets, respostas, registos de tempo, antes de desativar a fonte definitivamente.
Operar duas plataformas em simultâneo tem uma consequência que vale a pena planear com antecedência: agentes a trabalhar em tickets em ambos os sistemas durante a sobreposição, e um esquema de numeração que precisa de fazer sentido em ambos. Esta é uma decisão tomada previamente, não um pormenor resolvido no dia da transição.
Duas decisões específicas, ambas agendadas antes do início da transição
Em primeiro lugar, a numeração dos tickets: a plataforma de destino pode manter a numeração da plataforma de origem ou inicia a sua própria sequência?
Isso depende muito de para onde vai. Os campos de tickets documentados do Autotask PSAlistam o ID e o número do ticket como campos separados, pelo que o número de origem tem onde ser armazenado. Os campos documentados do ConnectWise PSA listam o ID, mas não um campo separado para o número do ticket, o que significa que chega como um valor em vez de necessariamente reproduzir a sequência própria do ConnectWise. Se os seus clientes notarem números de tickets, confirme isso especificamente para o seu destino antes de definir o âmbito do projeto. A plataforma que está a deixar não é um indicador fiável da plataforma para a qual está a ir.
Segundo: quando será migrado o portal orientado para o cliente? Esta é uma questão pequena, mas com consequências maiores do que parece. Os clientes têm este URL guardado nos favoritos e já acederam por ele inúmeras vezes. Agendar esta migração como uma reflexão tardia, depois de os dados já terem sido transferidos, é exatamente como uma migração tecnicamente perfeita se transforma numa má experiência para o cliente.
Não existe migração de PSA sem tempo de inatividade, e quem disser o contrário está apenas a vender, não a descrever. O que é realista, segundo a experiência da Help Desk Migration, é um impacto visível quase nulo para o cliente, e o quão próximo disso se chega depende do número de clientes, da configuração do portal e da forma como a plataforma de destino lida com a numeração dos tickets. Um MSP cujos clientes apenas enviam pedidos por e-mail tem geralmente uma transição mais fácil do que um que utiliza um portal de clientes com utilização intensa. Menos um sistema para migrar em produção, menos uma coisa que pode correr mal.
Qual o custo real da migração para um MSP e quanto tempo demora?
A precificação da migração de dados para MSPs segue uma lógica diferente da de um projeto para um único tenant, e a primeira questão que se coloca é a mesma: quanto é que isso vai custar e quanto tempo vai demorar a concluir o projeto? Uma pergunta justa. Veja o que realmente influencia o preço:
O número de clientes é a variável que diferencia um projeto de MSP de um projeto de cliente único, e muitas vezes tem um impacto maior no custo e no cronograma do que o volume bruto de registos. Uma migração de baixo volume distribuída por 40 clientes pode acabar por custar mais e demorar mais tempo do que uma migração de alto volume para uma única empresa, porque o mapeamento e a validação são dimensionados de acordo com o número de clientes, e não com o número de linhas. O registo de tempo e a complexidade dos contratos agravam a situação: um PSA com vários tipos de contrato e regras de faturação detalhadas por cliente demora mais tempo a mapear do que um com uma estrutura simples e plana, independentemente do volume de chamadas.
O facto de a sua fonte de dados possuir uma API também altera diretamente o custo e o cronograma. O acesso via API significa, muitas vezes, um processo mais automatizado. As fontes de dados que utilizam apenas CSVou que são altamente personalizadas requerem, geralmente, mais mapeamento manual antes mesmo do início da migração. O preço da migração da Help Desk Migrationreflete estas variáveis, e não um valor fixo por registo.
Vamos aos números, em vez de andarmos a dar voltas aos círculos. Help Desk Migration é calculado pela quantidade de registos e não é linear: quanto mais registos migrar, menos pagará por registo. No plano Standard, sem qualquer personalização, uma de 1.000 registos custa 100 dólares.Uma de 10.000 registos custa 514 dólares.A matemática favorece o volume, e é exatamente por isso que 40 pequenas migrações por cliente não têm a mesma vantagem económica que uma grande migração para um único tenant.
Os pacotes de serviços são escaláveis de acordo com a complexidade: o Standard cobre uma migração completa única, o Premium lida com até 50.000 registos com suporte dedicado, e o Signature e o Enterprise acrescentam migração Delta, migração por intervalo, migração multithread e uma equipa de contas dedicada para projetos maiores e com vários clientes.
Nada disto substitui um orçamento formal. Help Desk Migration só fornece um preço fixo por escrito após uma demonstração gratuita da migração, que confirma o que realmente precisa.
, estime o custo da sua migração com base no número de clientes e plataformas que utiliza, especialmente se for um MSP mais pequeno, onde o self-service pode ser a melhor opção. Se tiver um maior número de clientes e a complexidade do projeto, uma reunião para definir o âmbito do negócio dar-lhe-á uma resposta mais precisa do que uma estimativa baseada no volume.
Dois MSPs, duas migrações, duas histórias reais
Duas histórias reais de migração para MSP PSA comprovam-no melhor do que qualquer promessa.
VestaTech entra no ConnectWise PSA
A VestaTech, empresa de serviços de TI e segurança sediada em Ardooie, na Bélgica, e parte do grupo Vestagroup, necessitava de migrar aproximadamente 2.000 tickets, clientes e registos de atividades relacionados do Freshservice para o ConnectWise PSA. Antes da migração, a equipa utilizava um script de exportação desenvolvido internamente e já tinha descartado a importação manual, por a considerar mais trabalhosa do que compensadora para aquele volume. O teste inicial revelou alguns erros menores, que a VestaTech e a equipa de suporte resolveram antes da migração completa. Após analisar os resultados do teste, a VestaTech afirmou que nenhuma outra opção se comparava. A migração da VestaTech para ConnectWise oferece um excelente exemplo para as empresas de serviços que estão a adotar uma PSA completa. Demonstra uma mudança direta de plataforma, em vez de uma fusão, uma distinção importante para o próximo artigo.
ROIcode, fundindo duas instâncias de suporte numa só
A ROIcode, uma empresa de tecnologia e serviços de informação com sede em Denver, no Colorado, precisava de integrar dois sistemas de help desk distintos, Kayako Classic e Zendeskbaseada na cloud Kayako , em vez de desativar completamente um deles. A fusão de contas da ROIcode no Kayakoconsolidou ambas as fontes de help desk numa única instância, preservando todo o histórico de suporte da empresa desde o primeiro dia. Se a sua equipa precisa de fundir contas após uma aquisição, em vez de migrar completamente de plataforma, este caso de estudo demonstra como executar este processo sem problemas.
Percursos de migração documentados versus resultados para o cliente
Para além dos casos de sucesso de clientes, Help Desk Migration documentou e mapeou os caminhos de migração para as plataformas PSA e RMM mais utilizadas pelos MSPs: SuperOps, Syncroe Atera, bem como guias passo a passo para ConnectWise migrações, Autotask PSA migrações, a SuperOps lista de verificação de migração de dadose a Halo Service Solutions lista de verificação de migração de dados.
Vale a pena sermos precisos sobre o que estes dois tipos de evidência realmente significam, porque os MSP que avaliam um fornecedor percebem quando a distinção se torna confusa. Um caso de sucesso de um cliente específico, como o da VestaTech ou da ROIcode, é um resultado: uma empresa, uma migração, um resultado, reportado uma única vez e não extrapolado posteriormente. Um caminho de migração documentado é diferente. Indica que Help Desk Migration suporta este par de plataformas e que já existe um mapeamento para o mesmo, não que um projeto de determinada dimensão ou complexidade tenha sido de facto executado nesta plataforma. Ambos são importantes. Nenhum substitui o outro, e qualquer página que os trate como intercambiáveis é uma página em que deve confiar um pouco menos.
A escala é a outra metade da questão da confiança. Help Desk Migration já realizou mais de 60.000 migrações, suporta mais de 100 plataformas e possui as certificações SOC 2 Type II e SOC 3 Nada disto substitui a história da VestaTech ou da ROIcode. Apenas confirma que a mesma disciplina que ambas adquiriram está disponível em escala, e não apenas como um serviço pontual.
Antes de analisar isso, comece por aqui
Para um MSP (managed service provider), o âmbito da migração deve ser definido cliente a cliente, e não como um único conjunto de dados de grande dimensão.
Antes de se comprometer com a migração, execute as mesmas cinco verificações para cada cliente:
Não reutilize o mesmo mapeamento para todos os clientes sem verificar as diferenças. Um cliente com um baixo volume de transações, uma estrutura organizacional diferente ou campos personalizados pode exigir um mapeamento diferente de um cliente muito maior.
Halo Service Solutions As listas de SuperOps verificação de migração de dados Help Desk Migrationda e seguem a mesma estrutura de ligar, configurar, selecionar, mapear e testar. Utilize este formato como ponto de partida para a sua própria lista de verificação de migração por cliente.
A regra é simples: um cliente, uma revisão de mapeamento, uma validação antes da implementação.
Perguntas frequentes
Um help desk para os MSP é a camada de emissão de tickets e de suporte técnico dentro de um PSA (Plataforma de Serviços Profissionais), ou ocasionalmente uma ferramenta independente, que os técnicos utilizam para registar, encaminhar e resolver pedidos para várias organizações clientes a partir de uma única instância. Normalmente, funciona em conjunto com sistemas de faturação, contratos e registos de ativos, em vez de operar como uma ferramenta de apoio independente. Compare software ITSM para MSPs se estiver a escolher ou a reconsiderar um.
O MSP é um modelo de negócio: uma empresa que gere as TI de outras empresas sob contrato. O PSA é uma categoria de software: uma plataforma de automatização de serviços profissionais que gere este negócio, integrando os chamados, registos de tempo, contratos e faturação num só local. A maioria dos MSP utiliza um PSA em vez de um help desk genérico, porque um PSA tem uma camada financeira que um help desk simplesmente não tem. Veja ConnectWise a migração para um exemplo comum desta categoria.
Para um MSP (Managed Service Provider), o PSA (Professional Services Agreement) funciona como o sistema operativo para o trabalho com o cliente. Os tickets, registos de tempo, contratos e faturação são todos rastreados em relação a um cliente, local ou contacto específico, frequentemente também em relação aos dados do RMM (Revenue Marketing Management). Um help desk pára em "ticket resolvido". Um PSA continua em "horas registadas" e "fatura gerada". Veja Autotask PSA para um exemplo prático desta estrutura.
Diferentes fontes abordam isto de formas distintas, mas a maioria das estruturas divide a migração de dados em migração de armazenamento, database , migração de aplicações e migração de processos de negócio, um modelo criado para infraestrutura, não especificamente para registos de PSA ou tickets. Se era isso que procurava, o aborda Help Desk Migrationprocesso de a versão ao nível do registo que se aplica aos dados da central de serviços.
Não existe uma única ferramenta ideal. Depende das plataformas envolvidas, se a fonte tem uma API e quanta migração requer mapeamento personalizado ou apenas correspondência de campos. Especificamente para dados de PSA e help desk, compare Help Desk Migrationda os serviços de migração com a ferramenta de importação nativa da sua plataforma de origem antes de tomar qualquer decisão.
A melhor opção depende do número de clientes, da necessidade de faturação e controlo de tempo nativos e da complexidade das integrações necessárias. Alguns MSP utilizam um PSA dedicado, o ConnectWise ou o Autotask. Outros utilizam um help desk mais simples com faturação separada. Compare as opções de help desk e ITSM desenvolvidas para os MSP antes de assumir que um PSA completo é a única solução.
Além do próprio PSA, o seu conjunto de ferramentas inclui frequentemente um software RMM para monitorização e gestão remota, uma plataforma de documentação e, por vezes, uma camada de emissão de tickets separada. Exemplos de PSA e RMM para MSPs incluem o ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOnee SherpaDesk, bem como ferramentas ITSM desenvolvidas especificamente para o segmento dos MSPs, como o ManageEngine ServiceeDesk Plus MSP. Veja SuperOps os concorrentes para conhecer uma opção mais recente e completa.
Um CRM acompanha o pipeline de vendas, contactos e negócios. Um PSA acompanha a prestação de serviços: chamadas, tempo, contratos e faturação para clientes já registados, e não para potenciais clientes. Algumas plataformas combinam ambos, mas para um MSP, o PSA é geralmente o sistema de registo para o trabalho de serviço, enquanto um CRM, se existir, se concentra em novos negócios. Veja como ConnectWise estrutura estes dados.
"MSP na nuvem" refere-se normalmente a um fornecedor de serviços geridos que gere a infraestrutura de nuvem de um cliente ou a migração de um cliente para serviços de nuvem como o Microsoft 365. Este é um projeto diferente do abordado nesta página: a migração dos seus próprios dados de PSA e service desk, e não do ambiente de nuvem de um cliente. Veja porque é que os MSPs mudam de plataforma para a versão desta questão focada na plataforma.
As estruturas comuns incluem rehosting, replatforming, repurchasing, refactoring, retireing, retaining e relocating, um modelo criado para migração de infraestruturas e aplicações, e não para dados de PSA ou de tickets. Se chegou aqui através de uma pesquisa sobre migração para a cloud, veja como funciona o processo de migração para o equivalente ao nível do registo, aplicável a dados de service desk e PSA.