Partilhar via


Fluxo de trabalho sugerido para uma migração de dados complexa

Este artigo sugere um processo passo a passo para migrar grandes quantidades de dados. Ao transferir dados de um CRM poderoso baseado em nuvem, é importante planejar cuidadosamente devido à sua configuração complexa, como objetos personalizados, links entre dados e IDs de registro exclusivos. Você precisa pensar nas etapas técnicas e em como a migração funciona na prática.

  • Abordagem técnica: abrange as principais etapas de migração — extraindo, transformando e carregando dados no Dataverse — enquanto garante a integridade, preserva relacionamentos e otimiza o desempenho por meio da validação e do tratamento de erros.
  • Abordagem funcional: abrange tarefas de migração funcional, como segmentação e arquivamento de dados, e destaca a necessidade de envolver as partes interessadas do negócio para garantir que os dados atendam às suas necessidades.

Abordagem técnica para a migração de dados

Garanta uma migração suave seguindo uma abordagem estruturada — extraia, transforme e carregue dados, preservando a integridade e minimizando interrupções.

Diagrama ilustrando um fluxo de trabalho de migração de dados com seis círculos interconectados como etapas.

Extrair dados da origem para a base de dados de teste

Para migrações de dados complexas, recomendamos o preparo de dados em um banco de dados separado (por exemplo, SQL Server). Esta área de preparação captura um instantâneo do sistema de origem sem interromper as operações empresariais em andamento.

Considerações-chave:

  • Carga total versus carga delta: organize os dados como cargas completas ou incrementais (delta). Utilize carimbos de data/hora gerados automaticamente para monitorizar a chegada de dados e identificar alterações para carregamentos futuros.
  • Processamento de ativação pós-falha: projete o processo para ignorar registos com falha (por exemplo, devido ao comprimento do campo, pesquisas inválidas) sem interromper a migração Registre e resolva problemas antes de reprocessar.
  • Mapeamento de campo: converta valores de origem para corresponder aos formatos de destino na camada de preparo e aos intervalos de valores no banco de dados de preparo antes de migrar os dados para o Dataverse para melhorar a eficiência.
  • Validações de dados: execute verificações de integridade para detetar problemas como referências ausentes. Como a extração de dados pode durar horas ou dias, use a camada de preparo para filtrar registros incompletos e garantir a consistência.
  • Visualização de dados: use o banco de dados de preparo para auditar e analisar dados — por exemplo, contar registros ou somar campos financeiros — antes da migração final.

Transformar dados na base de dados de teste de destino

Depois de extrair dados do sistema de origem, transforme-os em um banco de dados de preparo de destino que espelhe o esquema Dataverse e contenha valores prontos para inserção ou atualização direta.

Principais etapas de transformação:

  • Mapeamento de campo: Mapeie colunas de origem para colunas Dataverse de destino. Use scripts para unir e mesclar tabelas onde necessário.

  • Conversão do conjunto de opções: Converta valores de conjunto de opções baseados em texto em inteiros do Dataverse usando uma tabela de mapeamento (por exemplo, OptionSetMapping) e consultas de atualização em massa. Crie uma tabela para padronizar e automatizar a transformação de valores de conjuntos de opções de sistemas de origem para sistemas de destino.

    Tabela: OptionSetMapping

    Nome da coluna Tipo de dados
    Nome da tabela de origem cadeia (de caracteres)
    Nome da tabela de destino cadeia (de caracteres)
    Texto de origem cadeia (de caracteres)
    Texto alvo cadeia (de caracteres)
    Valor alvo cadeia (de caracteres)

    Use a tabela OptionSetMapping para transformar e atualizar eficientemente os valores do conjunto de opções em massa. Por exemplo, para atualizar todos os valores do conjunto de opções na tabela Contact com base nos valores de texto correspondentes:

    Update C.\<OptionsetValue\> = M.\<TargetValue\> 
    FROM Contact C 
    JOIN OptionsetMapping M 
      ON C.OptionsetText = M.TargetText 
      AND M.TargetTableName = 'Contact'
    
  • Evite GUIDs personalizados: Deixe o Dataverse gerar GUIDs para evitar problemas de fragmentação e desempenho.

  • Verificações de comprimento de string: Certifique-se de que os valores de cadeia de caracteres se ajustem aos limites do Dataverse. Corte ou ajuste conforme necessário.

  • Campos calculados: Adicione campos derivados (por exemplo, Nome para pesquisas) se faltar na fonte.

  • Outra consideração: Ao projetar tabelas para corresponder ao esquema Dataverse, considere as seguintes colunas principais e tabelas de suporte.

    • DataMigration_CreatedDateTime: Carimbo de data/hora preenchido automaticamente para monitorizar lotes de carregamento de dados.
    • Sinalizador de ação: indica Inserir (I), Atualizar (U) ou Excluir (D).
    • Sinalizador de processamento: rastreia o status — Processado (P), Não processado (U), Erro (E) ou Sucesso (S).
    • Coluna exclusiva: use uma ID exclusiva (por exemplo, a ID exclusiva do sistema de origem) para mapear registros.
    • Tabelas de sucesso/erro: mantenha tabelas separadas (por exemplo, Contact_Success, Contact_Error) para registrar resultados e dar suporte a tentativas.

