Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo sugere um processo passo a passo para migrar grandes quantidades de dados. Ao transferir dados de um CRM baseado em nuvem eficiente, é importante planejar cuidadosamente devido à sua configuração complexa, como objetos personalizados, links entre dados e IDs de registro exclusivas. Você precisa pensar nas etapas técnicas e em como a migração funciona na prática.
- Abordagem técnica: aborda as principais etapas de migração, extraindo, transformando e carregando dados no Dataverse, garantindo a integridade, preservando relações e otimizando o desempenho por meio de validação e tratamento de erros.
- Abordagem funcional: abrange tarefas de migração funcionais, como segmentação e arquivamento de dados, e destaca a necessidade de envolver os stakeholders empresariais para garantir que os dados atendam às suas necessidades.
Abordagem técnica para migração de dados
Certifique-se de uma migração suave seguindo uma abordagem estruturada: extrair, transformar e carregar dados, preservando a integridade e minimizando a interrupção.
Extrair dados da origem para o banco de dados de preparo
Para migrações de dados complexas, recomendamos preparar dados em um banco de dados separado (por exemplo, SQL Server). Essa área de preparação captura um instantâneo do sistema de origem sem interromper as operações comerciais em andamento.
Principais considerações:
- Carga total versus delta: organize os dados como cargas completas ou incrementais (delta). Use carimbos de data e hora gerados automaticamente para acompanhar a chegada de dados e identificar alterações para cargas futuras.
- Tratamento de failover: projete o processo para ignorar registros com falha (por exemplo, devido ao comprimento do campo, pesquisas inválidas) sem interromper a migração. Registre e resolva problemas antes do reprocessamento.
- Mapeamento de campo: converta valores de origem para corresponder aos formatos de destino na camada de preparo e 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 capturar problemas como referências ausentes. Como a extração de dados pode abranger 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 em banco de dados de preparo de destino
Depois de extrair dados do sistema de origem, transforme-os em um banco de dados de preparo de destino que espelha o esquema dataverse e contém valores prontos para inserção ou atualização direta.
Principais etapas de transformação:
Mapeamento de campo: Mapeie colunas de origem para as colunas do Dataverse de destino. Use scripts para unir e mesclar tabelas quando 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 optionsets dos sistemas de origem para os de destino.
Tabela: OptionSetMapping
Nome da coluna Tipo de dados Nome da tabela de origem cadeia Nome da tabela de destino cadeia Texto de origem cadeia Texto de destino cadeia Valor-alvo cadeia Use a tabela OptionSetMapping para transformar e atualizar com eficiência os valores do conjunto de opções em massa. Por exemplo, para atualizar todos os valores de conjunto de opções na tabela Contato 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: Permitir que o Dataverse gere GUIDs para evitar problemas de fragmentação e desempenho.
Verificações de comprimento da cadeia de caracteres: Verifique se os valores de cadeia de caracteres se ajustam aos limites do Dataverse. Corte ou ajuste conforme necessário.
Campos calculados: Adicione campos derivados (por exemplo, Nome para pesquisas) se estiver ausente na origem.
Outra consideração: ao criar tabelas para corresponder ao esquema do Dataverse, considere as seguintes colunas de chave e tabelas de suporte.
- DataMigration_CreatedDateTime: carimbo de data/hora gerado automaticamente para acompanhamento de 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 Êxito (S).
- Coluna exclusiva: use uma ID exclusiva (por exemplo, a ID exclusiva do sistema de origem) para mapear registros.
- Tabelas de êxito/erro: mantenha tabelas separadas (por exemplo, Contact_Success, Contact_Error) para registrar resultados e tentativas de suporte.
Tabelas de sequência e consultas antecipadas
Após transformações estáticas, organize suas tabelas de forma a reduzir as dependências cíclicas — casos em que as tabelas fazem referência umas às outras, tornando importações isoladas impossíveis. Use esta abordagem:
- Liste todas as tabelas qualificadas para migração.
- Conte consultas únicas por tabela (ignore campos padrão, como
Created Bye outras consultas de tabela, se não houver migração). - Classificar tabelas em ordem crescente por número de consultas.
- Inclua tabelas de relação N:N, contando ambas as pesquisas.
- Exclua consultas em várias tabelas (por exemplo, campos "sobre").
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:
- Use um identificador exclusivo (por exemplo, importsequencenumber) para corresponder aos registros entre preparo e o Dataverse quando os GUIDs são gerados durante a inserção.
- Separe os logs de êxito e erro para evitar problemas de bloqueio e melhorar o desempenho.
- Pré-carregar GUIDs de pesquisa de tabelas já migradas para resolver referências durante a inserção.
- Lidar com dependências cíclicas por:
- Inserindo registros sem consultas dependentes.
- Atualizando essas consultas após o carregamento dos registros relacionados.
Carregar dados no Dataverse
A próxima etapa é determinar e implementar sua abordagem para carregar dados no Dataverse.
Ferramentas: selecione uma ferramenta com base no tamanho e na complexidade dos dados:
- Ferramenta de Migração de Configuração do SDK
- Azure Data Factory
- KingswaySoft
- Scribe
- Transporte de Dados do XrmToolBox
Principais considerações (independente de ferramenta):
Lidar com dependências cíclicas: Carregue as tabelas em sequência para minimizar consultas circulares. Insira registros sem consultas dependentes e atualize-os mais tarde.
Rastrear IDs de registro: capturar os GUIDs do Dataverse em uma tabela de êxito e, em seguida, atualizar a tabela principal usando um identificador exclusivo (por exemplo, importsequencenumber).
Otimizar o tamanho do lote e o número de threads: examine as diretrizes para otimizar o desempenho para operações em massa. O aplicativo usado deve gerenciar erros de proteção de serviço que ocorrem quando números extraordinários de solicitações são enviados ao Dataverse. Se você escrever seu próprio código e usar a API Web do Dataverse, certifique-se de lidar novamente com os erros 429, conforme descrito nos Limites da API de proteção do serviço. Se você usar o SDK do Dataverse, ele gerenciará esses erros para você.
Para obter um desempenho ideal, ajuste o tamanho do lote e a contagem de threads com base na complexidade da tabela:
- Tabelas prontas para uso (OOB) (por exemplo, Contato, Conta, Potencial Cliente): essas tabelas são mais lentas devido a plug-ins internos e tarefas. Recomendado: tamanho do lote 200 a 300, até 30 threads (se ≤10 pesquisas e 50 a 70 colunas).
- Tabelas simples (poucas ou nenhuma pesquisa): recomendado: tamanho do lote ≤10, até 50 threads.
- Tabelas personalizadas moderadamente complexas (algumas pesquisas): recomendado: tamanho do lote ≤100, até 30 threads.
- Tabelas grandes/complexas (>100 colunas, >20 pesquisas): recomendado: tamanho do lote 10 a 20, até 10 a 20 threads para reduzir erros.
Dicas de infraestrutura: para maximizar o desempenho da migração de dados, execute a migração de uma VM (máquina virtual) localizada na mesma região que o ambiente do Dataverse. Essa abordagem reduz significativamente a latência e acelera todo o processo. Saiba como determinar a região do seu ambiente do Dataverse.
Tratamento de erros: não ignore os erros, resolva-os para evitar falhas em cascata. Utilize padrões (por exemplo, pesquisas em branco, valores padrão de conjunto de opções) para inserir registros de espaço reservado e capturar GUIDs.
Atualizações de status: defina apenas o status ativo durante a inserção de registro inicial. 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 ser seguidas imediatamente após a inserção. No entanto, para tabelas especiais como "Case", "Opportunity" ou "Lead", atrase 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 corre o risco de integridade dos dados.
Propriedade e segurança: defina o proprietário do registro correto durante a inserção de dados, pois a segurança de unidade de negócios e no nível do usuário no Dataverse está vinculada à unidade de negócios do proprietário. Atribua a unidade de negócios correta na criação, atualizar isso posteriormente remove todos os direitos de acesso.
-
Use usuários simulados:
- O Dataverse dá suporte a usuários stub (não habilitados), que são úteis para migrações grandes ou históricas. Os usuários do Stub recebem automaticamente a função de segurança do Vendedor– não renomeie ou modifique essa função. Os usuários do Stub podem possuir registros se tiverem acesso de leitura ao nível do usuário às tabelas relevantes.
-
Recomendações:
- Crie todos os usuários não habilitados 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 o papel de Vendedor tem acesso de leitura a todas as tabelas elegíveis para migração.
- Até mesmo usuários desabilitados no ambiente do Dataverse com essa função podem possuir registros.
-
Use usuários simulados:
Manipulação de moeda: defina as taxas de câmbio durante a inserção usando um plug-in de pré-avaliação, pois o Dataverse não dá suporte a taxas históricas.
Postar carregamento de dados no Dataverse
Depois de carregar dados no Dataverse, siga estas etapas para garantir a integridade dos dados e minimizar problemas downstream:
Atualize a tabela principal com GUIDs:
- Após uma carga bem-sucedida, copie os GUIDs de registro do Dataverse da Tabela de Sucesso para a Tabela Principal usando um identificador exclusivo, como
importsequencenumber. - Atualize o Sinalizador de Processamento para marcar registros como:
- P – Processado
- E – Com erro
- U – Não processado - Essa estratégia permite repetições eficientes ignorando registros já processados e dá suporte à resolução de pesquisa em cargas subsequentes.
- Após uma carga bem-sucedida, copie os GUIDs de registro do Dataverse da Tabela de Sucesso para a Tabela Principal usando um identificador exclusivo, como
Tente novamente os registros com falha: Para reduzir o retrabalho 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 substituto caso o proprietário original não esteja disponível (mesmo que como usuário fictício).
- Use valores em branco ou padrão para pesquisas não resolvidas.
- Até mesmo registros de espaço reservado podem ajudar a gerar GUIDs necessários para buscas 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 tabelas elásticas, é possível importar, armazenar e analisar grandes volumes de dados sem escalabilidade, latência ou problemas 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 específico.
As tabelas elásticas são armazenadas no Azure Cosmos DB e dão suporte:
- Dados sem esquema por meio de colunas JSON
- Dimensionamento horizontal automático
- TTL (vida útil) 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.
Tipos de dados recomendados para tabelas elásticas durante a migração de dados
As tabelas elásticas são ideais para tipos de dados específicos.
| Tipo de dados | Description |
|---|---|
| Dados brutos de ingestão | Logs de origem, fluxos de sensores ou exportações em massa de sistemas herdados. Por exemplo, os logs de interação do cliente de um ERP herdado, threads de email antigos e tíquetes de suporte do sistema anterior. |
| Registros semiestruturados | Dados com campos opcionais ou em evolução que não se ajustam a um esquema rígido. Por exemplo, formulários de comentários do cliente com campos opcionais ou formulários de registro de evento com anotações ou marcas personalizadas. |
| Dados em 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 eliminação de duplicação e validação antes de serem adicionados à tabela principal de leads. |
| Dados sensíveis ao tempo ou de expiração | Use TTL (Time-to-Live) para exclusão automática de registros CRM temporários. Por exemplo, códigos de desconto promocionais vinculados a uma campanha, links de acesso único para pesquisas de clientes ou portais de integração e respostas temporárias de pesquisa. |
| Dados em massa particionados | Particione dados por ID ou categoria para melhorar o desempenho e a escalabilidade. Por exemplo, dividir por ID de conta ou ID de região durante a migração de dados em massa, ou segmentar logs de atividades do cliente por ID de campanha para fins de 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 ajustam. Esta seção destaca padrões comuns de dados CRM que são melhor armazenados em outros lugares para garantir o desempenho, a eficiência do custo e a manutenção. Saiba mais sobre os recursos atualmente não compatíveis com tabelas elásticas
| Tipo de dados | Reason |
|---|---|
| Dados altamente relacionais | Tabelas elásticas não dão suporte a junções ou pesquisas |
| Registros comercialmente críticos | Sem integridade transacional ou suporte a plugins |
| Dados que exigem validação complexa | Melhor gerenciado em tabelas padrão com regras de negócios |
Estrutura de segmentação e arquivamento de dados funcionais
O 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 se tornam complexas devido à falta de análise inicial, especialmente em relação a 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ço 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 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% de registros contiverem valores, consulte os stakeholders empresariais para decidir se devem mantê-los ou descartá-los.
Essa análise simples pode reduzir significativamente o escopo da migração. Em sistemas CRM de longa execução, é comum eliminar de 30 a 40% de colunas e até 20% de tabelas, simplificando o processo e melhorando o desempenho.
Relevância de 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 os stakeholders de negócios para decidir se as tarefas de migração são necessárias.
Ignorar colunas que são relevantes apenas no sistema de origem ou não são significativas no destino. Isso inclui muitos campos prontos para uso, como Criado por, Modificado por ou Número da Versão da Linha, a menos que eles atendam a uma finalidade específica em sua migração.
Dados de tipo de arquivo
Se o sistema de origem incluir dados do tipo 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 de vários usuários.
- Arquivos multimídia (por exemplo, imagens, vídeos): escolha uma plataforma que dê suporte à reprodução. As opções incluem SharePoint, serviços de streaming ou outras soluções de armazenamento amigáveis à 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 detecçã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 examinar a relevância do arquivo, você geralmente descobre que o volume total de dados cai significativamente , especialmente em sistemas CRM de execução longa, tornando a migração mais eficiente.
Estratégias de arquivamento de dados
Alguns dados, como emails antigos, casos fechados ou clientes potenciais desqualificados, permanecem 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:
- Emails com mais de três anos
- Casos fechados
- Oportunidades perdidas
- Clientes potenciais desqualificados
- E-mails de marketing, postagens e logs de auditoria
Examine seu sistema para identificar outras tabelas que você pode arquivar.
Etapa 2: Escolher uma abordagem de arquivamento
- Mantenha os dados no sistema de origem. Mantenha algumas licenças de administrador para acesso enquanto desativa outras para reduzir os custos.
- Mover para o 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 separado do Dataverse. Essa opção é menos comum, mas é útil se você quiser isolar dados arquivados. Você pode desativar esse ambiente mais tarde para simplificar o planejamento de transição.
Infraestrutura de migração de dados recomendada
Para garantir a migração rápida e confiável de dados para o Dataverse:
- Use uma VM (máquina virtual) na mesma região que o ambiente do 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 armazenamento de 500 GB para lidar com grandes volumes de dados com eficiência.
- 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 o ambiente do Dataverse para um desempenho ideal.