Migre dados legados sem estragar tudo

Migrar dados legados é difícil.

Muitas organizações têm sistemas de CRM de negócios on-premise antigos e complexos. Hoje, existem muitas alternativas de SaaS em nuvem, que trazem muitos benefícios; pague conforme o uso e pague apenas pelo que usar. Portanto, eles decidem migrar para os novos sistemas.

Ninguém quer deixar dados valiosos sobre clientes no sistema antigo e começar com o novo sistema vazio, então precisamos migrar esses dados. Infelizmente, a migração de dados não é uma tarefa fácil, pois cerca de 50% do esforço de implantação é consumido pelas atividades de migração de dados. De acordo com o Gartner, a Salesforce é líder em soluções de CRM na nuvem. Portanto, a migração de dados é um tópico importante para a implantação do Salesforce.

Então, como podemos garantir uma transição bem-sucedida de dados legados para um novo sistema brilhante e garantir que preservaremos todo o seu histórico? Neste artigo, forneço 10 dicas para uma migração de dados bem-sucedida. As primeiras cinco dicas se aplicam a qualquer migração de dados, independentemente da tecnologia utilizada.

Migração de dados em geral

1. Faça da migração um projeto separado

Na lista de verificação de implantação de software, a migração de dados não é um item de “exportação e importação” manipulado por uma ferramenta inteligente de migração de dados de “apertar um botão” que possui mapeamento predefinido para sistemas de destino.

A migração de dados é uma atividade complexa, merecendo um projeto, plano, abordagem, orçamento e equipe separados. Um escopo e um plano em nível de entidade devem ser criados no início do projeto, garantindo que não haja surpresas, como “Ah, esquecemos de carregar os relatórios de visita desses clientes, quem fará isso?” duas semanas antes do prazo.

A abordagem de migração de dados define se carregaremos os dados de uma só vez (também conhecido como big bang ), ou se carregaremos pequenos lotes toda semana.

Esta não é uma decisão fácil, no entanto. A abordagem deve ser acordada e comunicada a todas as partes interessadas técnicas e de negócios para que todos estejam cientes de quando e quais dados aparecerão no novo sistema. Isso também se aplica a interrupções do sistema.

2. Faça uma estimativa realista

Não subestime a complexidade da migração de dados. Muitas tarefas demoradas acompanham esse processo, que podem ser invisíveis no início do projeto.

Por exemplo, carregar conjuntos de dados específicos para fins de treinamento com vários dados realistas, mas com itens confidenciais ofuscados, para que as atividades de treinamento não gerem notificações por email para os clientes.

O fator básico para estimativa é o número de campos a serem transferidos de um sistema de origem para um sistema de destino.

Algum tempo é necessário em diferentes estágios do projeto para cada campo, incluindo entender o campo, mapear o campo de origem para o campo de destino, configurar ou construir transformações, realizar testes, medir a qualidade dos dados para o campo e assim por diante.

O uso de ferramentas inteligentes, como Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas e similares, pode reduzir esse tempo, especialmente na fase de construção.

Em particular, a compreensão dos dados de origem – a tarefa mais crucial em qualquer projeto de migração – não pode ser automatizada por ferramentas, mas exige que os analistas dediquem algum tempo examinando a lista de campos um por um.

A estimativa mais simples do esforço geral é de um homem-dia para cada campo transferido do sistema legado.

Uma exceção é a replicação de dados entre os mesmos esquemas de origem e destino sem transformação adicional – às vezes conhecida como migração 1:1 – onde podemos basear a estimativa no número de tabelas a serem copiadas.

Uma estimativa detalhada é uma arte própria.

3. Verifique a qualidade dos dados

Não superestime a qualidade dos dados de origem, mesmo que nenhum problema de qualidade de dados seja relatado pelos sistemas legados.

Novos sistemas têm novas regras, que podem ser violadas com dados legados. Aqui está um exemplo simples. O e-mail de contato pode ser obrigatório no novo sistema, mas um sistema legado de 20 anos pode ter um ponto de vista diferente.