Tabelas de sequência e consultas de pré-carregamento

Após as transformações estáticas, ordene suas tabelas para reduzir as dependências cíclicas — casos em que as tabelas fazem referência umas às outras, impossibilitando importações isoladas. Use esta abordagem:

  • Listar todas as tabelas elegíveis para migração.
  • Conte pesquisas exclusivas por tabela (ignore campos predefinidos, como Created By, e outras pesquisas de tabela, se não estiver a migrar).
  • Classifique as tabelas em ordem crescente pelo número de consultas.
  • Inclua tabelas de relacionamento N:N, contabilizando ambas as procuras.
  • Exclua pesquisas em várias tabelas (por exemplo, campos "relativos").

Essa abordagem define a sequência de carga de migração de dados e funciona bem na maioria dos cenários. Para casos mais complexos:

  • Utilize um identificador exclusivo (por exemplo, importsequencenumber) para fazer corresponder registos entre teste e Dataverse quando são gerados GUIDs durante a inserção.
  • Separe os logs de sucesso e erros para evitar problemas de bloqueio e melhorar o desempenho.
  • Pré-carregue GUIDs de pesquisa de tabelas já migradas para resolver referências durante a inserção.
  • Lidar com dependências cíclicas da seguinte forma:
    • Inserção de registos sem pesquisas dependentes.
    • Atualizar essas pesquisas depois que os registros relacionados forem carregados.

Carregar dados no Dataverse

