Muitos guias dizem que a migração de um help desk demora 4 a 12 semanas. Este intervalo descreve um projeto planeado e testado manualmente, com a transferência criada de raiz. Com uma ferramenta de migração testada, a maior parte destas semanas simplesmente não acontece: o mapeamento demora minutos num assistente, um teste demora minutos e a transferência é executada em segundo plano enquanto a sua equipa continua a trabalhar.
O fator decisivo são as plataformas. Zendesk permite 200 pedidos de API por minuto no plano Team e 2.500 no Enterprise Plus (Zendesk Documentação para Developers). Halo limita a utilização da API a 300 chamadas a cada cinco minutos (HaloFair Use Policy). Desde 2 de março de 2026 que a Atlassian cobra pelas Jira Cloud com base numa quota horária por pontos (Atlassian Developer). Abaixo encontrará os tempos típicos por tipo de projeto, volume de dados e plataforma, bem como as etapas que compõem um projeto de migração.
Quanto tempo demora um projeto de migração de help desk, do início ao fim?
A transferência de dados é apenas uma etapa. A maior parte do projeto envolve preparação e verificação, por isso planeie todo o cronograma, e não apenas a execução.
Preparação Help Desk Migration : 10 passos antes da entrada em funcionamento
Comece por definir os objetivos do projeto e auditar os registos existentes. Em seguida, limpe os dados, configure a plataforma de destino e teste o mapeamento de campos. Cada etapa ajuda a evitar atrasos e problemas com os dados. Veja de seguida um resumo das principais etapas de migração e os seus respetivos cronogramas.
| Fase | O que fazer | Tempo típico |
|---|---|---|
| 1.º Defina o âmbito e os objetivos | Definam em conjunto os motivos da mudança, a plataforma de destino e a data de lançamento | 1 a 2 dias |
| 2.º Alinhe a equipa | Nomeie um responsável pelo projeto, informe os agentes e os gestores e defina um prazo de transição | 1 a 3 dias |
| 3.º Audite os seus dados | Liste o que tem: bilhetes, contactos, empresas, anexos, campos personalizados, macros | 2 a 5 dias |
| 4.º Decida o que migrar | Marque os dados como "devem ser movidos", "mover mais tarde" ou "arquivar". Geralmente, é seguro deixar de fora os chamados fechados mais antigos | 1 a 2 dias |
| 5.º Limpe os dados | Mesclar duplicados, fechar chamadas obsoletas, remover itens indesejados | 2 a 7 dias |
| 6.º Prepare o alvo | Configure campos personalizados, agentes e automatizações para que os registos importados tenham um destino final | 3 a 10 dias |
| 7. Execute uma migração de demonstração | Teste numa amostra, verifique o mapeamento de campos e anexos e corrija os problemas | 1 a 3 dias |
| 8. Migração completa | Transferir todos os registos (de horas a vários dias, dependendo do volume e dos limites da API) | 1 a 5 dias |
| 9.º Transição | Mova os registos criados desde a execução completa e troque os agentes | 1 dia |
| 10.º Verificar e dar apoio | Comparar contagens de registos, verificar dados pontuais e treinar agentes | 1 a 2 semanas |
Em geral: a maioria dos projetos de migração completos demora 2 a 6 semanas, e a transferência de dados demora geralmente menos de uma semana. As fases 3 a 6 podem sobrepor-se, pelo que iniciar o planeamento com antecedência é a melhor forma de encurtar o projeto.
O Processo de Migração: cronogramas estimados de migração por dimensão e complexidade do projeto
A tabela abaixo resume cada etapa de um projeto para três cenários comuns. Os tempos de transferência são provenientes dos nossos registos. As restantes etapas são intervalos de planeamento com base nas durações das etapas descritas posteriormente neste artigo.
| Cenário | Configuração e demonstração | Correções de teste e mapeamento | Migração completa (transferência) | Delta e transição | Total típico |
|---|---|---|---|---|---|
| Configuração pequena e padrão: menos de 10 mil registos, poucos campos personalizados. | 15–30 min | 1–2 h | Aproximadamente 35 minutos (9 em cada 10 em aproximadamente 4,5 horas) | 1–2 h | Aproximadamente 1 dia |
| Tamanho médio com campos personalizados: 10 mil a 100 mil registos, várias repetições de demonstração. | 1–2 h | 1 a 3 dias | Aproximadamente 4 horas (9 em cada 10 em aproximadamente 1 dia) | 2–4 h | 2 a 5 dias |
| Empresarial ou fusão de vários centros de atendimento: mais de 1 milhão de registos, objetos personalizados, meta de limite baixo | 1 a 2 dias de planeamento | 3 a 7 dias | Aproximadamente 2 dias (9 em cada 10 casos em aproximadamente 8,5 dias) | meio dia | 2 a 6 semanas |
Na maioria das vezes, num projeto de grande dimensão, o tempo é gasto em revisões e decisões, e não em tempo de máquina. É por isso que as maiores poupanças provêm de testes antecipados e de um âmbito bem definido. As dicas de aceleração abaixo abrangem ambos os aspetos.
Tempos típicos de migração de dados por volume de dados
A tabela abaixo mostra a duração da transferência de dados nas Help Desk Migration observadas, agrupadas pelo número de registos transferidos. As colunas indicam o número de execuções, a amplitude abrangida pela metade central das execuções, a mediana e o tempo em que 9 em cada 10 execuções foram concluídas.
| Volume de dados (registos) | Corridas | Gama típica (50% centrais) | Mediana | 9 em cada 10 terminam dentro de |
|---|---|---|---|---|
| Pequeno: menos de 10 mil | 496 | 15 min – 1,5 h | ~35 min | ~5 horas |
| Médio: 10 mil – 100 mil | 572 | 1,5 h – 11 h | ~4 h | ~1 dia |
| Grande: 100 mil – 1 milhão | 457 | 5 horas – 1 dia | ~12 h | ~2 dias |
| Muito grande: 1M+ | 263 | 21 horas – 5 dias | ~46 h | Aproximadamente 8,5 dias |
São tempos observados nas migrações reais, não uma fórmula. Abrangem rotas API-para-API em qualquer plano utilizado por cada cliente. As fontes de dados CSV, databasee caixa de correio operam a velocidades diferentes e, por isso, foram excluídas. Os mesmos 30.000 registos podem ser migrados numa hora ou demorar quase um dia inteiro, dependendo das plataformas descritas na secção seguinte.
Tempo de migração por plataforma (limites da API)
O limite da API de cada plataforma define a velocidade com que os registos podem ser lidos (exportação) ou escritos (importação). A tabela lista 13 plataformas com os seus limites de API documentados nos níveis padrão e superior, para além dos tempos observados de exportação e importação para migrações de aproximadamente 100.000 registos.
| Plataforma | Limite da API (padrão/nível superior) | Exportar, aproximadamente 100 mil registos | Importação, aproximadamente 100 mil registos | Notas |
|---|---|---|---|---|
| Zendesk | 200 / 2.500 rpm | 7 horas | 24 horas | alvo comum mais rápido |
| Freshdesk | 100 / 700 rpm | 6,5 horas | 23 h | Rápido nos dois sentidos |
| Freshservice | 100 / 500 rpm | 17 h | 23 h | Lento como fonte; a velocidade de exportação praticamente não aumenta com o volume |
| Jira Service Management | baseado em pontos (quota horária) | 25 h | 25 h | A taxa de transferência mais lenta, de longe, é de aproximadamente 1.250 registos por hora, independentemente do tamanho |
| Intercom | 10.000 rpm por aplicação; rotações mais elevadas sob encomenda | 5 horas | 5 horas | Rápido nos dois sentidos; limites contados a intervalos de 10 segundos |
| HubSpot Service Hub | 600 / 1.140 rpm | 1 hora | 6 horas | Exportação muito rápida |
| Salesforce Service Cloud | Diariamente: ~100 mil requisições/dia | 30 horas | 70 h | Limite diário; desaceleração acentuada acima de 1 milhão de registos (ver abaixo) |
| Zoho Desk | créditos diários | 2,5 horas | 13 h | Créditos diários; ampla distribuição |
| ServiceNow | configurável pelo administrador | 2 horas | 19 h | Depende dos limites da própria instância |
| Halo | 60 rpm (300 rpm necessárias / 5 min) | 4,5 horas | 12 horas | Limite mínimo documentado na tabela |
| Pylon | não documentado | n/a (apenas alvo) | 23 h | Confirme o limite com Pylon |
| Front | 50 / 200 rpm | 32 h | 20 horas | Limites baixos combinam com horários lentos |
| Gorgias | 120 rpm (40 req/20 s) | n / D | 19 h | Alvo lento |
Em novembro de 2026, os limites da API foram verificados em relação à documentação para os programadores de cada fornecedor. Os fornecedores alteram estes limites com frequência e a maioria vende planos superiores ou complementos, por isso verifique o seu próprio plano antes de planear uma migração. Para obter um valor exato para os seus dados,
A Relokia concluiu a migração Help Desk Migration da Vanta do Freshservice para o Jira Service Management em apenas 21 dias, transferindo mais de 128 mil tickets e preservando o histórico, anexos e a integridade do registo de auditoria. Veja como o fizemos:
Vanta: Mais de 128 mil tickets migrados em apenas 21 dias
A Relokia concluiu a migração Help Desk Migration da Vanta do Freshservice para o Jira Service Management em apenas 21 dias, transferindo mais de 128 mil tickets e preservando o histórico, anexos e a integridade do registo de auditoria. Veja como o fizemos:
Desde o lançamento do projeto até à sua conclusão com sucesso em apenas 21 dias, a Vanta migrou mais de 128 mil tickets, 512 mil comentários, 86 mil anexos e mais de 4,2 mil requerentes e agentes Freshservice para o Jira Service Management, preservando o contexto histórico e a integridade total do registo de auditoria.
O calendário apertado foi alcançado através de opções de migração automatizadas, definições personalizadas e uma abordagem iterativa. As imagens incorporadas foram transferidas como anexos de tickets, enquanto as etiquetas personalizadas baseadas em campos de grupo mantiveram os registos migrados organizados e fáceis de identificar.
O pacote de suporte Premium incluía a remigração, dando à Vanta tempo para aplicar as personalizações, validar os resultados e completar a transferência final sem prolongar o prazo de 21 dias do projeto.
O que influencia a duração de uma migração de dados?
Os limites da API definem o teto. Outros quatro fatores determinam o quão perto uma migração chega deste limite e o tempo que o projeto demora.
- Número de registos. Cada ticket traz os seus comentários; um ticket pode incluir centenas ou milhares de comentários, e cada comentário faz parte da transferência. O volume estabelece a base de referência.
- Anexos. Cada ficheiro é um upload separado, pelo que os anexos podem ser mais importantes do que a quantidade de tickets. Uma conta grande com poucos anexos pode ser concluída mais rapidamente do que uma conta mais pequena repleta de capturas de ecrã e PDFs. O número de ficheiros também é difícil de estimar antecipadamente, o que torna as migrações com muitos anexos as mais difíceis de prever.
- Considere os planos oferecidos por ambos os lados. A maioria dos fornecedores ajusta os limites da API de acordo com o plano escolhido — quanto maior for o plano, mais chamadas de API pode utilizar. Por exemplo, Freshservice oferece desde 100 pedidos por minuto no plano Starter até 500 no Enterprise, com pacotes adicionais que chegam aos 2.000 (Freshservice documentação da API).
- Consolidação de vários help desks num só. A consolidação não se trata de uma única migração, mas sim de várias para o mesmo destino. Cada origem executa a sua própria migração, e cada execução subsequente chega a um destino que já contém dados. Os nossos engenheiros técnicos podem avaliar os seus requisitos de migração e determinar se uma abordagem de migração paralela (multithread) ou sequencial proporcionará os resultados mais eficientes em termos de tempo. A Mayvik migrou os dados do Freshdesk, Zendesk, Desk.com e Groove para o Help Scout desta forma.
O nosso guia sobre os desafios da migração de dados de apoio ao cliente lista tudo o que pode atrasar um projeto, com soluções.
Cronograma de migração de dados, passo a passo
O tempo de transferência é apenas uma parte de um projeto de migração. O cronograma abaixo abrange todo o processo e quanto tempo demora normalmente cada etapa.
Passo 1: Mapeie os seus dados e execute uma Migração de Demonstração (15 a 30 minutos)
Portanto, aqui estão as principais opções que você pode considerar ao escolher uma forma de transição de dados:
Uma demonstração gratuita demora geralmente 15 a 30 minutos. No Assistente de Migração, liga as plataformas de origem e de destino (é necessário acesso de administrador em ambas). De seguida, escolhe os registos a transferir, associa agentes e grupos e mapeia os campos de organização, cliente, ticket e artigo. Os passos exatos de mapeamento variam de acordo com o par de migração. Também pode escolher opções automatizadas predefinidas para personalizar a importação.
A demonstração demora mais tempo se a configuração prévia à migração não for concluída. Antes de começar, reúna as credenciais de acesso para ambas as plataformas, crie perfis e grupos de agentes correspondentes no destino e configure os campos personalizados de tickets necessários. Com muitos campos personalizados, planeie várias rondas de mapeamento em vez de apenas uma.
Passo 2: Analise os resultados da demonstração (de alguns minutos a 2 horas)
A análise de uma demonstração demora alguns minutos. Testar os resultados de uma migração completa de dados demora pelo menos 1 a 2 horas. A demonstração espelha a migração completa; portanto, se algo não for migrado na demonstração, também não será migrado na migração completa. Execute a demonstração as vezes necessárias para ajustar o mapeamento.
Verifique se:
- Os comentários têm os autores corretos
- Os tickets são atribuídos aos agentes corretos
- Os campos personalizados contêm os valores corretos
- Empresas e clientes estão interligados
- Os acessórios chegam com os seus nomes
- Os artigos devem estar nas secções e categorias corretas
- Partilhar o acesso à migração permite que a sua equipa ajude na validação.
Partilhar o acesso à migração permite que a sua equipa ajude na validação.
Passo 3: Prepare a sua equipa e o help desk alvo (menos de 2 horas)
Comece a integrar os agentes o mais cedo possível. O tempo necessário depende do número de agentes e da plataforma alvo. A transição em si é rápida:
- Desative as automatizações no alvo ou solicite uma etiqueta: 5 a 30 minutos
- A equipa de suporte deixa de funcionar na origem: 5 minutos
- Desligue os canais de comunicação na fonte: 5 a 15 minutos
- Ativar os canais de comunicação no alvo: 15 minutos a 1 hora
Passo 4: Execute a migração completa (de horas a dias)
Este é o tempo de transferência apresentado nas tabelas de volume e de plataforma. A sua equipa pode continuar a trabalhar no help desk de origem enquanto a migração é executada. Pode acompanhar o progresso na tabela de registos, que mostra os registos recuperados e transferidos, e receberá um e-mail quando a migração estiver concluída. Se a execução precisar de ser realizada em horário comercial, a Migração por Intervalo permite-lhe pausar e retomar a Migração Completa em coordenação com a nossa equipa.
Passo 5: Execute uma migração delta para novos registos
Os tickets criados ou atualizados na origem durante a Migração Completa podem ser movidos posteriormente com a Migração Delta, disponível no plano Premium. Valide o resultado antes de transferir os agentes para o destino.
8 formas de acelerar a migração de dados
Para acelerar a migração de um help desk, ITSM ou RMM, pode adotar diversas medidas para reduzir o tempo de transferência de dados, simplificar o planeamento e evitar atrasos desnecessários. Desde a otimização dos limites da API e a limpeza dos dados de origem até à simplificação do mapeamento de campos e à utilização da migração paralela, a abordagem correta pode tornar todo o projeto mais rápido e previsível. Considere as seguintes formas de acelerar a sua migração sem comprometer a precisão dos dados ou a continuidade do negócio.
- Solicite ao fornecedor um aumento temporário do limite da API. Intercom aceita pedidos de limites mais elevados, Freshdesk vende chamadas API adicionais e Zendesk oferece um complemento de API de Alto Volume que aumenta os planos elegíveis para 2.500 pedidos por minuto.
- Ignorar anexos. A opção "Ignorar anexos" move registos sem
ficheiros. Apague os anexos de todos os tickets ou tickets atualizados há mais de 6, 12 ou 24 meses. Reduza o tempo de migração e os custos de armazenamento transferindo apenas os ficheiros de que a sua equipa necessita. Ideal para migrações grandes, ficheiros desatualizados e para evitar o excesso de armazenamento. - Filtre registos antigos ou irrelevantes. Menos registos significam menos chamadas à API. Não precisa de migrar tudo para a nova plataforma. Utilize as opções de filtragem no Assistente de Migração para selecionar quais os registos a transferir e eliminar dados irrelevantes, como todos os tickets ou tickets atualizados há mais de seis meses. Se os filtros padrão não corresponderem às suas necessidades, pode solicitar opções de filtragem adicionais à nossa equipa técnica. Podem ajudar a configurar filtros personalizados com base no âmbito da sua migração, para que transfira apenas os dados necessários, reduza as chamadas à API e poupe tempo de migração.
- Migração multithread com Help Desk Migration. Migre em paralelo. A transferência assíncrona e multithread é executada em threads paralelos, enviando vários pedidos em simultâneo em vez de um para um, o que reduz o tempo de espera pelas respostas. Combine com um limite de API mais elevado, uma vez que os pedidos paralelos ainda são contabilizados no limite. Disponível nos planos Premium e Enterprise.
- Faça um upgrade do plano durante a migração. Um plano de nível superior numa plataforma mais lenta aumenta frequentemente o limite da API durante o período de execução.
- Migre primeiro os registos mais recentes. Transfira primeiro os chamados mais recentes para que a sua equipa possa priorizar os problemas ativos dos clientes enquanto os registos mais antigos são migrados em segundo plano. Esta opção é ideal para períodos de inatividade limitados, suporte ininterrupto, orçamentos mais restritos e para testar os chamados ativos antes da migração completa. Disponível apenas para Migração Completa.
- Utilize a Migração Delta para a transição. Transfira os tickets criados ou atualizados na origem após a Migração Completa, garantindo que a sua nova plataforma tem os dados mais recentes antes da entrada em produção. Isto minimiza o tempo de inatividade e evita lacunas de dados. Disponível no plano Premium.
- Utilize a Migração por Intervalo para se adequar ao horário de expediente. Faça uma pausa na Migração Completa durante as horas de maior afluência e retome-a posteriormente. Pode fazer uma pausa até cinco vezes, por até cinco dias de cada vez, em coordenação com a nossa equipa.
Para migrações complexas, os nossos Serviços de Migração Gerida oferecem suporte especializado em planeamento, personalizações, mapeamento de dados, limites de API e validação para garantir uma transição suave com o mínimo de perturbações.
Pandora: Migração empresarial concluída em apenas 4 semanas
Em apenas 4 semanas, sem qualquer interrupção, Pandora concluiu uma migração empresarial do Zendesk para o Salesforce Service Cloud, consolidando os dados de apoio ao cliente em mais de 6.500 pontos de venda e para 37.000 colaboradores em todo o mundo.
A migração transferiu todo o histórico de tickets e clientes, gravações de chamadas, anexos, anotações internas, conversas paralelas e fluxos de trabalho comerciais, preservando as relações entre os dados.
Para manter o projeto dentro do cronograma, a equipa utilizou uma abordagem iterativa com cinco migrações de demonstração para validar o mapeamento e as configurações dos campos antes da transferência final. Os gatilhos do backend Salesforce foram temporariamente desativados para evitar bloqueios no sistema e garantir uma transição suave.
Migração manual, automatizada ou gerida: compare os prazos
Um script desenvolvido em equipa, uma ferramenta de migração de self-service e um serviço de migração gerido diferem principalmente no tempo gasto antes e depois da transferência, e não durante a mesma.
| Critério | Manual (script personalizado) | Ferramenta automatizada (self-service) para Help Desk Migration | Serviço de migração gerido pela Help Desk Migration e Equipa Técnica |
|---|---|---|---|
| Tempo de configuração | Semanas a meses a estudar ambas as APIs | Ligar e mapear em minutos com um assistente | A nossa equipa define o âmbito do projeto e mapeia os dados consigo |
| Testando | Construído e repetido pela sua equipa | Migração de demonstração num exemplo; execute novamente conforme necessário | Execuções de demonstração e um plano de validação do projeto |
| Lidar com limites da API | O seu código precisa de limitar a taxa de pedidos e tentar novamente | Integrado na ferramenta | Integrado, além de pedidos de limite de fornecedores planeados com antecedência |
| Campos personalizados, filtros, fusões | Independentemente do que a sua equipa construa | Mapeamento standard e opções automatizadas, com filtragem. Solicite filtros personalizados ou personalizações adicionais de migração à nossa equipa técnica para adequar o processo aos seus dados e às necessidades do seu projeto. | Filtragem personalizada, mapeamento personalizado, consolidação de múltiplas fontes |
| Duração típica do projeto | Semanas a meses | De algumas horas a alguns dias | De alguns dias a algumas semanas, dependendo do âmbito |
| Custo | Tempo de engenharia, muitas vezes escondido | Preços definidos por volume de gravação e opções, pacote de suporte (preços) | Cotado por volume de registos, opções, pacote de suporte (serviços de migração) |
Um serviço gerido não tem de significar código personalizado para cada projeto. A equipa da Help Desk Migrationutiliza o mesmo mecanismo testado da ferramenta de self-service, pelo que a velocidade da transferência permanece a mesma, mas o planeamento, o mapeamento e a validação ficam a cargo da sua equipa.
para ver como os seus próprios registos se comportam no seu percurso ou fale com um especialista sobre um projeto empresarial ou com várias origens de dados.
Perguntas frequentes
Nos nossos registos, as migrações com mais de 1 milhão de registos demoraram, em média, cerca de 46 horas. A metade intermédia das migrações foi concluída entre as 21 horas e os 5 dias, e 9 em cada 10 foram concluídas em cerca de 8,5 dias. Um alvo com um limite baixo, como Jira Service Management demoraria cerca de um mês, enquanto um com um limite diário, como Salesforce Service Cloud, prolongaria o tempo de execução para o limite superior desse intervalo. Adicionando alguns dias a uma semana para mapeamento e testes durante a transferência, um projeto com 1 milhão de tickets é geralmente concluído em uma a três semanas, e não em três meses.
Estes prazos descrevem frequentemente todo o projeto com uma abordagem manual ou personalizada: semanas de planeamento, uma migração de teste automatizada, a transferência e semanas de controlo de qualidade. Com uma ferramenta de migração testada, o mapeamento e os testes demoram minutos a dias, e a transferência em si demora horas para a maioria das contas. Projetos muito grandes ou com várias fontes ainda exigem um planeamento cuidadoso, mas um cronograma medido em meses geralmente significa muito trabalho manual.
Sim. Cada anexo é um upload separado, pelo que uma conta com muitos ficheiros pode demorar mais tempo do que uma conta maior com poucos ficheiros. Os artigos da base de conhecimento são geralmente poucos em comparação com os tickets, mas as imagens incorporadas e a estrutura do artigo (secções e categorias) aumentam o tempo de mapeamento e verificação. Se os anexos estiverem a tornar a transferência mais lenta, a opção "Ignorar anexos" move os registos sem os ficheiros.
Para os dados de help desk no Salesforce Service Cloud (casos, contactos e artigos da base de dados de conhecimento), Zendeskpara oSalesforce as migrações Salesforcecomeça a ter impacto na velocidade: ZendeskparaSalesforce desta dimensão demoraram, em média, 3,4 dias. Estes números não abrangem uma migração completa do Sales Cloud CRM. Consulte a nossa Salesforce Service Cloud de migração para obter informações sobre os registos suportados.
A migração paralela é executada em vários threads, enviando vários pedidos em simultâneo para reduzir o tempo de espera pelas respostas. É mais útil em contas grandes com muitos tipos de registo e menos eficaz se já estiver a atingir o limite da API do fornecedor; nesse caso, aumente primeiro o limite. Os registos relacionados, como os tickets e os seus requerentes, ainda são criados na ordem correta, e uma migração de demonstração permite verificar o resultado antes da execução completa.
Sim. Os agentes continuam a trabalhar no help desk de origem enquanto a Migração Completa é executada, uma vez que a transferência lê os dados através da API sem bloquear a conta. Desative primeiro as automatizações no sistema de destino, para que os tickets importados não acionem o envio de e-mails para os clientes. O guia de migração sem tempo de inatividade aborda a sequência de transição.
Os tickets criados ou atualizados na origem após o início da Migração Completa não fazem parte desta execução. Uma Migração Delta move-os numa etapa posterior, muito mais curta, para que os agentes possam migrar para o destino com o histórico completo. A Migração Delta está disponível no plano Premium. A lista de verificação geral de migração de dados mostra onde a Migração Delta se insere na transição.
Sim, com a Migração por Intervalo. Pode pausar a Migração Completa até cinco vezes, até cinco dias de cada vez, e retomá-la em coordenação com a Help Desk Migration . Por exemplo, pode manter os horários de pico de suporte livres de sobrecarga da API. A Migração por Intervalo não é a mesma coisa que a Migração Delta, que move os registos criados após a execução principal. Os passos de pausa e retoma estão na secção de ajuda "Primeiros Passos".
Durante uma Migração de Demonstração, o Assistente de Migração apresenta uma barra de progresso com a percentagem de dados de exemplo transferidos. Durante a Migração Completa de Dados, uma tabela de registos mostra quantos registos foram recuperados e transferidos. Receberá um e-mail quando a Migração de Demonstração ou a Migração Completa estiver concluída.
Compare o ambiente de destino com o de origem: contagem de registos por tipo, autores de comentários, responsáveis pelos tickets, valores de campos personalizados, anexos e categorias de artigos. Verifique uma amostra de tickets antigos, recentes e com muitos anexos e, em seguida, ative os gatilhos, automações e notificações no ambiente de destino. Recolha feedback dos agentes durante os primeiros dias no novo help desk. A lista de verificação pós-migração detalha cada uma destas verificações.
Primeiro, verifique a tabela da plataforma: uma execução lenta num destino com um limite baixo, como Jira Service Management, Haloou Front é geralmente normal. Se a contagem de registos na tabela de progresso não tiver sido alterada durante várias horas, um limite diário da API ou um token expirado pode ter colocado a execução em pausa. Nesse caso, contacte a nossa equipa de suporte com o seu ID de migração para que possam verificar os registos.