Pode haver minas ocultas em dados históricos que não foram tocadas por um longo tempo, mas podem ser ativadas ao serem transferidas para o novo sistema. Por exemplo, dados antigos usando moedas européias que não existem mais precisam ser convertidos para euros, caso contrário, as moedas devem ser adicionadas ao novo sistema.

A qualidade dos dados influencia significativamente o esforço, e a regra simples é: quanto mais avançarmos na história, maior será a confusão que descobriremos. Assim, é vital decidir com antecedência quanta história queremos transferir para o novo sistema.

4. Envolva Pessoas de Negócios

Os empresários são os únicos que realmente entendem os dados e, portanto, podem decidir quais dados podem ser descartados e quais devem ser mantidos.

É importante ter alguém da equipe de negócios envolvido durante o exercício de mapeamento e, para retrocessos futuros, é útil registrar as decisões de mapeamento e as razões para elas.

Como uma imagem vale mais que mil palavras, carregue um lote de teste no novo sistema e deixe a equipe de negócios brincar com ele.

Mesmo que o mapeamento de migração de dados seja revisado e aprovado pela equipe de negócios, surpresas podem aparecer quando os dados aparecerem na interface do novo sistema.

“Ah, agora entendo, temos que mudar um pouco”, torna-se uma frase comum.

Deixar de envolver especialistas no assunto, que geralmente são pessoas muito ocupadas, é a causa mais comum de problemas depois que um novo sistema entra em operação.

5. Apontar para a solução de migração automatizada

A migração de dados geralmente é vista como uma atividade única, e os desenvolvedores tendem a acabar com soluções cheias de ações manuais esperando executá-las apenas uma vez. Mas há muitas razões para evitar tal abordagem.

• Se a migração for dividida em várias ondas, teremos que repetir as mesmas ações várias vezes.
• Normalmente, há pelo menos três execuções de migração para cada onda: uma simulação para testar o desempenho e a funcionalidade da migração de dados, uma carga completa de validação de dados para testar todo o conjunto de dados e realizar testes de negócios e, claro, a carga de produção. O número de execuções aumenta com baixa qualidade de dados. Melhorar a qualidade dos dados é um processo iterativo, portanto, precisamos de várias iterações para alcançar a taxa de sucesso desejada.

Assim, mesmo que a migração seja uma atividade única por natureza, ter ações manuais pode desacelerar significativamente suas operações.

Migração de dados do Salesforce

A seguir, abordaremos cinco dicas para uma migração bem-sucedida do Salesforce. Lembre-se de que essas dicas provavelmente também se aplicam a outras soluções em nuvem.

6. Prepare-se para cargas longas

O desempenho é uma das, se não a maior, compensação ao passar de uma solução local para uma solução em nuvem – o Salesforce não está excluído.

Os sistemas locais geralmente permitem o carregamento direto de dados em um banco de dados subjacente e, com um bom hardware, podemos alcançar facilmente milhões de registros por hora.

Mas, não na nuvem. Na nuvem, somos fortemente limitados por vários fatores.

• Latência de rede – Os dados são transferidos pela Internet.
• Camada de aplicativo do Salesforce – os dados são movidos por uma camada de multilocação de API espessa até chegarem em seus bancos de dados Oracle.
• Código personalizado no Salesforce – validações personalizadas, gatilhos, fluxos de trabalho, regras de detecção de duplicação e assim por diante – muitos dos quais desabilitam cargas paralelas ou em massa.

Como resultado, o desempenho da carga pode ser de milhares de contas por hora.

Pode ser menos, ou pode ser mais, dependendo de coisas, como o número de campos, validações e gatilhos. Mas é vários graus mais lento do que uma carga direta de banco de dados.

A degradação do desempenho, que depende do volume dos dados no Salesforce, também deve ser considerada.

É causado por índices no RDBMS subjacente (Oracle) usado para verificar chaves estrangeiras, campos exclusivos e avaliação de regras de duplicação. A fórmula básica é de aproximadamente 50% de desaceleração para cada nota 10, causada por O(logN) a porção de complexidade de tempo nas operações de classificação e árvore B.

Além disso, o Salesforce tem muitos limites de uso de recursos.

