Migração de dados para empresas de serviços de TI: da contagem de chamadas ao âmbito completo
Comecemos por algo que a maioria das equipas só considera quando já é tarde demais: o seu service desk não é apenas uma ferramenta. Contém todas as informações sobre o relacionamento com cada cliente. Portanto, ao decidir migrar para uma plataforma ITSM, todo este histórico precisa de ser transferido em conjunto.
Help Desk Migration transfere agentes, mapeia os seus tickets, contactos e histórico da empresa de forma organizada, proporcionando total integridade dos dados do ITSM.
Sem cartão de crédito Setup rápido
Aprovado por mais de 60.000 empresas
Âmbito da Migração de Dados: Sete Conjuntos de Registos, Um Projeto
Antes de planear a migração de dados, faça um inventário de todos os tipos de registo na sua plataforma de suporte. Analise os seus dados atuais para decidir o que migrar e, em seguida, compare os seus sistemas de origem e destino para criar um plano preciso de mapeamento de campos com antecedência.
| Conjunto de recordes | O que inclui | O que ver num filme |
|---|---|---|
| Dados de help desk e centro de atendimento | Casos, chamadas, conversas, estado, etiquetas, campos personalizados | Este determina o volume de todo o projeto. Defina primeiro o âmbito. |
| Registos ITSM | Incidentes, pedidos de assistência, registos de alterações, registos de problemas, políticas de SLA, cadeias de aprovação, itens de configuração | Três destes sete tipos necessitam geralmente de remapeamento ou reconstrução, e não de uma transferência direta |
| Base de conhecimento | Artigos, categorias, pastas, visibilidade interna versus pública, anexos de artigos | As definições de visibilidade nem sempre correspondem a um equivalente na plataforma de destino |
| Dados do cliente e de contacto | Empresas, contactos, sites, hierarquia organizacional, estrutura de agentes e grupos | A estrutura de grupo tem frequentemente de ser reestruturada quando a plataforma de destino modela as equipas de forma diferente |
| Media e anexos | Imagens embutidas, anexos de ficheiros | O volume de anexos pode estender a sua janela de migração mais do que a quantidade de tickets |
| 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 depende do que a plataforma de origem armazena realmente, e não apenas do que exibe |
| Registos e gravações de chamadas | Registos telefónicos e links de gravação anexados aos bilhetes | Geralmente, trata-se de uma ligação a um sistema de telefonia, e não de uma gravação armazenada. Migras a referência, não o áudio. |
Nota de rodapé: a cobertura por conjunto de registos depende do que a plataforma de origem expõe e dos modelos de destino.
Entrou aqui a pensar apenas em chamados? Todo o mundo faz isso. Mas quando se vê a lista completa, o âmbito dos registos ITSM torna-se muito mais claro, rapidamente. Considere um projeto típico: uma migração para Ivantiou para o ServiceNow.
Pretende uma análise mais detalhada de uma plataforma específica? Consulte as Freshservice migração ou Jira Service Management de migração para saber como se comporta um único conjunto de registos neste destino.
A sobre a migração da base de conhecimento aborda a estrutura e a visibilidade dos artigos. Ainda está a avaliar plataformas antes de sequer pensar em migrar? Comece pelo guia de software de help desk para empresas de TI.
Um ponto importante a destacar: "migração de dados" abrange também dois projetos que esta página não aborda. Database e aplicações move os sistemas da sua empresa, e não a central de atendimento. A migração de endpoints ou tenants move dispositivos e contas de utilizador, e não casos ou chamadas. Ambas são reais. Nenhuma delas precisa do guia abaixo.
Integrações de migração ITSM suportadas
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.
Os tipos de discos que se movem com facilidade e os três que raramente o fazem
Nem todos os tipos de registo migram da mesma forma. Os registos ITSM essenciais, como tickets e anexos, são transferidos com uma fidelidade quase perfeita, mas a lógica operacional — especificamente SLAs, cadeias de aprovação e relações de itens de configuração (CIs) — não pode ser simplesmente migrada. Os planos de migração bem-sucedidos devem ter em conta o remapeamento e a reconstrução personalizados necessários para estes três ativos dependentes da plataforma.
| Tipo de registo | Padrão típico | Estado |
|---|---|---|
| Incidentes | Move-se diretamente | A estrutura básica de bilhetes corresponde, geralmente, a uma correspondência direta entre as plataformas |
| Solicitações de serviço | Move-se diretamente | Padrão estrutural semelhante ao dos incidentes na maioria dos esquemas-alvo |
| Alterar registos | Move-se diretamente | Estruturalmente semelhantes aos tickets na maioria das plataformas ITSM |
| Registos de problemas | Move-se diretamente | Estruturalmente semelhantes aos tickets na maioria das plataformas ITSM |
| Campos personalizados | Move diretamente, condicional à correspondência do esquema | A fidelidade depende de o esquema de destino possuir um campo equivalente |
| Anexos | Move-se diretamente | Transferência ao nível do ficheiro, geralmente sem alterações |
| Políticas de SLA | Necessita de remapeamento | Recrie manualmente os seus objetivos de SLA (como limites de tempo para a primeira resposta e resolução) no sistema de destino antes da transferência principal de dados. Também pode preservar métricas históricas de SLA como dados estáticos e de leitura apenas em tickets individuais através de personalização. |
| Cadeias de aprovação | Geralmente reconstruído no alvo | A plataforma calcula a lógica de aprovação e o estado por si só, em vez de os armazenar como um registo portátil |
| Itens de configuração | Necessita de remapeamento | As relações de CI dependem da forma como o CMDB de destino modela os ativos e as dependências |
Porque é que apenas três tipos de registo causam problemas? Porque as políticas de SLA e as cadeias de aprovação nunca foram "dadas" em primeiro lugar. São lógica. A plataforma de destino recalcula os prazos de SLA e os estados de aprovação através das suas próprias regras de escalonamento e do seu próprio motor de fluxo de trabalho. Não pode simplesmente copiar um número de uma plataforma e aplicá-lo a outra esperando que ainda signifique a mesma coisa. Os itens de configuração enfrentam um obstáculo semelhante, mas de um ângulo diferente: as relações de CI dependem da forma como o CMDB de destino estrutura os ativos e as dependências, e esta estrutura raramente corresponde à da plataforma de origem, campo a campo.
Incidentes, pedidos de assistência, registos de alterações e registos de problemas não apresentam este problema. São, na sua maioria, registos simples: um estado, uma descrição, alguns campos personalizados e alguns anexos. Preserve a estrutura, remapeie os campos onde o esquema não se alinha e a transição entre eles ocorre sem grandes dificuldades.
História de um cliente
A e-Core migrou um cliente do Zendesk para o Jira Service Management
Migração Zendesk para o Jira Service Management
Bilhetes, contactos, agentes, empresas, anexos, notas: tudo foi transferido sem problemas. Mas depois a equipa deparou-se com o único obstáculo. A atribuição de organização de cada bilhete desorganizava-se após a migração, e tiveram de criar uma solução personalizada só para a manter no lugar.
Assim, dividiram o trabalho em duas etapas: primeiro os chamados fechados e, depois, os restantes. Este é o padrão em todas as migrações de ITSM, repetidamente. A maior parte da estrutura de uma central de serviços permanece intacta durante a transição. As exceções são aquelas partes que vale a pena planear antes da migração, e não as que precisam de ser corrigidas à pressa depois.
Os testes detetam estas três exceções enquanto ainda são baratas de corrigir. Audite os seus próprios tipos de registo em relação a esta matriz antes de definir o âmbito do projeto. Não depois.
Como funciona na prática a migração de dados para empresas de serviços de TI
A migração da sua central de serviços de TI com o Help Desk Migration segue cinco passos claros no assistente de migração de self-service.
Conecte suas plataformas
Ligue as suas plataformas de origem e destino no Assistente de Migração. Introduza as credenciais de acesso para ambas as ferramentas ITSM e Help Desk Migration autenticará cada ligação. Não é necessária instalação ou script. O assistente lê ambos os esquemas e lista todos os tipos de registo disponíveis para transferência.
Selecione os seus dados
Escolha quais os conjuntos de registos a migrar: incidentes, agentes, tickets, tarefas e artigos da base de conhecimento. Migre tudo ou limite a transferência a um subconjunto definido — o assistente move exatamente o que selecionar e nada mais. É aqui que define os limites do projeto antes de um único registo sair da origem.
Mapeie os seus campos
Mapeie os seus campos entre esquemas que não correspondem. Alinhe o estado dos tickets, prioridades, tipos de pedido, agentes e campos personalizados entre a origem e o destino para que nada seja alocado no local errado. O assistente sugere mapeamentos padrão automaticamente, e ajusta qualquer configuração que necessite de tratamento personalizado. Esta etapa protege a integridade referencial quando os registos são transferidos em grande volume.
Execute uma migração de demonstração
Execute uma Migração de Demonstração gratuita antes de se comprometer com qualquer coisa. O assistente transfere um pequeno lote de registos para que possa verificar o mapeamento de campos, anexos e relações na plataforma de destino. Analise os resultados, descarregue os relatórios e confirme se tudo foi mapeado corretamente. Ajuste e execute novamente a Demonstração as vezes necessárias.
Iniciar a Migração Completa
Assim que a demonstração estiver correta, inicie a Migração Completa. Help Desk Migration transfere todos os conjuntos de registos selecionados para a plataforma de destino sem interrupções, permitindo que a sua equipa continue a trabalhar durante todo o processo. Em seguida, execute uma Migração Delta para mover quaisquer chamadas criadas durante a transferência e conclua a transição sem deixar nada para trás.
Quais os custos da migração e quanto tempo dura?
O custo e o cronograma dependem das mesmas quatro variáveis:
Volume recorde
Quantos tickets, ocorrências e registos relacionados está a transferir?
Profundidade do campo personalizada
Quanto trabalho de mapeamento necessita cada campo?
Número de instâncias de origem
Uma mesa a consolidar-se numa, ou várias mesas a consolidar-se numa só
Disponibilidade da API
Independentemente de a sua plataforma de origem expor um, ou se precisar de um caminho de campo personalizado, como fez o Hexagon Software Group
No plano Standard do Help Desk Migration, uma migração básica sem personalização pré-configurada custa 100 dólares por 1.000 registos, mas 10.000 registos nas mesmas condições custam 514 dólares, um valor muito inferior a dez vezes o custo da migração. Quanto maior for a migração, menor será o custo por registo, e a profundidade dos campos personalizados influencia este valor de forma muito mais significativa do que o volume em si.
Estudos de Caso de Sucesso em Migração de Dados ITSM
Uma mudança de ITSM que abrange todo o ecossistema
A e-Core, uma empresa de consultoria Atlassian e outsourcing de aplicações com sede em Porto Alegre, no Brasil, precisava de migrar um dos seus clientes do Zendesk para o Jira Service Desk. A database do cliente era grande e queriam manter todos os seus dados, em vez de começar do zero. Help Desk Migration dividiu a transferência em duas etapas: primeiro os tickets fechados e, em seguida, o volume restante. Além disso, criaram uma solução personalizada para que cada ticket mantivesse a atribuição de organização correta após a migração. Tudo o resto foi migrado sem problemas: tickets, contactos, agentes, empresas, anexos e notas. A e-Core realizou vários testes de migração antes de confirmar a transferência completa, que é exatamente a etapa de validação que orienta toda esta página. O líder técnico da empresa confirmou que os dados necessários chegaram intactos ao Jira Service Desk.
A história da migração da e-Core
Janela curta, consolidação Zendesk , instância de um parceiro como fonte
Lenovo Private Cloud Solution necessitava de migrar rapidamente um volume significativo de tickets da instância Zendesk de um parceiro para a sua própria instância, para uma divisão sediada em Bucareste, na Roménia. Em vez de um serviço totalmente gerido, a equipa optou por utilizar o Assistente de Migração e transferiu o volume de tickets entre instâncias num curto período. A velocidade, porém, não era tudo. Lenovo precisava que o histórico de dados fosse preservado para referência futura, e o gestor de operações destacou posteriormente o acompanhamento da equipa de contas ao longo do processo.
História de migração da solução Lenovo Private Cloud
Uma fonte legada sem API
A Hexagon Software Group, empresa britânica de desenvolvimento de software especializado em gestão imobiliária e financeira, precisava de migrar do ReadyDesk para Freshdesk sem uma ligação API na origem. Help Desk Migration criou um caminho de migração personalizado que abrangia tanto os dados do help desk como a base de conhecimento. Preservar o histórico de chamadas era mais importante do que parece. A receita da Hexagon depende fortemente de serviços profissionais, e não apenas de licenças de software, e o consultor sénior do cliente destacou posteriormente que o histórico migrado forneceu à equipa um registo pesquisável que podia ser acedido a pedido, em vez de começar do zero.
A história de migração do Hexagon Software GroupTemos aqui três formas diferentes do problema: uma migração de plataforma entre ecossistemas, uma pressão constante sobre o volume e o prazo dos registos e uma fonte legada sem API. Juntas, abrangem uma boa parte do que será, provavelmente, a sua própria migração. Chame-lhe migração de dados para fornecedores de serviços de TI, chame-lhe migração ITSM. Não importa. O trabalho é o mesmo. Mova o registo. Não apenas o ticket.
Antes de definir o âmbito do projeto: mapeie os seus próprios tipos de registo
Funciona assim: a matriz acima é o padrão da Help Desk Migration, construído a partir de projetos reais, não um palpite. Mas ainda não é o seu padrão. Pegue-o. Ligue o seu próprio par de plataformas. Entre nessa reunião de âmbito já sabendo onde vai encontrar atrito, em vez de descobrir três semanas depois, quando a reparação for cara.
| Tipo de registo | Padrão geral | Confirmado para o seu par de plataformas? | Necessita de remapeamento? | Proprietário |
|---|---|---|---|---|
| Incidentes | Move-se diretamente | Sim (API compatível) | Mapeamento padrão de estado e prioridade | Líder da Central de Serviços |
| Solicitações de serviço | Move-se diretamente | Sim (API compatível) | Solicitar mapeamento de artigos do catálogo | Líder da Central de Serviços |
| Alterar registos | Move-se diretamente | Sim (correspondência de esquema) | Mapeamento dos campos de risco, tipo e motivo | Gestor de Mudanças |
| Registos de problemas | Move-se diretamente | Sim (correspondência de esquema) | Relações entre causa raiz e incidentes relacionados | Gestor de Problemas |
| Campos personalizados | Move diretamente, condicional à correspondência do esquema | Auditoria necessária | Crie campos personalizados correspondentes no destino | Administrador de ITSM |
| Anexos | Move-se diretamente | Sim (Transferência direta de ficheiros) | Não (Preservar anexos e ficheiros incorporados) | Líder de Migração |
| Políticas de SLA | Necessita de remapeamento | Reconstruir no alvo | Recriar objetivos; métricas históricas através de campos personalizados | Gestor de Entrega de Serviços |
| Cadeias de aprovação | Geralmente reconstruído no alvo | Reconstruir no alvo | Configure o motor de fluxo de trabalho no sistema de destino | Proprietário do Processo ITSM |
| Itens de configuração | Necessita de remapeamento | Dependente do modelo | Alinhar modelos de ativos e hierarquia de dependências de CI | Gestor de ativos/CMDB |
Preencha este formulário. Traga-o para a sua Migração de Demonstração Gratuita. Esta é a diferença entre chegar com um palpite e chegar com um plano, e é assim que minimiza os riscos da conversa inicial antes mesmo de esta começar.
Perguntas frequentes: Migração de dados para empresas de serviços de TI
A migração de ITSM significa mover os registos de uma plataforma de gestão de serviços de TI — incidentes, pedidos de serviço, registos de alterações, registos de problemas, políticas de SLA, cadeias de aprovação e itens de configuração — de uma plataforma para outra. É diferente de uma migração de help desk comum, uma vez que a plataforma calcula vários destes tipos de registo dinamicamente, em vez de os armazenar, pelo que normalmente os remapeia em vez de os transferir diretamente. Deparar-se-á com isto sempre que migrar para o ServiceNow ou para uma ferramenta ITSM concorrente.
A maioria das fontes centra-se nos mesmos quatro aspetos: migração de armazenamento, database , migração de aplicações e migração para a cloud. A migração de armazenamento move dados entre sistemas de armazenamento físicos ou virtuais. Database move os dados entre database . A migração de aplicações ocorre como parte da troca de um sistema de software por outro. A migração para a cloud move os dados para a infraestrutura da cloud. Nenhum destes quatro aspectos se centra na central de serviços. Consulte Help Desk Migrationo processo específico da para obter a versão para a central de serviços.
Depende do volume de registos, da complexidade dos campos personalizados, da quantidade de instâncias de origem que está a consolidar e se a sua plataforma de origem expõe uma API. Eis a questão: um pequeno volume de tickets com lógica complexa em campos personalizados pode custar mais do que um grande volume com lógica simples, porque o trabalho de mapeamento influencia o preço mais do que a quantidade de tickets. Consulte dos preços .
Depende da sua plataforma de origem, da sua plataforma de destino e de quanta intervenção gerida é necessária em comparação com a execução por conta própria. Para migrações de help desk e ITSM especificamente, Help Desk Migration traz dados de projeto próprios para mais de 100 plataformas suportadas, o que o diferencia de uma ferramenta ETL de uso geral criada para databaseou aplicações. Compare os modos de entrega na Help Desk Migration de serviços .
Geralmente, isto significa mover incidentes, pedidos, registos de alterações e itens de configuração para ServiceNow a partir de outra plataforma, ou ServiceNow vice-versa. ServiceNow o SLA e o estado de aprovação internamente, pelo que migrar para ou a partir dele geralmente significa remapear estes tipos de registo em vez de os transferir tal como estão. Consulte a ServiceNow página de migração para obter detalhes específicos da plataforma.
No âmbito do framework ITIL: estratégia de serviço, design de serviço, transição de serviço, operação de serviço e melhoria contínua de serviço. Uma migração de plataforma enquadra-se normalmente na transição de serviço, dado que altera a forma como entrega os serviços existentes sem necessariamente alterar a estratégia por detrás dos mesmos. Os recursos de IA na plataforma de destino também impactam cada vez mais esta etapa. Consulte IA em ITSM para compreender o que isto significa para o seu histórico de migração.
Nenhum fornecedor consegue satisfazer todas as necessidades de todas as empresas de serviços de TI. A decisão depende do volume de dados registados, da plataforma utilizada e da disponibilidade da API na sua origem. Help Desk Migration já realizou projetos de migração de dados de serviços de TI de diversas dimensões, tendo mais de 60.000 migrações ao longo do seu percurso. Compare Help Desk Migrationos clientes da com os da sua empresa, considerando o seu setor e plataforma, antes de tomar uma decisão.
Depende das plataformas ITSM específicas envolvidas e dos tipos de registos abrangidos. Help Desk Migration funciona com o ServiceNow, Jira Service Management, Freshservice, Zendesk, SysAid, Ivantie ManageEngine ServiceeDesk Plus, entre outros. Analise estudos de caso publicados sobre migrações específicas de ITSM semelhantes à sua plataforma antes de escolher um fornecedor.
As pessoas costumam chamar-lhe os 7 Rs. Provêm da migração de infraestrutura para a cloud: rehost (rehospedagem), replatform (reforma da plataforma), repurchase (recompra), refactor (refatoração), retire (desativação), retain (retenção) e relocate (relocação). Descrevem como move aplicações e cargas de trabalho para a nuvem, e não como move registos de help desk entre plataformas. Uma migração de help desk é um projeto à parte, com os seus próprios tipos de registo e a sua própria sequência. Veja como Help Desk Migration lida com isso.
ITSM, ou gestão de serviços de TI, abrange as práticas utilizadas para conceber, entregar e suportar serviços de TI: gestão de incidentes, gestão de mudanças, atendimento de pedidos e muito mais. É executado numa plataforma dedicada, como Jira Service Management, onde estes processos residem como registos estruturados. Consulte Migração para o Jira Service Management para saber como este conjunto de registos é transferido entre plataformas.
Pronto para migrar a sua central de serviços ITSM?
Execute uma migração de demonstração gratuita para testar os seus dados reais na plataforma de destino. Sem ambiente de teste, sem dados fictícios. Os seus registos reais, no lugar certo, prontos para a inspeção.
Agendar uma consulta de migração
Sem cartão de crédito Certificado SOC 2 Mais de 40.000 migrações concluídas