A próxima etapa é determinar e implementar sua abordagem para carregar dados no Dataverse.

  1. Ferramentas: Selecione uma ferramenta com base no tamanho e complexidade dos dados:

    • Ferramenta de migração de configuração do SDK
    • Azure Data Factory
    • KingswaySoft
    • Scribe
    • Transportador de dados da XrmToolBox
  2. Principais considerações (independente de ferramenta):

    • Lidar com dependências cíclicas: sequencie carregamentos de tabelas para minimizar pesquisas circulares. Insira registos sem pesquisas dependentes e, em seguida, atualize-os mais tarde.

    • Monitorizar IDs de registo: capture GUIDs do Dataverse numa tabela de sucesso e, em seguida, atualize a tabela principal usando um identificador exclusivo (por exemplo, importsequencenumber).

    • Otimize o tamanho do lote e o número de threads: revise as diretrizes para otimizar o desempenho de operações em massa. O aplicativo que você usa deve gerenciar erros de proteção de serviço que ocorrem quando números extraordinários de solicitações são enviados para o Dataverse. Se escrever o seu próprio código e utilizar a API Web do Dataverse, certifique-se de que repete os erros 429, conforme descrito em Limites da API de proteção de serviço. Se você usar o SDK do Dataverse, ele gerenciará esses erros para você.

      Para obter o desempenho ideal, ajuste o tamanho do lote e a contagem de threads com base na complexidade da tabela:

      • Tabelas de origem (OOB) (por exemplo, Contacto, Conta, Oportunidade Potencial): Essas tabelas são mais lentas devido a plugins e tarefas integradas. Recomendado: Tamanho do lote de 200 a 300, até 30 threads (se ≤10 consultas e 50 a 70 colunas).
      • Tabelas simples (poucas ou nenhumas consultas): Recomenda-se: Tamanho de lote ≤10, até 50 threads.
      • Tabelas personalizadas moderadamente complexas (algumas consultas): Recomendado: Tamanho do lote ≤100, até 30 threads.
      • Tabelas grandes/complexas (>100 colunas, >20 pesquisas): Recomendado: Tamanho do lote 10–20, até 10–20 threads para reduzir erros.
  3. Dicas de infraestrutura: para maximizar o desempenho da migração de dados, execute a migração de uma máquina virtual (VM) localizada na mesma região do ambiente Dataverse. Essa abordagem reduz significativamente a latência e acelera todo o processo. Saiba como determinar a região do seu ambiente Dataverse.

  4. Tratamento de erros: não ignore erros — resolva-os para evitar falhas em cascata. Utilize predefinições (por exemplo, pesquisas em branco, valores de conjunto de opções predefinidos) para inserir registos de marcadores de posição e capturar GUIDs.

  5. Atualizações de status: defina apenas o status ativo durante a inserção inicial do registro. Para registros inativos ou códigos de estado/status personalizados, atualize-os após a validação de dados. Para a maioria das tabelas personalizadas, as atualizações de status podem ocorrer imediatamente após a inserção. No entanto, para tabelas especiais como Caso, Oportunidade ou Lead, adie as atualizações de status até o final da migração. Depois que esses registros são fechados, eles não podem ser modificados, a menos que sejam reabertos, um processo demorado que coloca em risco a integridade dos dados.

  6. Propriedade e segurança: defina o proprietário do registro correto durante a inserção de dados, pois a segurança no nível do usuário e da unidade de negócios no Dataverse está vinculada à unidade de negócios do proprietário. Atribua a unidade de negócios certa na criação — atualizá-la depois remove todos os direitos de acesso.

    • Utilize utilizadores stub:
      • O Dataverse suporta usuários de stub (não licenciados), que são úteis para migrações grandes ou históricas. Os utilizadores de stub são automaticamente atribuídos à função de segurança de Representante Comercial — não renomeie ou modifique esta função. Os utilizadores stub podem ter registos se tiverem acesso de leitura ao nível do utilizador às tabelas relevantes.
    • Recomendações:
      • Crie todos os usuários não licenciados durante a migração com a unidade de negócios correta definida no momento da inserção.
      • Não altere a unidade de negócios após a criação — isso remove todas as funções, incluindo Vendedor.
      • Verifique se a função Representante de vendas tem acesso de leitura a todas as tabelas elegíveis para migração.
      • Mesmo os usuários desabilitados no ambiente Dataverse com essa função podem possuir registros.
  7. Tratamento de moeda: defina as taxas de câmbio durante a inserção usando um plug-in de pré-validação, pois o Dataverse não suporta taxas históricas.

Publicar o carregamento de dados no Dataverse

Depois de carregar os dados no Dataverse, siga estas etapas para garantir a integridade dos dados e minimizar os problemas de downstream:

  1. Atualize a tabela principal com GUIDs:

    • Após um carregamento bem-sucedido, copie os GUIDs do registro Dataverse da Tabela de Sucesso para a Tabela Principal usando um identificador exclusivo, como importsequencenumber.
    • Atualize o sinalizador de processamento para marcar os registros como:
      • P – Processado
      • E – Erro
      • U – Não processado Esta estratégia permite reexecuções eficientes ignorando registros já processados e suporta resolução de pesquisa em carregamentos subsequentes.
  2. Repetir registos com falha: Para reduzir a reformulação e manter a integridade referencial, considere estas ações:

    • Corte os valores da cadeia de caracteres se eles excederem os comprimentos permitidos.
    • Aplique valores de conjunto de opções padrão quando os mapeamentos estiverem ausentes.
    • Atribua um proprietário de fallback se o proprietário original não estiver disponível (mesmo como utilizador stub).
    • Use valores em branco ou padrão para pesquisas não resolvidas.
    • Até os registos de marcador de posição podem ajudar a criar os GUIDs necessários para as consultas em tabelas relacionadas.