Um deles é o limite de API em massa definido para 5.000 lotes em janelas contínuas de 24 horas, com o máximo de 10.000 registros em cada lote.

Portanto, o máximo teórico é de 50 milhões de registros carregados em 24 horas.

Em um projeto real, o máximo é muito menor devido ao tamanho limitado do lote ao usar, por exemplo, gatilhos personalizados.

Isso tem um forte impacto na abordagem de migração de dados.

Mesmo para conjuntos de dados de tamanho médio (de 100.000 a 1 milhão de contas), a abordagem big bang está fora de questão, então devemos dividir os dados em ondas de migração menores.

Isso, é claro, afeta todo o processo de implantação e aumenta a complexidade da migração, pois adicionaremos incrementos de dados em um sistema já preenchido por migrações anteriores e dados inseridos pelos usuários.

Também devemos considerar esses dados existentes nas transformações e validações de migração.

Além disso, cargas longas podem significar que não podemos realizar migrações durante uma interrupção do sistema.

Se todos os usuários estiverem localizados em um país, podemos aproveitar uma interrupção de oito horas durante a noite.

Mas para uma empresa como a Coca-Cola, com operações em todo o mundo, isso não é possível. Assim que tivermos os EUA, o Japão e a Europa no sistema, abrangemos todos os fusos horários, de modo que o sábado é a única opção de interrupção que não afeta os usuários.

E isso pode não ser suficiente, portanto, devemos carregar enquanto estiver online , quando os usuários estiverem trabalhando com o sistema.

7. Respeite as necessidades de migração no desenvolvimento de aplicativos

Os componentes do aplicativo, como validações e acionadores, devem ser capazes de lidar com as atividades de migração de dados. A desativação forçada das validações no momento da carga de migração não é uma opção se o sistema precisar estar online. Em vez disso, temos que implementar uma lógica diferente nas validações das alterações realizadas por um usuário de migração de dados.

• Os campos de data não devem ser comparados com a data real do sistema porque isso desabilitaria o carregamento de dados históricos. Por exemplo, a validação deve permitir a inserção de uma data de início de conta anterior para dados migrados.
• Campos obrigatórios, que não podem ser preenchidos com dados históricos, devem ser implementados como não obrigatórios, mas com validação sensível ao usuário, permitindo valores vazios para dados provenientes da migração, mas rejeitando valores vazios provenientes de usuários regulares via GUI .
• Triggers, especialmente aqueles que enviam novos registros para a integração, devem poder ser ativados/desativados para o usuário de migração de dados para evitar inundar a integração com dados migrados.

Outro truque é usar o campo Legacy ID ou Migration ID em cada objeto migrado. Há duas razões para isso. A primeira é óbvia: manter o ID do sistema antigo para retrocesso; depois que os dados estão no novo sistema, as pessoas ainda podem querer pesquisar suas contas usando os IDs antigos, encontrados em locais como e-mails, documentos e sistemas de rastreamento de bugs. Mau hábito? Pode ser. Mas os usuários agradecerão se você preservar seus IDs antigos. A segunda razão é técnica e vem do fato de que o Salesforce não aceita IDs fornecidos explicitamente para novos registros (ao contrário do Microsoft Dynamics), mas os gera durante o carregamento. O problema surge quando queremos carregar objetos filho porque temos que atribuir a eles IDs dos objetos pai. Como saberemos esses IDs somente após o carregamento, este é um exercício inútil.

Vamos usar Contas e seus Contatos, por exemplo:

1. Gerar dados para contas.
2. Carregue contas no Salesforce e receba IDs gerados.
3. Incorpore novos IDs de conta nos dados de contato.
4. Gere dados para Contatos.
5. Carregar contatos no Salesforce.

Podemos fazer isso de forma mais simples carregando as contas com seus IDs herdados armazenados em um campo externo especial. Este campo pode ser usado como referência pai, portanto, ao carregar Contatos, simplesmente usamos o ID legado da conta como um ponteiro para a conta pai:

