Imagine a situação: é sexta-feira à tarde. Sua organização está se preparando para uma migração em larga escala da plataforma de suporte durante o fim de semana. Na segunda-feira de manhã, suas equipes precisam ter acesso a anos de histórico de chamados, dados de clientes e fluxos de trabalho — sem interrupções ou perda de contexto.
Em situações como essa, a prioridade da migração torna-se crucial. Nem todos os registros precisam ser migrados na mesma ordem, e tratar todos os dados igualmente pode atrasar a transição. As equipes de suporte geralmente precisam de acesso imediato a chamados ativos, conversas recentes, clientes prioritários ou grupos específicos primeiro — enquanto os dados históricos podem continuar sendo migrados em segundo plano. Sem uma estratégia de migração clara e priorização definida, as equipes podem se deparar com dados incompletos, notificações duplicadas ou pressão operacional desnecessária durante a entrada em produção.
Uma migração expressa de help desk adota uma abordagem mais inteligente: a lógica de duas etapas. Primeiro, colocamos sua equipe em funcionamento e, em seguida, migramos seus dados históricos silenciosamente em segundo plano. Não se trata de deixar dados para trás, mas sim de migrar na ordem correta.
1. O que diferencia a Migração Expressa da Migração Padrão?
Uma migração padrão tenta mover tudo de uma só vez, num processo complexo: chamados abertos, registros fechados, anexos volumosos e logs do sistema. Para conjuntos de dados grandes, essa execução única facilmente ultrapassa o período padrão de uma noite.
Isso cria um período de limbo de vários dias. Os agentes são forçados a lidar com dois sistemas simultaneamente; ninguém sabe qual plataforma contém a verdadeira fonte de dados, e os erros se acumulam a cada hora.
Uma migração expressa do help desk elimina essa dor de cabeça. Ao estabelecer uma linha clara entre duas execuções direcionadas, esse modelo de migração do help desk sem tempo de inatividade mantém suas filas de suporte em movimento. Sem interrupções de vários dias. Sem agentes desamparados.
1. O que diferencia a Migração Expressa da Migração Padrão?
Uma migração padrão tenta mover tudo de uma só vez, num processo complexo: chamados abertos, registros fechados, anexos volumosos e logs do sistema. Para conjuntos de dados grandes, essa execução única facilmente ultrapassa o período padrão de uma noite.
Isso cria um período de limbo de vários dias. Os agentes são forçados a lidar com dois sistemas simultaneamente; ninguém sabe qual plataforma contém a verdadeira fonte de dados, e os erros se acumulam a cada hora.
Uma migração expressa do help desk elimina essa dor de cabeça. Ao estabelecer uma linha clara entre duas execuções direcionadas, esse de migração do help desk sem tempo de inatividade mantém suas filas de suporte em movimento. Sem interrupções de vários dias. Sem agentes desamparados.
- Etapa 1: Uma transferência completa do conjunto mínimo de dados viável que sua equipe precisa para dar suporte a clientes ativos desde o primeiro dia. Isso inclui chamados abertos, chamados pendentes, contatos, empresas e sua base de conhecimento ativa. Como esse conjunto de dados representa uma fração do seu arquivo total, a transferência é concluída facilmente durante a noite.
- Etapa 2: O arquivo histórico. Todo o resto, ou seja, seu arquivo de chamados fechados, é transferido em blocos gerenciáveis e calculados depois que sua equipe já estiver utilizando a nova plataforma. Sem pressa, sem pânico nos fins de semana e zero interrupção no seu suporte diário.
Sua equipe concluiu a troca de plataforma com sucesso e dentro do prazo. O histórico pesado continuou sendo processado com segurança em segundo plano.
1.1plainda Lógica de Duas Execuções
Considere a Etapa 1 como uma aula magistral de "carregamento lento". Em vez de fazer o usuário esperar até que todos os elementos pesados do rodapé, scripts de rastreamento e imagens de fundo sejam carregados, você renderiza o conteúdo essencial acima da dobra para que ele possa começar a interagir com a página imediatamente.
Na manhã de segunda-feira, seus agentes precisam apenas do essencial: conversas ativas, perfis de clientes atualizados e documentação técnica para resolver os chamados. Eles não precisam de um chamado resolvido há três verões para cumprir os SLAs do primeiro dia.
A segunda etapa é o carregamento assíncrono em segundo plano. Ela preenche o restante do arquivo histórico de acordo com suas necessidades, muito tempo depois da conclusão da transição crítica. Ambas as etapas compartilham o mesmo objetivo: uma transferência completa de dados. Essa abordagem de migração faseada simplesmente garante que sua equipe mantenha o controle total do cronograma operacional.
1.2 O que a Migração Expressa NÃO é
Para sermos claros: a migração expressa não se trata de economizar em detalhes ou excluir permanentemente seus arquivos. Todos os chamados fechados, resoluções anteriores e arquivos históricos são transferidos com segurança durante a Etapa 2. Todo o seu histórico chega intacto. Estamos alterando estrategicamente o cronograma de entrega.
A grande preocupação dos líderes de TI é que os dados históricos sejam abandonados. Mas isso não acontece. A Etapa 2 é uma fase essencial da engenharia, não uma mera formalidade. Para equipes vinculadas a estruturas de conformidade rigorosas, auditorias regulatórias ou modelos de sucesso do cliente, onde os agentes consultam constantemente interações antigas, concluir a Etapa 2 é uma parte indispensável do processo. A migração expressa é uma estratégia de sequenciamento, não uma exclusão seletiva.
2. Lista de verificação pré-migração: tudo o que precisa ser configurado antes da transferência de dados
Todas as tarefas desta seção devem ser finalizadas antes que a Etapa 1 inicie a movimentação de dados. Ignorar essas etapas é a maneira mais rápida de transformar uma migração noturna bem planejada em uma grande dor de cabeça interna. Use esta lista como seu principal checklist de migração helpdesk .
2.1 Desative as automações, notificações e gatilhos ativos na plataforma de destino
Quando registros antigos são importados para uma plataforma em produção, o mecanismo de automação do sistema os interpreta como eventos totalmente novos. Se as suas regras de negócio estiverem ativas, elas serão acionadas instantaneamente.
O resultado é um pesadelo de notificações em massa: milhares de e-mails obsoletos e confusos são enviados aos clientes sobre chamados resolvidos há meses. Pior ainda, os cronômetros de SLA são reiniciados incorretamente com base em dados históricos, e regras de roteamento ativas puxam acidentalmente registros inativos para as filas live agent .
Esta é a etapa mais frequentemente ignorada na lista de verificação para a migração helpdesk e é a que causa os danos operacionais mais graves quando negligenciada.
Antes de iniciar a Etapa 1, acesse o painel de administração da plataforma de destino e desative todas as automações, gatilhos de notificação e regras de negócios ativas:
- Zendesk: Administração > Regras de Negócio > Acionadores
- Freshdesk: Administrador > Fluxos de trabalho > Automações
- Intercom: Configurações > Caixa de entrada > Automação
2.2 Verificar a criação de agentes e mapear os perfis de equipe no alvofront
A falha em configurar a correspondência de agentesfront causa o abandono de tickets. Os registros chegam à nova plataforma sem um responsável válido, sendo atribuídos por padrão a um usuário do sistema não monitorado. Em um ambiente de suporte ao vivo, tickets abandonados levam diretamente a conversas perdidas e níveis de serviço comprometidos.
Antes de iniciar a Etapa 1, verifique se todos os perfis de agentes ativos e históricos existem na plataforma de destino. Em seguida, abra o mapeamento no Assistente de Migração para vincular as identidades de origem e destino. A maneira mais simples de garantir uma correspondência automática é usar endereços de e-mail idênticos em ambas as plataformas. Se as convenções de e-mail forem diferentes, mapeie esses usuários manualmente antes que os dados comecem a ser transferidos.
3. Passo 1. Abrir bilhetes durante a noite
Objetivo: Fazer com que sua equipe esteja trabalhando na plataforma alvo na manhã seguinte.
A primeira etapa é a mais sensível ao tempo em todo o processo. Cada decisão sobre o que incluir e excluir se resume a uma única pergunta: a equipe precisa disso para começar a trabalhar na segunda-feira?
3.1 O que incluir na Etapa 1
Limite a transferência inicial ao necessário para que seus agentes gerenciem as filas de atendimento ao vivo e migrem os chamados abertos para os novos ambientes helpdesk de forma eficiente:
- Chamados abertos e pendentes: Isso representa sua carga de trabalho operacional em tempo real e seu backlog de chamados ativos atual. Todo o restante aguarda a Etapa 2.
- Contatos e empresas associados: O contexto é tudo. Importar um ticket sem o perfil de cliente correspondente interrompe o fluxo da conversa e atrasa o trabalho dos seus agentes.
- Artigos da base de conhecimento em todos os idiomas: Sua base de conhecimento é uma ferramenta operacional vital. Os agentes precisam de acesso instantâneo à documentação interna e as centrais de autoatendimento devem permanecer ativas para os clientes desde o momento da transição.
3.2 O que excluir da Etapa 1
- Histórico de chamados fechados e resolvidos: Isso pertence inteiramente à Etapa 2. Mover esses registros para a sua execução inicial adiciona um volume enorme de dados, aumentando perigosamente o tempo disponível durante a noite para ativos que ninguém usará na segunda-feira de manhã.
- Anexos de registros arquivados: Os anexos introduzem um volume totalmente desproporcional ao seu valor operacional imediato durante uma transição. Adie-os para a Etapa 2. (Anexos vinculados a chamados ativos e abertos podem ser incluídos se o seu período noturno permitir largura de banda suficiente.)
- Histórico de atividades do agente: Os registros históricos de auditoria interna e os históricos de desempenho com o arquivo de chamados fechados devem permanecer no arquivo original e serem movidos juntamente com o arquivo histórico.
Manter a Etapa 1 enxuta é essencial para garantir que o lançamento durante a noite seja possível. Cada megabyte eliminado da execução inicial é uma garantia para o lançamento na manhã de segunda-feira.
3.3 Usando a migração multithread para atingir sua janela de transição
Os limites da API da plataforma de destino representam o limite absoluto de velocidade de qualquer migração digital. Um mecanismo de migração padrão, de thread única, processa as solicitações sequencialmente. Isso resulta em uma perda significativa de desempenho, com uma velocidade muito inferior à que a nova plataforma consegue suportar.
Executar uma migração helpdesk multithread altera os cálculos. Ao executar várias threads de requisição simultâneas, o processo de importação é forçado ao limite absoluto da capacidade da API da plataforma de destino.
Por exemplo, um conjunto de dados de 50.000 tickets que leva 8 horas para ser transferido em uma única thread pode ser concluído em 3 a 4 horas por meio de uma transferência multithread. Essa economia de tempo geralmente representa a diferença entre uma implementação bem-sucedida e deixar seus agentes frontsem um sistema ativo no início do turno.
Você obtém suporte a multithreading automaticamente com nosso Pacote de Serviço Signature, e nós o recomendamos fortemente para a Etapa 1. Lembre-se apenas de que os limites da API variam bastante dependendo do seu fornecedor e plano. Um plano Freshdesk Growth tem limites muito mais restritos do que uma conta Enterprise, e Zendesk dimensiona suas velocidades estritamente por nível. Não tem certeza se sua configuração suporta uma janela de transição noturna? Consulte nossa equipe de engenharia antes de definir uma data de migração em seu cronograma.
3.4 Etapa 1: Do lançamento na sexta-feira à ativação do sistema
Inicie o assistente de migração na sexta-feira à noite. Acompanhe o fluxo de dados pelo painel de controle em tempo real e não feche a aba do navegador (as atualizações são enviadas automaticamente). Não perca tempo atualizando a página manualmente; notificações automáticas chegam à sua caixa de entrada assim que a tarefa for concluída.
Assim que a Etapa 1 terminar, passe diretamente para as etapas seguintes:
- Migre imediatamente todos os canais de comunicação para a plataforma de destino. Ative o encaminhamento de e-mails, substitua os widgets de chat ao vivo do seu site e direcione os links da sua central de ajuda para a nova plataforma. Isso impedirá que todo o tráfego de novos clientes acesse o sistema antigo.
- Defina a plataforma de origem como somente leitura. Remova as permissões de edição da sua equipe ou adicione um aviso de somente leitura. O antigo help desk agora é apenas uma fonte somente leitura, não um espaço de trabalho ativo.
Isso prepara sua equipe perfeitamente para a manhã de segunda-feira. Seus agentes fazem login e trabalham na nova plataforma, mas o sistema antigo não pode receber nem gerar novas conversas.
3.5 O que acontece se a Etapa 1 não for concluída até de manhã?
Se novos chamados chegarem ou conversas existentes forem atualizadas durante o período de migração, a Migração Delta funciona como uma camada de sincronização integrada. Ela transfere automaticamente os registros recém-criados e atualizados recentemente após a passagem inicial da migração.
A migração Delta verifica seu antigo sistema de help desk em busca de novas atividades após da Etapa 1 e as sincroniza com seu novo espaço de trabalho. Como a sincronização Delta captura esses chamados pendentes silenciosamente em segundo plano, seus agentes podem começar a trabalhar imediatamente na segunda-feira de manhã, sem perder nenhum dado.
Você precisa executar a Migração Delta em até 10 dias após a conclusão da fase inicial de migração, e ela está incluída no nosso plano Signature. Muitas equipes também mantêm a plataforma anterior disponível em modo somente leitura durante o período de transição, dando aos agentes acesso a dados históricos de referência enquanto o novo ambiente de trabalho se estabiliza completamente.
4. Lançamento no primeiro dia: as etapas finais de transição
Este é o fluxo de trabalho oficial para o dia da entrada em produção. Siga exatamente estes passos antes que a equipe comece a trabalhar na segunda-feira de manhã.
4.1 Alternar todos os canais de comunicação para a plataforma de destino
Migre o tráfego de seus clientes para o novo sistema. Direcione o encaminhamento de e-mails de suporte para a nova caixa de entrada, atualize o código do chat ao vivo do seu site e redirecione os URLs da sua central de ajuda. Esse redirecionamento de canal é invisível; seus clientes não notarão nada, pois todos os seus pontos de contato habituais permanecem idênticos. Faça isso antes que os agentes iniciem o primeiro turno.
4.2 Defina a plataforma de origem como somente leitura
Bloqueie o sistema antigo e imponha o status de somente leitura para que os agentes não o utilizem acidentalmente. Revogue as permissões de edição ou adicione um aviso claro direcionando-os para a nova plataforma. Se um agente atualizar um ticket na fonte de dados em modo somente leitura por hábito, isso criará uma enorme bagunça de dados que arruinará o objetivo da migração realizada durante a noite.
Sua equipe ainda poderá acessar o sistema para consultar o contexto de conversas antigas, mas o sistema antigo estará fechado para novos trabalhos a partir da migração.
4.3 Execute a Migração Delta para detectar quaisquer atualizações de tickets que tenham sido perdidas
Mesmo com a Etapa 1 concluída sem problemas, você ainda precisa recuperar quaisquer tickets que tenham mudado de mãos enquanto a sincronização estava em andamento. Inicie a migração Delta como parte da sua transição, logo antes que sua equipe faça login. Observe que esse recurso está disponível no plano Signature e deve ser iniciado em até 10 dias após a conclusão para garantir que seu novo espaço de trabalho esteja atualizado.
4.4 Realize uma reunião de equipe de 10 minutos antes do início do primeiro turno
Evite sessões de treinamento demoradas no dia do lançamento. Mantenha o foco na parte prática. No dia da entrada em operação, sua equipe precisa dar suporte aos clientes, não ficar assistindo a apresentações de slides.
Aborde exatamente quatro tópicos:
- Novas credenciais de login.
- Onde encontrar ingressos disponíveis.
- Como funcionam a pesquisa e o histórico.
- A quem devo contactar se algo parecer estar em falta.
Se você já utilizou um ambiente de teste (sandbox) ou executou uma migração de demonstração, seus agentes já conhecem a interface. Esta reunião rápida é apenas uma verificação de alinhamento, não um tutorial de funcionalidades.
5. Etapa 2: Movendo tickets fechados para blocos em segundo plano
Objetivo: Transferir todo o seu arquivo histórico sem interromper as operações em andamento.
Seus agentes já estão executando suas filas, então a intensa monitoração do tempo da Etapa 1 terminou. A Etapa 2 não tem um limite de tempo estrito. O único foco agora é a execução em segundo plano que evita:
- Impacto no desempenho live agent ou na velocidade do espaço de trabalho.
- Exceder a sua quota de API durante o horário comercial padrão.
5.1 Por que o histórico de chamados fechados ainda importa
Não confunda chamados fechados com dados inúteis. Eles são vitais por três motivos principais após a entrada em produção:
- Auditorias de Conformidade e Regulamentação: Dependendo do seu setor, você pode ser legalmente obrigado a reter conversas com clientes por anos. A Etapa 2 garante que sua retenção de dados esteja em total conformidade com as normas.
- Contexto do agente: Os clientes frequentemente mencionam problemas antigos. Quando um agente abre um novo chamado e vê um histórico em branco, ele está no escuro. Manter o histórico de chamados fechados disponível preserva soluções, anotações e preferências anteriores.
- Continuidade de Relatórios: Para acompanhar tendências de longo prazo, volumes sazonais ou pontuações históricas de CSAT, você precisa de todos os seus dados em um só lugar. Dados fragmentados significam métricas confusas e inconsistentes.
5.2 Dividindo seu arquivo em fases: como separar seus intervalos de datas
Use filtros de data para dividir seu enorme arquivo histórico em partes menores e mais fáceis de assimilar. A estratégia mais inteligente é migrar de trás para frente. Comece migrando os dados mais recentes, pois são esses que seus agentes ativos provavelmente consultarão com mais frequência.
Roteiro de Migração Faseada
| Fase | Escopo | Cronograma/Método | Status |
| Etapa 1. Dia da Entrada em Operação | Tickets abertos e em andamento + Base de Conhecimento migrada via sincronização noturna | Sincronização noturna | Ao vivo |
| Etapa 2. Arquivo Histórico | Bilhetes antigos encerrados e histórico de longo prazo | Carregamento em segundo plano | Em andamento |
Configure cada lote como uma tarefa de migração separada no Assistente de Migração. Segmentar seus dados dessa forma minimiza a sobrecarga do sistema. Se uma API de um fornecedor falhar durante a transferência, isso afetará apenas esse bloco isolado, em vez de forçar você a recarregar todo o database.
5.3 Utilizando a migração por intervalo para pausar durante o horário comercial
Utilizar a lógica de suporte a tickets de migração intervalada permite pausar a transferência de dados durante o horário de pico e retomá-la automaticamente à noite ou nos fins de semana.
Em vez de executar uma sincronização de dados massiva que consome seus limites de API e torna seu espaço de trabalho ativo mais lento, cada pausa de intervalo divide o trabalho em janelas inteligentes.
Isso mantém a Etapa 2 invisível para sua equipe:
- Sem lentidão para os agentes: Sua equipe de suporte não sofrerá com atrasos ou lentidão na interface durante os horários de pico.
- Construção silenciosa em segundo plano: O arquivo histórico é preenchido enquanto todos estão offline.
- Agendamento automático: Você não precisa iniciar e parar a ferramenta manualmente; ela gerencia o tempo para você.
Para equipes corporativas com alto volume de chamados e SLAs rigorosos, a migração por intervalo transforma uma grande carga de dados em um processo silencioso e em segundo plano.
5.4 Quanto tempo demora a Etapa 2?
Ao contrário da urgência da Etapa 1, a Etapa 2 não possui um prazo fixo.
Algumas empresas concluem suas transferências de dados históricos em apenas duas noites. Outras optam por uma abordagem mais conservadora, distribuindo o trabalho ao longo de duas a três semanas, executando processos em segundo plano apenas nos fins de semana.
Em última análise, o ritmo ideal da sua migração depende de três fatores:
- seu volume total de registros.
- limites da API da sua plataforma de destino.
- Quanta largura de banda você realmente tem disponível para monitorar as tarefas?.
Dica de especialista: Se o seu arquivo ultrapassar 200.000 registros ou se a sua equipe estiver sujeita a um cronograma de conformidade rigoroso, você não precisa fazer tudo sozinho. Nossa equipe de Serviços Profissionais pode dimensionar, dividir e executar a sincronização do seu histórico de ponta a ponta.
6. Observações sobre a duração da música específicas da plataforma
Embora o procedimento para a Etapa 2 seja sempre o mesmo, o cronograma exato de sincronização em segundo plano depende da plataforma que você está utilizando.
Cada central de atendimento tem seus próprios limites de taxa de API, regras de limitação de requisições e estruturas de dados. Por exemplo, a migração do Zendesk para Freshdesk exige uma estratégia de implementação diferente da Intercom para o Zendesk migração do Freshdesk para o Intercom ou do .
Os mesmos princípios se aplicam a projetos como a migração do Zendesk para Intercom , a Intercom para Freshdesk ou até mesmo uma Zendesk entre Zendesk consolidaçãoCada plataforma lida com estruturas de dados, conversas, anexos e sincronização de maneira diferente, o que pode influenciar o cronograma e o planejamento da migração.
Ao mesmo tempo, a maioria das plataformas modernas de help desk oferece planos empresariais ou complementos de API com maior capacidade de processamento, permitindo que grandes migrações sejam executadas significativamente mais rápido quando necessário. É por isso que migrações bem-sucedidas dependem menos de limitações técnicas rígidas e mais de planejamento inteligente, priorização e escolha da estratégia de migração certa para o seu cronograma operacional.
Aqui está uma breve descrição do que esperar de cada ecossistema para que você possa planejar seus lotes em segundo plano sem surpresas.
6.1 Migração para Zendesk Express
Zendesk limita as velocidades de extração e importação com base em limites de taxa de API rigorosos. Dependendo do seu plano, você pode esperar entre 400 e 700 solicitações por minuto. Uma helpdesk maximiza totalmente essa capacidade de processamento.
No entanto, você deve ajustar suas configurações previamente para evitar grandes loops de e-mail automatizados. Antes de executar a Etapa 1, faça login no Zendesk, acesse Administração > Regras de Negócios > Gatilhose desative todos os gatilhos ativos. Você também deve verificar as configurações ativas em Regras de Negócios > Automações.
Deixar pelo menos uma notificação ativa permite que a plataforma envie atualizações acidentais para clientes antigos, o que corrompe seus metadados históricos durante a transição.
Ao mesmo tempo, a migração também é uma oportunidade para limpar campos obsoletos ou desnecessários. Nem todos os campos legados precisam ser transferidos, e muitas equipes intencionalmente deixam para trás campos personalizados não utilizados para evitar sobrecarregar o novo espaço de trabalho.
6.2 Migração Freshdesk Express
Freshdesk dimensiona as velocidades de ingestão e importação com base em limites de taxa de API rigorosos. Dependendo do seu plano, você pode esperar de cerca de 40 solicitações por minuto em planos mais básicos a aproximadamente 1.000 no plano Enterprise. Se sua equipe opera em um plano Growth, essa menor taxa de transferência restringe bastante uma execução padrão durante a noite.
Gerencie seus blocos de dados ativos com cuidado para evitar bloqueios de integração em toda a conta. O uso da migração por intervalo permite pausar a transferência em segundo plano durante os horários de pico e retomá-la automaticamente quando o tráfego diminuir. Essa opção operacional evita que cargas pesadas de dados sobrecarreguem seu espaço de trabalho ou causem timeouts do sistema para os agentes de suporte ao vivo.
6.3 Migração Intercom Express
Intercom regula as velocidades de importação usando uma estrutura de cotas diárias exclusiva, em vez de limites por minuto. Dependendo do seu plano de contrato, os espaços de trabalho recebem um orçamento fixo de chamadas de API, que é reiniciado à meia-noite UTC.
Certifique-se de fronto conteúdo da Base de Conhecimento (BC) diretamente na Etapa 1. A inclusão antecipada dos artigos garante que live agente os recursos de IA financeira tenham um database de alta qualidade pronto para soluções desde o primeiro dia. Para formatos de dados legados que representam uma ameaça ao seu orçamento diário, verifique a cota restante no seu Hub de Desenvolvedores Intercom antes de definir a data de lançamento.
7. Perguntas frequentes sobre a migração expressa: gerenciando a sequência de migração em duas etapas
Quanto tempo demora a Etapa 1 da Migração Expressa?
Para equipes de suporte com menos de 50.000 chamados abertos e pendentes, a Etapa 1 geralmente é concluída durante a noite, em um período de 4 a 8 horas. A velocidade exata depende do volume bruto de registros, dos limites de taxa da API da plataforma específica e do uso de multithreading. Executar um teste rápido é a maneira mais fácil de avaliar o cronograma exato para sua plataforma.
Meus clientes saberão que mudamos de plataforma?
Não, se você direcionar seus canais de e-mail, widgets de chat e URLs do portal do cliente para o novo sistema antes que os agentes façam login. Suas principais linhas de comunicação permanecem idênticas; apenas o software de back-end que as gerencia muda. Feita corretamente, a mudança de plataforma é invisível para os usuários finais.
O que acontece aos bilhetes criados durante a Etapa 1?
A migração delta captura todos os tickets criados ou atualizados na sua plataforma antiga após o início da Etapa 1, movendo-os com segurança para o novo destino. Essa rede de segurança elimina quaisquer lacunas de dados durante o período de transição. Lembre-se apenas de iniciar a sincronização delta em até 10 dias após a conclusão da Etapa 1. Essa opção está disponível no plano Signature.
Preciso desativar as automações antes da migração?
Sim. Ignorar esta etapa é um erro extremamente caro em uma migração para o Express. Manter gatilhos ou fluxos de trabalho automatizados ativos no seu novo sistema durante a importação faz com que a plataforma dispare milhares de notificações antigas para contatos de clientes antigos. Isso também distorce permanentemente os temporizadores de acompanhamento de SLA em todo o seu histórico.
Quando devo usar serviços profissionais em vez de recorrer ao autoatendimento?
Recomendamos serviços profissionais para migrações complexas envolvendo mais de 200.000 registros, prazos de transição rigorosos de acordo com o SLA ou mapeamentos complexos de campos personalizados. Se você estiver consolidando várias plataformas de origem em uma só, nossa equipe de engenharia pode definir o escopo, mapear e executar toda a sequência com segurança em seu nome.
8. Configuração recomendada para migração expressa
Se sua equipe de suporte estiver trabalhando com um databaselimpo (ou seja, com menos de 50.000 chamados ativos e abertos) e você tiver um fim de semana inteiro pela frente, nosso assistente de autoatendimento dará conta do recado facilmente. Basta configurar a Etapa 1 no seu painel, marcar os itens da sua lista de pré-migração e clicar em "Iniciar".
Mas quando databasesão enormes ou cheios de dados legados, as coisas se complicam. Se você quer que sua equipe faça login sem problemas na segunda-feira de manhã, seu sucesso depende inteiramente de como você aproveita dois recursos essenciais de engenharia:
- Migração Multithread: Este protocolo força a API da plataforma de destino a utilizar todo o seu potencial de desempenho para reduzir o tempo da Etapa 1. Disponível no nosso Pacote de Serviços Premium, esta é a sua principal ferramenta para processar grandes volumes de dados no primeiro dia.
- Migração por Intervalo: Este recurso gerencia completamente as transferências de arquivos históricos da Etapa 2 durante o seu horário comercial. Como ele pausa automaticamente o carregamento de dados durante o dia e o retoma à noite, a sincronização em segundo plano nunca interfere no desempenho dos seus frontde suporte.
Se você está lidando com um prazo apertado para o término de um contrato de software, volumes enormes de arquivos ou uma combinação de plataformas extremamente restritiva, uma abordagem do tipo "faça você mesmo" pode não ser suficiente. Nossa equipe de serviços profissionais está à disposição para mapear sua arquitetura específica e gerenciar todo o seu projeto de migração do início ao fim.
Migração Expressa: Viva até segunda-feira, arquive no seu horário
Uma migração expressa une velocidade e segurança de dados. Seus agentes de suporte simplesmente acessam a nova plataforma na segunda-feira de manhã e começam a trabalhar, enquanto seus arquivos históricos são atualizados silenciosamente em segundo plano, em um ritmo que se adapta ao seu fluxo de trabalho.
A lógica principal não muda com base no seu fornecedor de help desk. Enviar primeiro os dados essenciais do primeiro dia e, em seguida, transmitir os arquivos de longo prazo é uma estrutura que funciona para qualquer configuração empresarial. Os únicos elementos realmente variáveis são as suas métricas de tempo específicas:
- A velocidade da Etapa 1 depende inteiramente do seu volume de tickets ativos e dos limites da API da plataforma.
- A segunda etapa cronograma com base na profundidade total do seu arquivo e nas janelas de sincronização diárias.
O resultado é previsível. Você terá zero tempo de inatividade operacional, nenhum agente sobrecarregado com dois sistemas diferentes e zero risco de envio acidental de e-mails incomodando seus clientes.
Gerenciar uma infraestrutura empresarial complexa significa olhar além da transição inicial de fim de semana. Confira nosso Guia Completo de Migração de Dados para auditar toda a arquitetura do seu pipeline de dados ou leia o Guia de Migração com IA para configurar sua nova plataforma para ferramentas de suporte automatizadas.