Usando tabelas elásticas para migração de dados

As tabelas elásticas são projetadas para lidar com grandes volumes de dados em tempo real. Com as tabelas elásticas, pode importar, armazenar e analisar grandes volumes de dados sem problemas de escalabilidade, latência ou de desempenho.

As tabelas elásticas oferecem recursos exclusivos para esquema flexível, dimensionamento horizontal e remoção automática de dados após um período de tempo específico.

As tabelas elásticas são armazenadas no Azure Cosmos DB e suportam:

  • Dados sem esquema por meio de colunas JSON
  • Dimensionamento horizontal automático
  • Time-to-live (TTL) para exclusão automática de dados obsoletos
  • Particionamento para otimização de desempenho

As tabelas elásticas são mais adequadas para importações em massa com esquema variável.

As tabelas elásticas são ideais para tipos de dados específicos.

Tipo de dados Description
Dados brutos de ingestão Registos de origem, feeds de sensores ou exportações em massa de sistemas legados. Por exemplo, registos de interação com o cliente de um ERP legado, conversas de e-mail antigas e pedidos de suporte do sistema anterior.
Registos semi-estruturados Dados com campos opcionais ou em evolução que não se ajustam a um esquema rígido. Por exemplo, formulários de feedback do cliente com campos opcionais ou formulários de registro de eventos com anotações ou tags personalizadas.
Dados de preparação para validação Uma zona de retenção temporária antes de sincronizar dados com tabelas relacionais. Por exemplo, dados de leads importados aguardando desduplicação e validação antes de serem adicionados à tabela principal de leads.
Dados sensíveis ao tempo ou que expiram Use TTL (Time-to-Live) para exclusão automática de registros temporários do CRM. Por exemplo, códigos de desconto promocionais vinculados a uma campanha, links de acesso único para pesquisas com clientes ou portais de integração e respostas temporárias a pesquisas.
Dados em massa particionados Particione dados por ID ou categoria para melhorar o desempenho e a escalabilidade. Por exemplo, particione por ID de conta ou ID de região durante a migração de dados em massa ou segmente os logs de atividade do cliente por ID de campanha para análise.

Tipos de dados inadequados para tabelas elásticas

As tabelas elásticas são otimizadas para cenários flexíveis e de alta escala, mas nem todos os tipos de dados se adequam. Esta seção destaca padrões de dados comuns do CRM que são melhor armazenados em outro lugar para garantir desempenho, eficiência de custos e capacidade de manutenção. Saiba mais sobre as funcionalidades atualmente não suportadas em tabelas elásticas

Tipo de dados Reason
Dados altamente relacionais As tabelas elásticas não suportam junções ou pesquisas
Registros críticos para os negócios Sem integridade transacional ou suporte a plug-ins
Dados que requerem validação complexa Melhor processado em tabelas standard com regras de negócio

Segmentação funcional de dados e estrutura de arquivamento

Um planejamento técnico eficaz inclui a seleção das ferramentas e da infraestrutura certas, o alinhamento dos volumes de dados de origem e de destino e a configuração de processos de auditoria e reconciliação. Muitas migrações tornam-se complexas devido à falta de análise inicial, especialmente em torno de quais dados precisam ser movidos e para onde pertencem. Esta seção descreve os princípios fundamentais da análise de dados para dar suporte a uma migração bem-sucedida.

Segmentação de dados

A segmentação de dados é uma etapa fundamental na migração de um sistema CRM para o Dataverse. Organize tabelas de dados por função de negócios, como vendas, serviços ou marketing, para simplificar o planejamento e a execução da migração.

Segmentação de tabelas

Comece listando todas as tabelas qualificadas para migração, agrupadas por área de negócios (por exemplo, vendas, marketing, serviço). Em seguida:

  • Documente o esquema no Excel ou em uma ferramenta semelhante.
  • Execute consultas básicas no sistema de origem para verificar o uso da coluna.
  • Sinalizar colunas de baixo uso. Se menos de 5% dos registos contiverem valores, consulte as partes interessadas da empresa para decidir se os conserva ou elimina.