1. Gere dados para contas, incluindo ID herdado.
2. Gere dados para contatos, incluindo ID de conta herdada.
3. Carregar contas no Salesforce.
4. Carregue contatos no Salesforce, usando o ID legado da conta como referência pai.

O legal aqui é que separamos uma fase de geração e uma fase de carregamento, o que permite melhor paralelismo, diminuição do tempo de indisponibilidade e assim por diante.

8. Esteja ciente dos recursos específicos do Salesforce

Como qualquer sistema, o Salesforce tem muitas partes complicadas das quais devemos estar cientes para evitar surpresas desagradáveis ​​durante a migração de dados. Aqui estão alguns exemplos:

• Algumas alterações em usuários ativos geram automaticamente notificações por e-mail para e-mails de usuários. Assim, se quisermos brincar com os dados do usuário, precisamos desativar os usuários primeiro e ativá-los após a conclusão das alterações. Em ambientes de teste, embaralhamos e-mails de usuários para que as notificações não sejam disparadas. Como os usuários ativos consomem licenças caras, não podemos ter todos os usuários ativos em todos os ambientes de teste. Temos que gerenciar subconjuntos de usuários ativos, por exemplo, para ativar apenas aqueles em um ambiente de treinamento.
• Usuários inativos, para alguns objetos padrão, como Conta ou Caso, podem ser atribuídos somente após conceder a permissão do sistema “Atualizar registros com proprietários inativos”, mas podem ser atribuídos, por exemplo, a Contatos e todos os objetos personalizados.
• Quando o contato é desativado, todos os campos de desativação são ativados silenciosamente.
• Ao carregar um objeto duplicado de Membro da equipe de conta ou compartilhamento de conta, o registro existente é substituído silenciosamente. No entanto, ao carregar um Opportunity Partner duplicado, o registro é simplesmente adicionado, resultando em uma duplicata.
• Campos do sistema, como Created Date de criação , Created By ID , Last Modified Date , Last Modified By ID , podem ser escritos explicitamente somente após conceder uma nova permissão do sistema "Definir campos de auditoria na criação do registro".
• As alterações de valor do histórico do campo não podem ser migradas.
• Os proprietários de artigos de conhecimento não podem ser especificados durante o carregamento, mas podem ser atualizados posteriormente.
• A parte complicada é o armazenamento de conteúdo (documentos, anexos) no Salesforce. Existem várias maneiras de fazer isso (usando anexos, arquivos, anexos de feed, documentos), e cada maneira tem seus prós e contras, incluindo diferentes limites de tamanho de arquivo.
• Os campos da lista de opções forçam os usuários a selecionar um dos valores permitidos, por exemplo, um tipo de conta. Mas ao carregar dados usando a API do Salesforce (ou qualquer ferramenta criada sobre ela, como o Apex Data Loader ou o conector Informatica Salesforce), qualquer valor será transmitido.

A lista continua, mas o ponto principal é: familiarize-se com o sistema e aprenda o que ele pode e o que não pode fazer antes de fazer suposições. Não assuma o comportamento padrão, especialmente para objetos principais. Sempre pesquise e teste.

9. Não use o Salesforce como plataforma de migração de dados

É muito tentador usar o Salesforce como plataforma para criar uma solução de migração de dados, especialmente para desenvolvedores do Salesforce. É a mesma tecnologia para a solução de migração de dados que para a customização do aplicativo Salesforce, a mesma GUI, a mesma linguagem de programação Apex, a mesma infraestrutura. O Salesforce possui objetos que podem atuar como tabelas e um tipo de linguagem SQL, Salesforce Object Query Language (SOQL). No entanto, por favor, não o use; seria uma falha arquitetônica fundamental.

O Salesforce é um excelente aplicativo SaaS com muitos recursos interessantes, como colaboração avançada e personalização avançada, mas o processamento em massa de dados não é um deles. As três razões mais significativas são:

• Desempenho – O processamento de dados no Salesforce é vários graus mais lento do que no RDBMS.
• Falta de recursos analíticos – O Salesforce SOQL não oferece suporte a consultas complexas e funções analíticas que devem ser suportadas pela linguagem Apex e prejudicariam ainda mais o desempenho.
• Arquitetura * – Colocar uma plataforma de migração de dados dentro de um ambiente específico do Salesforce não é muito conveniente. Normalmente, temos vários ambientes para fins específicos, muitas vezes criados ad hoc para que possamos dedicar muito tempo à sincronização de código. Além disso, você também estaria contando com a conectividade e a disponibilidade desse ambiente específico do Salesforce.

Em vez disso, crie uma solução de migração de dados em uma instância separada (pode ser uma nuvem ou local) usando uma plataforma RDBMS ou ETL. Conecte-o aos sistemas de origem e direcione os ambientes do Salesforce que você deseja, mova os dados necessários para sua área de preparação e processe-os lá. Isso permitirá que você:

• Aproveite todo o poder e os recursos da linguagem SQL ou dos recursos ETL.
• Tenha todos os códigos e dados em um só lugar para que você possa executar análises em todos os sistemas.
  • Por exemplo, você pode combinar a configuração mais recente do ambiente de teste do Salesforce mais atualizado com dados reais do ambiente de produção do Salesforce.
• Você não é tão dependente da tecnologia dos sistemas de origem e destino e pode reutilizar sua solução para o próximo projeto.

10. Supervisionar os metadados do Salesforce

No início do projeto, geralmente pegamos uma lista de campos do Salesforce e iniciamos o exercício de mapeamento. Durante o projeto, muitas vezes acontece que novos campos são adicionados pela equipe de desenvolvimento de aplicativos ao Salesforce ou que algumas propriedades de campo são alteradas. Podemos pedir à equipe de aplicativos para notificar a equipe de migração de dados sobre todas as alterações no modelo de dados, mas nem sempre funciona. Para estar seguro, precisamos ter todas as alterações do modelo de dados sob supervisão.

Uma maneira comum de fazer isso é baixar, regularmente, metadados relevantes para migração do Salesforce em algum repositório de metadados. Uma vez que temos isso, podemos não apenas detectar alterações no modelo de dados, mas também podemos comparar modelos de dados de dois ambientes do Salesforce.

Quais metadados baixar:

• Uma lista de objetos com seus rótulos e nomes técnicos e atributos, como creatable ou updatable .
• Uma lista de campos com seus atributos (melhor pegar todos eles).
• Uma lista de valores de lista de opções para campos de lista de opções. Vamos precisar deles para mapear ou validar dados de entrada para valores corretos.
• Uma lista de validações, para garantir que novas validações não estejam criando problemas para os dados migrados.

Como baixar metadados do Salesforce? Bem, não existe um método de metadados padrão, mas existem várias opções:

• Gerar Enterprise WSDL – No aplicativo da Web Salesforce, navegue até o menu Setup / API e baixe o Enterprise WSDL fortemente tipado, que descreve todos os objetos e campos no Salesforce (mas não os valores da lista de opções nem as validações).
• Chame o serviço Web describeSObjects da Salesforce, diretamente ou usando o wrapper Java ou C# (consulte a API do Salesforce). Dessa forma, você obtém o que precisa e esta é a maneira recomendada de exportar os metadados.
• Use qualquer uma das inúmeras ferramentas alternativas disponíveis na internet.

Prepare-se para a próxima migração de dados

As soluções em nuvem, como o Salesforce, ficam prontas instantaneamente. Se você estiver satisfeito com as funcionalidades integradas, basta fazer login e usá-las. No entanto, o Salesforce, como qualquer outra solução de CRM em nuvem, traz problemas específicos aos tópicos de migração de dados a serem observados, principalmente no que diz respeito ao desempenho e limites de recursos.

Mover dados legados para o novo sistema é sempre uma jornada, às vezes uma jornada para a história oculta em dados de anos anteriores. Neste artigo, baseado em uma dúzia de projetos de migração, apresentei dez dicas sobre como migrar dados legados e evitar com sucesso a maioria das armadilhas.

A chave é entender o que os dados revelam. Portanto, antes de iniciar a migração de dados, certifique-se de que sua equipe de desenvolvimento do Salesforce esteja bem preparada para os possíveis problemas que seus dados podem conter.