Essa análise simples pode reduzir significativamente o escopo da migração. Em sistemas de CRM de longa duração, é comum eliminar de 30 a 40% de colunas e até 20% de tabelas, simplificando o processo e melhorando o desempenho.

Relevância das colunas

Algumas colunas do sistema de origem são mapeadas diretamente para o Dataverse, enquanto outras se tornam campos calculados. Separe essas colunas e consulte as partes interessadas da empresa para decidir se os trabalhos de migração são necessários.

Ignore colunas que só são relevantes no sistema de origem ou que não são significativas no destino. Isto inclui muitos campos prontos de origem, como Criado por, Modificado por ou Número da versão da linha, a menos que sirvam a uma finalidade específica na sua migração.

Dados do tipo de ficheiro

Se o sistema de origem incluir dados de tipo de arquivo, sinalize esses campos antecipadamente e planeje uma estratégia de migração separada. Considere os seguintes tipos de arquivo:

  • Documentos do Office (por exemplo, Word, Excel, PowerPoint): para até 20.000 arquivos, migre para uma plataforma colaborativa como o SharePoint para habilitar o acesso multiusuário.
  • Ficheiros multimédia (por exemplo, imagens, vídeos): Escolha uma plataforma que suporte a reprodução. As opções incluem SharePoint, serviços de streaming ou outras soluções de armazenamento compatíveis com mídia.
  • Grandes volumes ou tamanhos de arquivo: se o custo de armazenamento for uma preocupação, use o Armazenamento de Blobs do Azure ou a coluna de arquivo nativa no Dataverse, que usa o Blob do Azure nos bastidores.
  • Proteção contra malware: execute arquivos por meio de uma ferramenta de deteção de malware (por exemplo, Proteção Avançada contra Ameaças do Azure) antes da migração para garantir a segurança.

Depois de analisar a relevância do arquivo, você geralmente descobre que o volume total de dados cai significativamente, especialmente em sistemas CRM de longa execução, tornando a migração mais eficiente.

Estratégias de arquivamento de dados

Alguns dados, como e-mails antigos, casos fechados ou leads desqualificados, continuam sendo importantes, mas raramente são acessados. Para reduzir o volume de migração sem interromper as operações de negócios, desenvolva uma estratégia de arquivamento inteligente.

Etapa 1: Identificar dados arquiváveis

Os candidatos comuns incluem:

  • E-mails com mais de três anos
  • Processos encerrados
  • Oportunidades perdidas
  • Leads desqualificados
  • E-mails de marketing, postagens e registos de auditoria

Revise seu sistema para identificar outras tabelas que você pode arquivar.

Etapa 2: escolha uma abordagem de arquivamento

  • Mantenha os dados no sistema de origem. Retenha algumas licenças de administrador para acesso enquanto desativa outras para reduzir custos.
  • Mover para armazenamento externo. Use bancos de dados locais, Armazenamento de Blobs do Azure ou Tabelas do Azure para armazenar registros arquivados. Essa abordagem reduz os custos de armazenamento e migração, mas requer uma estratégia de migração separada.
  • Use um ambiente Dataverse separado. Essa opção é menos comum, mas é útil se você quiser isolar dados arquivados. Pode retirar este ambiente mais tarde para simplificar o planeamento da transferência.

Para garantir uma migração de dados rápida e confiável para o Dataverse:

  • Use uma máquina virtual (VM) na mesma região do ambiente Dataverse para reduzir a latência e melhorar a velocidade de migração.
  • Escolha uma VM de alto desempenho. No mínimo, use uma VM D4 com oito núcleos, 28 GB de RAM e 500 GB de armazenamento para lidar com grandes volumes de dados de forma eficiente.
  • Prefira um banco de dados local na VM. Evite conexões remotas durante a migração. Se você usar o Azure Data Factory, implante-o na mesma região que seu ambiente Dataverse para obter o desempenho ideal.

Próximo passo