Estratégia de teste de conversão de dados

Estratégia de teste de migração de dados: um guia completo para o sucesso do teste de migração de dados.
O teste de migração de dados exige uma estratégia abrangente para reduzir o risco e fornecer uma migração bem-sucedida para os usuários finais.
Neste artigo, David Katzoff, diretor administrativo da Valiance Partners, especialista em tecnologia de migração de dados e provedor de serviços, esboça um plano para projetar uma estratégia de teste de migração de dados eficaz.
David completa o artigo com uma lista de verificação útil de recomendações que o leitor pode usar para avaliar sua própria abordagem.
Como implementar uma estratégia de teste de migração de dados eficaz.
O compliance e o business risk desempenham um papel significativo na implementação de sistemas de informações corporativas.
Os riscos associados a esses sistemas são, em geral, bem conhecidos.
No entanto, como parte do processo de implementação, muitos desses sistemas de informação serão preenchidos com dados legados e os riscos de conformidade e de negócios associados a migrações de dados e conteúdo não são necessariamente compreendidos.
Nesse contexto, os riscos associados à migração de dados são um resultado direto do erro de migração. Além disso, as estratégias de testes da indústria para mitigar esse risco, ou mais especificamente o erro de migração de dados, não têm consistência e estão longe de ser deterministas.
Este artigo oferece ideias e recomendações sobre como criar uma estratégia de testes de migração de dados mais robusta e consistente.
Antes de mergulhar nos detalhes, um pouco de experiência - a Valiance Partners testou centenas de migrações de dados e conteúdo, principalmente em indústrias reguladas pela FDA (produtos farmacêuticos, dispositivos médicos, biotecnologia e produtos alimentícios), manufatura e automóveis.
As informações apresentadas aqui incluem algumas das lições aprendidas com o controle de qualidade de nossos clientes e o histórico real de erros, desde o teste de migrações de centenas de milhares de campos e terabytes de conteúdo.
A abordagem recomendada para projetar estratégias de teste de migração é documentar o risco, a probabilidade de ocorrência e, em seguida, definir os meios para reduzir o risco por meio de testes, quando apropriado. A identificação de riscos é complicada e muito do processo será específico para o sistema que está sendo migrado.
Vamos analisar dois sistemas para ilustrar este ponto:
No primeiro caso, a migração de dados financeiros em bancos de varejo é tipicamente definida por migrações de alto volume (10 ou 100 de milhões de registros) onde os registros de origem para destino são bastante semelhantes e envolvem tradução mínima e pouco ou nenhum enriquecimento de dados. Para um segundo exemplo, considere o gerenciamento de reclamações de uma empresa de produtos de consumo. Esses sistemas normalmente não são maduros e as implementações mais recentes, e seus processos de negócios associados, precisam se adaptar aos diversos requisitos de negócios e conformidade. Esses sistemas têm um volume modesto em comparação (10 ou 100 de milhares de registros) com traduções complexas e enriquecimento de dados para concluir o registro mais novo à medida que são migrados.
Em ambos os casos, a obtenção dos dados migrados representados com precisão no sistema de destino é fundamental. No entanto, o processo pelo qual a precisão é definida irá variar significativamente entre esses dois sistemas e suas migrações associadas.
No primeiro caso, o setor de serviços financeiros evoluiu até o ponto em que existem padrões de intercâmbio de dados, o que simplifica enormemente esse processo.
No caso em que os dados de gerenciamento de reclamações são migrados, será necessária uma análise significativamente mais adiantada para “ajustar melhor” os dados legados no novo sistema.
Essa análise extrairá o enriquecimento de dados para preencher registros incompletos, identificar os requisitos de limpeza de dados por meio de análise de pré-migração, executar o processo de migração e verificar os resultados antes de entender os requisitos finais de migração de dados.
Deixando de lado as características específicas do sistema, existem várias opções para minimizar a ocorrência de erros de migração por meio de testes. A discussão a seguir revisa essas opções e apresenta um conjunto de recomendações para consideração.
Teste de migração de dados: quais são as opções?
A abordagem de fato para testar dados e migrações de conteúdo depende da amostragem, onde alguns subconjuntos de dados aleatórios ou de conteúdo são selecionados e inspecionados para garantir que a migração seja concluída “conforme projetado”.
Aqueles que testaram migrações usando essa abordagem estão familiarizados com o método típico de teste, depuração e reteste de iteração, em que as execuções subseqüentes do processo de teste revelam diferentes condições de erro à medida que novas amostras são revisadas.
A amostragem funciona, mas depende de um nível aceitável de erro e de uma suposição relativa à repetibilidade. Um nível aceitável de erro implica que menos de 100% dos dados serão migrados sem erro e o nível de erro é inversamente proporcional ao número de amostras testadas (consulte padrões de amostragem como ANSI / ASQ Z1.4).
De acordo com a suposição de repetibilidade, o fato de muitas migrações exigirem quatro, cinco ou mais iterações de testes com resultados diferentes implica que um dos princípios fundamentais da amostragem não é mantido, ou seja, “não conformidades ocorrem aleatoriamente e com independência estatística… "
Mesmo com essas deficiências, a amostragem tem um papel em uma estratégia de testes bem definida, mas quais são as outras opções de teste?
As seguintes listas listam os testes para a fase do processo de migração:
Teste de migração de dados prévios.
Esses testes ocorrem no início do processo de migração, antes que qualquer migração, até mesmo a migração para fins de teste, seja concluída. As opções de teste de pré-migração incluem:
Verificar o escopo dos sistemas e dados de origem com a comunidade de usuários e a TI. A verificação deve incluir dados a serem incluídos e excluídos e, se aplicável, vinculados às consultas específicas que estão sendo usadas para a migração. Defina a origem para direcionar mapeamentos de alto nível para cada categoria de dados ou conteúdo e verifique se o tipo desejado foi definido no sistema de destino. Verifique os requisitos de dados do sistema de destino, como nomes de campo, tipo de campo, campos obrigatórios, listas de valores válidos e outras verificações de validação no nível de campo. Usando a origem nos mapeamentos de destino, teste os dados de origem em relação aos requisitos do sistema de destino. Por exemplo, se o sistema de destino tiver um campo obrigatório, verifique se a origem apropriada não é nula ou se o campo do sistema de destino tem uma lista de valores válidos, teste para garantir que os campos de origem apropriados contenham esses valores válidos. Teste os campos que vinculam exclusivamente os registros de origem e de destino e assegure-se de que haja um mapeamento definitivo entre os conjuntos de registros Teste as conexões de origem e de destino da plataforma de migração. Configuração da ferramenta de teste em relação à especificação de migração, que geralmente pode ser concluída por meio de testes de caixa preta em campo por campo. Se for inteligente, o teste aqui também pode ser usado para verificar se os mapeamentos de uma especificação de migração estão completos e precisos.
Revisão Formal de Design de Migração de Dados.
Realize uma revisão formal do design da especificação de migração quando o teste de pré-migração estiver quase concluído ou durante os primeiros estágios da configuração da ferramenta de migração.
A especificação deve incluir:
Uma definição dos sistemas de origem Os conjuntos de dados e consultas do sistema de origem Os mapeamentos entre os campos do sistema de origem e o sistema de destino Número de registros de origem Número de registros de sistemas de origem criados por unidade de tempo (a ser usado para definir o tempo de migração e o tempo de inatividade fontes suplementares Requisitos de limpeza de dados Requisitos de desempenho Requisitos de teste.
A revisão formal do design deve incluir representantes das comunidades de usuários, TI e gerenciamento apropriadas.
O resultado de uma revisão de projeto formal deve incluir uma lista de questões abertas, os meios para fechar cada problema e aprovar a especificação de migração e um processo para manter a especificação em sincronia com a configuração da ferramenta de migração (que parece mudar continuamente até a migração de produção). ).
Teste de migração pós-dados.
Uma vez que a migração tenha sido executada, testes adicionais de ponta a ponta podem ser executados.
Esperar que uma soma significativa de erros seja identificada durante as execuções de teste iniciais, embora ela seja minimizada se testes de pré-migração suficientes forem bem executados. A pós-migração é normalmente executada em um ambiente de teste e inclui:
Teste a taxa de transferência do processo de migração (número de registros por unidade de tempo). Esse teste será usado para verificar se o tempo de inatividade planejado é suficiente. Para fins de planejamento, considere o tempo para verificar se o processo de migração foi concluído com êxito. Comparar Registros Migrados em Registros Gerados pelo Sistema de Destino - Assegure-se de que os registros migrados estejam completos e do contexto apropriado. Verificação resumida - Existem várias técnicas que fornecem informações resumidas, incluindo contagens de registros e somas de verificação. Aqui, o número de registros migrados é compilado do sistema de destino e comparado ao número de registros migrados. Essa abordagem fornece apenas informações resumidas e, se houver algum problema, não fornecerá muitas informações sobre a causa raiz de um problema. Comparar registros migrados a fontes - os testes devem verificar se os valores dos campos são migrados de acordo com a especificação de migração. Em suma, os valores de origem e os mapeamentos de nível de campo são usados ​​para calcular os resultados esperados no destino. Esse teste pode ser concluído usando amostragem, se apropriado, ou se a migração incluir dados que representem risco significativo de negócios ou conformidade, 100% dos dados migrados poderão ser verificados usando uma ferramenta de teste automatizada.
As vantagens da abordagem automatizada incluem a capacidade de identificar erros que são menos prováveis ​​de ocorrer (as proverbiais agulhas no palheiro). Além disso, como uma ferramenta de teste automatizada pode ser configurada em paralelo com a configuração da ferramenta de migração, a capacidade de testar 100% dos dados migrados está disponível imediatamente após a primeira migração de teste.
Quando comparado com abordagens de amostragem, é fácil ver que o teste automatizado economiza tempo significativo e minimiza o típico teste interativo, depuração e reteste encontrado com a amostragem.
O conteúdo migrado tem considerações especiais.
Para os casos em que o conteúdo está sendo migrado sem alteração, o teste deve verificar se a integridade do conteúdo é mantida e se o conteúdo está associado ao registro de destino correto. Isso pode ser concluído usando amostragem ou como já descrito, ferramentas automatizadas podem ser usadas para verificar 100% do resultado.
Teste de aceitação do usuário de migração de dados.
Sutilezas funcionais relacionadas à mistura de dados migrados e dados criados no sistema de destino podem ser difíceis de identificar no início do processo de migração.
O teste de aceitação do usuário oferece uma oportunidade para a comunidade de usuários interagir com os dados herdados no sistema de destino antes da liberação da produção e, na maioria das vezes, essa é a primeira oportunidade para os usuários.
Atenção deve ser dada aos relatórios, feeds downstream e outros processos do sistema que dependem de dados migrados.
Migração de produção.
Todos os testes concluídos antes da migração da produção não garantem que o processo de produção seja concluído sem erros.
Desafios vistos neste momento incluem erros de procedimento e, às vezes, erros de configuração do sistema de produção. Se uma ferramenta de teste automatizada tiver sido usada para o teste pós-migração de dados e conteúdo, a execução de outra execução de teste é direta e recomendada.
Se uma abordagem automatizada não tiver sido usada, algum nível de amostragem ou verificação de resumo ainda é recomendado.
Estratégia de teste de migração de dados: Recomendações de design.
No contexto das migrações de dados e conteúdo, os riscos de negócios e conformidade são um resultado direto do erro de migração de dados, mas uma estratégia de teste minuciosa minimiza a probabilidade de erros de migração de dados e conteúdo.
A lista abaixo fornece um conjunto de recomendações para definir essa estratégia de teste para um sistema específico:
Estabelecer uma equipe de migração abrangente, incluindo representantes da comunidade de usuários, TI e gerenciamento. Verifique o nível apropriado de experiência para cada membro da equipe e treine conforme necessário nos princípios de migração de dados, na origem e no sistema de destino. Analise os riscos de negócios e conformidade com os sistemas específicos que estão sendo migrados. Esses riscos devem se tornar a base para a estratégia de teste de migração de dados. Crie, analise e gerencie formalmente uma especificação de migração completa. Embora seja fácil afirmar, pouquíssimas migrações dão esse passo. Verifique o escopo da migração com a comunidade de usuários e a TI. Entenda que o escopo da migração pode ser refinado ao longo do tempo, pois os testes pré e pós-migração podem revelar falhas desse escopo inicial. Identifique (ou preveja) fontes prováveis ​​de erro de migração e defina estratégias de teste específicas para identificar e remediar esses erros. Isso fica mais fácil com a experiência e as categorias e condições de erro listadas aqui fornecem um bom ponto de partida. Use a origem em nível de campo para mapeamentos de destino para estabelecer requisitos de dados para o sistema de origem. Use esses requisitos de dados para concluir o teste de pré-migração. Se necessário, limpe ou complemente os dados de origem, conforme necessário. Conclua um nível apropriado de teste pós-migração. Para migrações em que os erros precisam ser minimizados, recomenda-se a verificação de 100% usando uma ferramenta automatizada. Assegure-se de que essa ferramenta de teste automatizada seja independente da ferramenta de migração. Observe atentamente o ROI do teste automatizado se houver alguma preocupação com os custos, o comprometimento de tempo ou a natureza iterativa da verificação de migração por meio da amostragem de Teste de aceitação do usuário completo com dados migrados. Essa abordagem tende a identificar erros de aplicativos com dados que foram migrados conforme projetados. Teste a execução de produção. Se uma ferramenta de teste automatizada foi escolhida, é provável que 100% dos dados migrados possam ser testados aqui com custo incremental ou tempo de inatividade mínimos. Se uma abordagem de teste manual estiver sendo usada, conclua uma verificação de resumo.
Sobre o autor: David Katzoff, Valiance Partners, Inc.
David Katzoff é diretor administrativo de desenvolvimento de produtos da Valiance Partners, Inc.
Ele traz mais de quinze anos de engenharia de aplicativos de software, gerenciamento de projetos e experiência comercial compatível com essa função.
Além de supervisionar o desenvolvimento dos produtos de migração da Valiance, David ocupou importantes funções consultivas para migrações em grande escala na Amgen, Pfizer, Wyeth e J & amp; J.

Estratégia de Conversão de Dados.
O objetivo principal de uma estratégia de conversão será identificar a abordagem geral a ser usada para converter os dados mestre e transacionais necessários de sistemas legados para a nova solução.
Uma implementação do sistema quase sempre envolve alguma conversão. É crucial que uma organização identifique os dados que precisam ser transferidos de um sistema para outro e o formato de transferência para que possa ser usado com êxito pelo novo sistema.
A CNT utiliza algumas diretrizes básicas para preparar qualquer plano de conversão de dados, incluindo:
Requisitos de conversão de dados Conversão manual Conversão automática Métodos de conversão de dados Requisitos de limpeza de dados Cronogramas de teste de conversão.

Estratégia de teste de conversão de dados
Estamos migrando nossos dados de produção (banco de dados e sistema de arquivos) de um modelo de dados bastante complexo para outro modelo de dados bastante complexo. O processo de migração é dado pela especificação como um conjunto de regras de mapeamento e funções de transformação.
Estou planejando estratégias de teste para esse processo de migração. Para identificar as áreas mais arriscadas aqui, li algumas lições aprendidas com testes de migração e testes de ferramentas ETL em geral e os comparei com a especificação do processo de migração.
Onde as coisas podem dar errado?
Por motivos de compatibilidade com versões anteriores, os novos dados serão fornecidos pelo novo aplicativo aos módulos antigos por meio de adaptadores. Módulos antigos farão seu trabalho usando dados migrados como eles usaram. O novo modelo de dados suportará alguns novos recursos do aplicativo. O novo modelo de dados não suportará mais alguns recursos de aplicativos antigos (geralmente usados ​​com pouca freqüência). Campos anuláveis ​​no modelo antigo não são mais anuláveis. Arquivos no sistema de arquivos são definidos em formato diferente. Os dados que costumavam ser dissociados no sistema antigo agora serão associados (por exemplo, clientes com seus projetos) com base em: regras de administrador de regras automáticas Novos formatos de dados serão usados.
Valores para dados usados ​​por novos recursos podem ser incorretamente padronizados. O adaptador pode converter novos dados em formato legado incorretamente. Nem todas as entidades podem ser migradas, por exemplo, algumas configurações de cliente antigas não podem ser encontradas no novo sistema. Nem todos os dados (propriedades) podem ser migrados. Novo modelo de dados pode usar formatos de dados podem não ser capazes de armazenar alguma estrutura de dados antiga (por exemplo, VARCHAR vs. BLOB) Arquivos migrados podem não ser legíveis para módulos antigos etc.
Minha primeira ideia é combinar duas estratégias de teste aqui:
Estratégia de teste de baixo nível que será relativamente completa, mas terá pouca cobertura. A ideia é isolar uma amostra mais representativa de dados originais (que faz sentido para o negócio, por exemplo, cliente único e seus documentos). Então, para cada regra de mapeamento, defina a saída real esperada para a parte correspondente dos dados da amostra. Automatize as verificações.
Estratégia de teste de alto nível que será menos abrangente, mas cobrirá a maioria das funcionalidades do aplicativo e tentará identificar problemas de integração com módulos antigos. A ideia é migrar todos os dados primeiro. Em seguida, realize cenários de teste de usuário que envolvam todas as funcionalidades do novo aplicativo e dos módulos antigos.
Que outras estratégias você sugeriria para descobrir bugs para os riscos identificados?
Tendo participado de algumas migrações de dados, eu diria que você tem um bom começo no caminho certo. Criar linhas de base de comportamento esperado antes da migração e compará-las após a migração será útil, mas, como você mencionou, há várias alterações que devem ser alteradas para que os resultados não sejam exatamente os mesmos e haja algum esforço manual envolvidos para comparar os resultados e garantir que atendam às expectativas.
Como já foi descrito, você planeja executar testes de regressão no aplicativo para garantir que a funcionalidade não tenha sido quebrada. Espero que você já tenha testes automatizados ou um conjunto de testes manual bem definido para a maioria disso.
Algumas coisas adicionais que eu teria cuidado com minha própria experiência pessoal:
Certifique-se de dar uma olhada nos casos de borda atuais e que eles são abordados na migração. É fácil para um desenvolvedor manipular todos os dados normalmente esperados, no entanto, sempre há casos extremos em que os dados de determinados clientes ou configurações particulares são armazenados de forma diferente e é necessário garantir que esses casos especiais sejam tratados adequadamente também. (Eu encontrei uma questão que teria causado 200.000 pessoas em um estado "especial" - de milhões - a serem bloqueadas de suas contas durante uma migração). Se o sistema estiver on-line durante a migração, (estou pensando em uma migração que pode levar horas ou mesmo dias ou semanas), certifique-se de que após o passo inicial, o processo de limpeza obtenha todos os dados desde o início do processo. a migração é tão robusta quanto o processo original. É fácil para os desenvolvedores gastarem menos tempo nesta parte, mas é tão importante quanto isso. Também é mais difícil testar se você está testando apenas com um pequeno subconjunto dos dados. Se possível, faça uma migração completa com o conjunto de dados inteiro como uma execução seca antes da migração. Mesmo que você não consiga testar todos os dados, isso dará aos desenvolvedores muitas informações e eles poderão descobrir que alguns dos seus scripts de migração geraram erros em certos dados que precisarão analisar um pouco mais de perto para garantir que eles lidem com eles. corretamente. Então vá para a cidade no seu teste de regressão.
Há um conjunto de ferramentas do Red-Gate que permitem fazer comparações de dados entre bancos de dados. Mesmo que os dados sejam armazenados de forma diferente, você pode comparar os resultados de consultas específicas, portanto, se você souber que uma consulta no sistema antigo deve ser equivalente a uma consulta no novo sistema, poderá compará-los dessa maneira.

Lista de verificação do projeto de migração de dados: um modelo para o planejamento efetivo da migração de dados.
Lista de verificação de migração de dados: planejador para migração de dados.
Lista de verificação de migração de dados: o guia definitivo para planejar sua próxima migração de dados.
A apresentação de uma lista de verificação de migração de dados para o seu projeto de migração de dados é uma das tarefas mais desafiadoras, especialmente para os não iniciados.
Para ajudar, eu compilei uma lista de atividades que eu considero essenciais para as migrações bem-sucedidas.
Não é uma lista definitiva, você quase certamente precisará adicionar mais pontos, mas é um excelente ponto de partida.
Por favor, critique-o, estenda-o usando os comentários abaixo, compartilhe-o, mas acima de tudo, use-o para garantir que você esteja totalmente preparado para o caminho desafiador pela frente.
DICA: A qualidade dos dados tem um papel fundamental nessa lista, por isso confira o Data Quality Pro, nosso site irmão com a maior coleção de tutoriais práticos, guias de qualidade de dados e suporte especializado para Data Quality na Internet.
Obtenha um kit de lista de verificação gratuito: Planilha do Project Planner + MindMap.
Sério sobre entregar uma migração de dados bem sucedida?
Faça o download do mesmo kit de lista de verificação que uso nos compromissos do cliente e aprenda táticas avançadas para o planejamento da migração de dados.
Planilha de Planejamento de Projetos (para Excel / Planilhas Google) MindMap Online Interativo (excelente para navegação)
Baixe o kit.
Nós nunca enviamos spam ou vendemos seus dados.
Fase 1: planejamento pré-migração.
Você avaliou a viabilidade de sua migração com uma avaliação de impacto pré-migração?
A maioria dos projetos de migração de dados vai direto ao projeto principal sem considerar se a migração é viável, quanto tempo levará, qual tecnologia exigirá e quais perigos estão por vir.
É aconselhável realizar uma avaliação de impacto antes da migração para verificar o custo e o provável resultado da migração. Quanto mais tarde você planeja fazer isso, maior o risco de pontuar de acordo.
Você baseou estimativas de projetos em suposições ou uma avaliação mais precisa?
Não se preocupe, você não está sozinho, a maioria dos projetos baseia-se em estimativas de projetos anteriores, na melhor das hipóteses, ou na adivinhação otimista, na pior das hipóteses.
Mais uma vez, sua avaliação de impacto pré-migração deve fornecer uma análise muito mais precisa dos requisitos de custo e recursos, portanto, se você tiver prazos apertados, uma migração complexa e recursos limitados, faça uma avaliação de impacto da migração o mais rápido possível.
Você tornou as comunidades de negócios e TI conscientes de seu envolvimento?
Faz todo o sentido informar as partes interessadas e equipes técnicas de dados relevantes de seus compromissos futuros antes que a migração comece.
Pode ser muito difícil arrastar um especialista no assunto para uma sessão de análise de 2 a 3 horas, uma vez por semana, se os idosos não estiverem a bordo, além de identificar quais recursos são necessários com antecedência, eliminará o risco de ter lacunas no seu legado ou no conjunto de habilidades de destino.
Além disso, há vários aspectos da migração que exigem aprovação e comprometimento da empresa. Chegue antecipadamente aos patrocinadores e às partes interessadas e certifique-se de que eles compreendam e concordem com o envolvimento deles.
Você já concordou formalmente com as restrições de segurança do seu projeto?
Tenho lembranças maravilhosas de uma migração em que pensávamos que tudo estava em ordem, então iniciamos o projeto e logo fomos desligados logo no primeiro dia.
Nós tínhamos assumido que as medidas de segurança que tínhamos concordado com o gerente de projetos do cliente eram suficientes, no entanto, não contamos com a equipe de segurança corporativa para entrar em ação e exigir um conjunto muito mais rigoroso de controles que causou 8 semanas de atraso no projeto.
Não cometa o mesmo erro, obtenha um acordo formal das equipes de governança de segurança relevantes com antecedência. Basta colocar a cabeça na areia e esperar que você não seja pego de surpresa é algo pouco profissional e altamente arriscado, devido à recente perda de dados em muitas organizações.
Você identificou os principais recursos do projeto de migração de dados e quando eles são necessários?
Não comece seu projeto esperando que o Jobserve ofereça magicamente os recursos que você precisa.
Conheci uma empresa há vários meses que decidiu que não precisavam de um analista de migração de dados de lead porque o "plano de projeto era tão bem definido". Basta dizer que agora eles estão se preparando para problemas, pois o projeto está fora de controle. Portanto, certifique-se de entender exatamente quais funções são necessárias em uma migração de dados.
Também garanta que você tenha um plano para incluir essas funções no projeto no momento certo.
Por exemplo, há uma tendência para lançar um projeto com um contingente completo de desenvolvedores armados com ferramentas e desejosos de ir. Isso é caro e desnecessário. Um pequeno grupo de migração de dados, qualidade de dados e analistas de negócios pode executar a maior parte da descoberta da migração e mapear bem antes que os desenvolvedores se envolvam, geralmente criando uma migração bem mais bem-sucedida.
Portanto, a lição é entender as principais atividades e dependências de migração e planejar ter os recursos certos disponíveis quando necessário.
Você determinou a estrutura ótima de entrega do projeto?
As migrações de dados não se adequam a uma abordagem em cascata, mas a grande maioria dos planos de migração de dados que eu testemunhei quase sempre se assemelha a um design clássico de cascata.
O planejamento de projeto ágil e iterativo com quedas de entrega altamente concentradas é muito mais eficaz, portanto, garanta que seu plano geral seja flexível o suficiente para lidar com os possíveis eventos de mudança que ocorrerão.
Além disso, o seu plano de projeto tem contingência suficiente? 84% das migrações falham ou sofrem atrasos, você tem certeza de que a sua não sofrerá as mesmas consequências?
Certifique-se de ter capacidade suficiente em seu plano para lidar com a ocorrência altamente provável de atraso.
Você tem um conjunto bem definido de descrições de funções para que cada membro entenda seus papéis?
O início do projeto chegará a você como um trem de carga em breve, então garanta que todos os seus recursos saibam o que se espera deles.
Se você não tiver um conjunto preciso de tarefas e responsabilidades já definidas, isso significa que você não sabe o que sua equipe deve entregar e em que ordem. Claramente não é uma situação ideal.
Mapeie a sequência de tarefas, entregas e dependências que você espera que sejam necessárias e, em seguida, atribua funções a cada atividade. Verifique sua lista de recursos, você tem os recursos certos para concluir essas tarefas?
Esta é uma área com a qual a maioria dos projetos se esforça para entender claramente o que seus recursos precisam realizar o ajudará a estar totalmente preparado para a fase de iniciação do projeto.
Você criou um fluxo de trabalho de tarefa estruturada para que cada membro possa entender quais tarefas são esperadas e em qual sequência?
Esta é uma extensão do ponto anterior, mas é extremamente importante.
A maioria dos planos de projeto terá algumas datas de entrega vagas ou cronogramas indicando quando as equipes de negócios ou técnica exigem que uma liberação ou atividade específica seja concluída.
O que isso não mostrará é o fluxo de trabalho preciso que o levará a esses pontos. Isso precisa ser idealmente definido antes do início do projeto, para que não haja confusão à medida que você entra na fase de iniciação.
Também ajudará a identificar lacunas em seu modelo de recursos, onde faltam as habilidades ou orçamentos necessários.
Você criou a documentação de treinamento apropriada e elaborou um plano de treinamento?
Os projetos de migração de dados normalmente exigem muitas ferramentas adicionais e plataformas de suporte a projetos para funcionar sem problemas.
Certifique-se de que todos os seus materiais de treinamento e ferramentas de educação sejam testados e estejam em vigor antes do início do projeto.
Idealmente, você desejaria que todos os recursos fossem totalmente treinados antes do projeto, mas se isso não for possível, pelo menos, garanta que o treinamento e a educação sejam incluídos no plano.
Você tem uma política de gerenciamento de configuração e software em vigor?
Os projetos de migração de dados criam muitos materiais de recursos. Resultados de criação de perfil, problemas de qualidade de dados, especificações de mapeamento, especificações de interface - a lista é interminável.
Certifique-se de ter uma abordagem de gerenciamento de configuração bem definida e testada antes do início do projeto, você não quer ficar tropeçando no início do projeto tentando fazer as coisas funcionarem, testá-las com antecedência e criar os materiais de treinamento necessários.
Você planejou um ambiente de trabalho seguro e colaborativo?
Se o seu projeto envolver entidades terceiras e apoio interorganizacional, vale a pena usar um produto dedicado para gerenciar todas as comunicações, materiais, planejamento e coordenação do projeto.
Ele também fará com que o seu projeto seja executado mais suavemente se estiver configurado e pronto antes do início do projeto.
Você criou um conjunto acordado de documentos de política de migração de dados?
Como a equipe do projeto deve lidar com dados de forma segura? Quem será responsável por assinar as regras de qualidade de dados? Quais procedimentos de escalonamento estarão em vigor?
Há uma infinidade de políticas diferentes necessárias para que uma migração típica ocorra sem problemas, vale a pena concordar com isso antes da migração para que a fase de início do projeto seja executada sem esforço.
Fase 2: Iniciação do Projeto.
Você criou um plano de comunicação das partes interessadas e um registro das partes interessadas?
Durante esta fase, você precisa formalizar como cada parte interessada será informada. Podemos muito bem ter criado uma política geral de antemão, mas agora precisamos instanciá-la com cada parte interessada individual.
Não crie uma lacuna de ansiedade em seu projeto, determine que nível de relatório você fornecerá para cada tipo de parte interessada e obtenha um acordo com eles no formato e na frequência. Soltá-los por e-mail seis meses depois do início do período de 8 semanas não lhe renderá nenhum favor.
Para se comunicar com as partes interessadas, obviamente, você sabe quem são e como contatá-las! Registre todos os tipos de partes interessadas e indivíduos que precisarão de contato durante todo o projeto.
Você ajustou e publicou as políticas do seu projeto?
Agora é a hora de fazer com que suas políticas sejam concluídas e circuladas por toda a equipe e por novos recrutas.
Quaisquer políticas que definam como o negócio será envolvido durante o projeto também precisam ser divulgadas e finalizadas.
Não presuma que todos saibam o que se espera deles, portanto, acostume as pessoas a aprender e assinar as políticas do projeto no início do ciclo de vida.
Você criou um plano de projeto de primeiro nível de alto nível?
Se você seguiu as melhores práticas e implementou uma avaliação de impacto antes da migração, você deve ter um nível razoável de detalhes para o seu plano de projeto. Se não, basta concluir o máximo possível com uma ressalva acordada de que os dados conduzirão o projeto. Eu ainda recomendaria a realização de uma avaliação do impacto da migração durante a fase de iniciação, independentemente das atividades de análise que ocorrerão na próxima fase.
Você não pode criar linhas do tempo precisas para o seu plano de projeto até ter analisado os dados.
Por exemplo, simplesmente criar uma janela arbitrária de 8 semanas para “atividades de limpeza de dados” não tem sentido se os dados forem considerados realmente péssimos. Também é vital que você entenda as dependências em um projeto de migração de dados. Não é possível codificar os mapeamentos até descobrir os relacionamentos, e você não pode fazer isso até que a fase de análise e descoberta seja concluída.
Also, don’t simply rely on a carbon copy of a previous data migration project plan, your plan will be dictated by the conditions found on the ground and the wider programme commitments that your particular project dictates.
Have you set up your project collaboration platform?
This should ideally have been created before project initiation but if it hasn’t now is the time to get it in place.
There are some great examples of these tools listed over at our sister community site here:
Have you created your standard project documents?
During this phase you must create your typical project documentation such as risk register, issue register, acceptance criteria, project controls, job descriptions, project progress report, change management report, RACI etc.
They do not need to be complete but they do need to be formalised with a process that everyone is aware of.
Have you defined and formalised your 3rd Party supplier agreements and requirements?
Project initiation is a great starting point to determine what additional expertise is required.
Don’t leave assumptions when engaging with external resources, there should be clear instructions on what exactly needs to be delivered, don’t leave this too late.
Have you scheduled your next phase tasks adequately?
At this phase you should be meticulously planning your next phase activities so ensure that the business and IT communities are aware of the workshops they will be involved in.
Have you resolved any security issues and gained approved access to the legacy datasets?
Don’t assume that because your project has been signed off you will automatically be granted access to the data.
Get approvals from security representatives (before this phase if possible) and consult with IT on how you will be able to analyse the legacy and source systems without impacting the business. Full extracts of data on a secure, independent analysis platform is the best option but you may have to compromise.
It is advisable to create a security policy for the project so that everyone is aware of their responsibilities and the professional approach you will be taking on the project.
Have you defined the hardware and software requirements for the later phases?
What machines will the team run on? What software will they need? What licenses will you require at each phase? Sounds obvious, not for one recent project manager who completely forgot to put the order in and had to watch 7 members of his team sitting idly by as the purchase order crawled through procurement. Don’t make the same mistake, look at each phase of the project and determine what will be required.
Model re-engineering tools? Data quality profiling tools? Data cleansing tools? Project management software? Presentation software? Reporting software? Issue tracking software? ETL tools?
You will also need to determine what operating systems, hardware and licensing is required to build your analysis, test, QA and production servers. It can often take weeks to procure this kind of equipment so you ideally need to have done this even before project initiation.
Phase 3: Landscape Analysis.
Have you created a detailed data dictionary?
A data dictionary can mean many things to many people but it is advisable to create a simple catalogue of all the information you have retrieved on the data under assessment. Make this tool easy to search, accessible but with role-based security in place where required. A project wiki is a useful tool in this respect.
Have you created a high-level source to target mapping specification?
At this stage you will not have a complete source-to-target specification but you should have identified the high-level objects and relationships that will be linked during the migration. These will be further analysed in the later design phase.
Have you determined high-level volumetrics and created a high-level scoping report?
It is important that you do not fall foul of the load-rate bottleneck problem so to prevent this situation ensure that you fully assess the scope and volume of data to be migrated.
Focus on pruning data that is historical or surplus to requirements (see here for advice). Create a final scoping report detailing what will be in scope for the migration and get the business to sign this off.
Has the risk management process been shared with the team and have they updated the risk register?
There will be many risks discovered during this phase so make it easy for risks to be recorded. Create a simple online form where anyone can add risks during their analysis, you can also filter them out later but for now we need to gather as many as possible and see where any major issues are coming from.
Have you created a data quality management process and impact report?
If you’ve been following our online coaching calls you will know that without a robust data quality rules management process your project will almost certainly fail or experience delays.
Understand the concept of data quality rules discovery, management and resolution so you deliver a migration that is fit for purpose.
The data quality process is not a one-stop effort, it will continue throughout the project but at this phase we are concerned with discovering the impact of the data so decisions can be made that could affect project timescales, deliverables, budget, resourcing etc.
Have you created and shared a first-cut system retirement strategy?
Now is the time to begin warming up the business to the fact that their beloved systems will be decommissioned post-migration. Ensure that they are briefed on the aims of the project and start the process of discovering what is required to terminate the legacy systems. Better to approach this now than to leave it until later in the project when politics may prevent progress.
Have you created conceptual/logical/physical and common models?
These models are incredibly important for communicating and defining the structure of the legacy and target environments.
The reason we have so many modelling layers is so that we understand all aspects of the migration from the deeply technical through to how the business community run operations today and how they wish to run operations in the future. We will be discussing the project with various business and IT groups so the different models help us to convey meaning for the appropriate community.
Creating conceptual and logical models also help us to identify gaps in thinking or design between the source and target environments far earlier in the project so we can make corrections to the solution design.
Have you refined your project estimates?
Most projects start with some vague notion of how long each phase will take. Use your landscape analysis phase to determine the likely timescales based on data quality, complexity, resources available, technology constraints and a host of other factors that will help you determine how to estimate the project timelines.
Phase 4: Solution Design.
Have you created a detailed mapping design specification?
By the end of this phase you should have a thorough specification of how the source and target objects will be mapped, down to attribute level. This needs to be at a sufficient level to be passed to a developer for implementation in a data migration tool.
Note that we do not progress immediately into build following landscape analysis. It is far more cost-effective to map out the migration using specifications as opposed to coding which can prove expensive and more complex to re-design if issues are discovered.
Have you created an interface design specification?
At the end of this stage you should have a firm design for any interface designs that are required to extract the data from your legacy systems or to load the data into the target systems. For example, some migrations require change data capture functionality so this needs to be designed and prototyped during this phase.
Have you created a data quality management specification?
This will define how you plan to manage the various data quality issues discovered during the landscape analysis phase. These may fall into certain categories such as:
Ignore Cleanse in source Cleanse in staging process Cleanse in-flight using coding logic Cleanse on target.
Have you defined your production hardware requirements?
At this stage you should have a much firmer idea of what technology will be required in the production environment.
The volumetrics and interface throughput performance should be known so you should be able to specify the appropriate equipment, RAID configurations, operating system etc.
Have you agreed the service level agreements for the migration?
At this phase it is advisable to agree with the business sponsors what your migration will deliver, by when and to what quality.
Quality, cost and time are variables that need to be agreed upon prior to the build phase so ensure that your sponsors are aware of the design limitations of the migration and exactly what that will mean to the business services they plan to launch on the target platform.
Phase 5: Build & Teste.
Has your build team documented the migration logic?
The team managing the migration execution may not be the team responsible for coding the migration logic.
It is therefore essential that the transformations and rules that were used to map the legacy and target environments are accurately published. This will allow the execution team to analyse the root-cause of any subsequent issues discovered.
Have you tested the migration with a mirror of the live environment?
It is advisable to test the migration with data from the production environment, not a smaller sample set. By limiting your test data sample you will almost certainly run into conditions within the live data that cause a defect in your migration at runtime.
Have you developed an independent migration validation engine?
Many projects base the success of migration on how many “fall-outs” they witness during the process. This is typically where an item of data cannot be migrated due to some constraint or rule violation in the target or transformation data stores. They then go on to resolve these fall-outs and when no more loading issues are found carry out some basic volumetric testing.
“We had 10,000 customers in our legacy system and we now have 10,000 customers in our target, job done”.
We recently took a call community member based in Oman. Their hospital had subcontracted a data migration to a company who had since completed the project. Several months after the migration project they discovered that many thousands of patients now had incomplete records, missing attributes and generally sub-standard data quality.
It is advisable to devise a solution that will independently assess the success of the execution phase. Do not rely on the reports and stats coming back from your migration tool as a basis for how successful the migration was.
I advise clients to vet the migration independently, using a completely different supplier where budgets permit. Once the migration project has officially terminated and those specialist resources have left for new projects it can be incredibly difficult to resolve serious issues so start to build a method of validating the migration during this phase, don’t leave it until project execution, it will be too late.
Have you defined your reporting strategy and associated technology?
Following on from the previous point, you need to create a robust reporting strategy so that the various roles involved in the project execution can see progress in a format that suits them.
For example, a migration manager may wish to see daily statistics, a migration operator will need to see runtime statistics and a business sponsor may wish to see weekly performance etc.
If you have created service level agreements for migration success these need to be incorporated into the reporting strategy so that you can track and verify progress against each SLA.
Have you defined an ongoing data quality monitoring solution?
Data quality is continuous and it should certainly not cease when the migration has been delivered as there can be a range of insidious data defects lurking in the migrated data previously undetected.
In addition, the new users of the system may well introduce errors through inexperience so plan for this now by building an ongoing data quality monitoring environment for the target platform.
A useful tool here is any data quality product that can allow you to create specific data quality rules, possesses matching functionality and also has a dashboard element.
Have you created a migration fallback policy?
What if the migration fails? How will you rollback? What needs to be done to facilitate this?
Hope for the best but plan for the worst case scenario which is an failed migration. This can often be incredibly complex and require cross-organisation support so plan well in advance of execution.
Have you confirmed your legacy decommission strategy?
By now you should have a clear approach, with full agreement, of how you will decommission the legacy environment following the migration execution.
Have you completed any relevant execution training?
The team running the execution phase may differ to those on the build phase, it goes without saying that the migration execution can be complex so ensure that the relevant training materials are planned for and delivered by the end of this phase.
Have you obtained sign-off for anticipated data quality levels in the target?
It is rare that all data defects can be resolved but at this stage you should certainly know what they are and what impact they will cause.
The data is not your responsibility however, it belongs to the business so ensure they sign off any anticipated issues so that they are fully aware of the limitations the data presents.
Have you defined the data migration execution strategy?
Some migrations can take a few hours, some can run into years.
You will need to create a very detailed plan for how the migration execution will take place. This will include sections such as what data will be moved, who will sign-off each phase, what tests will be carried out, what data quality levels are anticipated, when will the business be able to use the data, what transition measures need to be taken.
This can become quite a considerable activity so as ever, plan well in advance.
Have you created a gap-analysis process for measuring actual vs current progress?
This is particularly appropriate on larger scale migrations.
If you have indicated to the business that you will be executing the migration over an 8 week period and that specific deliverables will be created you can then map that out in an excel chart with time points and anticipated volumetrics.
As your migration executes you can then chart actual vs estimated so you can identify any gaps.
Phase 6: Execute & Validar.
Have you kept an accurate log of SLA progress?
You will need to demonstrate to the business sponsors and independent auditors that your migration has been compliant. How you will do this varies but if you have agreed SLA’s in advance these need to be reported against.
Have you independently validated the migration?
Already covered this but worth stressing again that you cannot rely on your migration architecture to validate the migration. An independent process must be taken to ensure that the migration process has delivered the data to a sufficient quality level to support the target services.
Phase 7: Decommission & Monitor.
Have you completed your system retirement validation?
There will typically be a number of pre-conditions that need to be met before a system can be terminated.
Ensure that these are fully documented and agreed (this should have been done earlier) so you can begin confirming that the migration has met these conditions.
Have you handed over ownership of the data quality monitoring environment?
Close down your project by passing over the process and technology adopted to measure data quality during the project.
Please note that this list is not exhaustive, there are many more activities that could be added here but it should provide you with a reasonable starting point.
You may also find that many of these activities are not required for your type of migration but are included for clarity, as ever, your migration is unique so will require specific actions to be taken that are not on this list.

O gerente de projetos de TI praticando.
Notícias, artigos, The Weekly Round-up e The IT PM Book Store.
Validating Data Conversion.
Este post foi extensivamente atualizado e incorporado ao meu novo livro, The Data Conversion Cycle: Um guia para a migração de transações e outros registros para equipes de implementação do sistema. Agora disponível na Amazon, tanto no formato Kindle, por US $ 4,49, quanto no paperback, por US $ 6,99.
Continuing the series on the data conversion cycle: subsequent to any bulk load of data from another system, the accuracy and completeness of the data in the target system must be assessed. This process is generally referred to as validation, and it has three objectives:
Identify errors in mapping data elements between systems Identify errors in the source system extraction processes Identify errors in the source system records.
As you can see from the diagram below, the validation process is the key feedback point in the data conversion cycle.
Validation typically uses several techniques, selected based on the nature of the data being inspected. Eles incluem:
Application level comparison – A user logs in to each system and compares the information in the source system with the information in the target system. This is the most labor-intensive technique, but invaluable for confirming that the data elements were mapped to the correct fields in the target system (Objective 1). Report level comparison – A user or analyst compares a report from the source system with a report containing the same records, prepared from the target system. The reviewer looks for differences in the number of records, and incorrect or truncated values. Once identified, a member of the conversion team should investigate whether the difference was caused by the extraction process (Objective 2) or resulted from issues in the source system (Objective 3). This technique doesn’t require access to the system, or even knowledge of the data or subject matter. However, it can be fairly labor intensive. This technique is best used when reviewing data with a limited number of values, such as assignment to an organization, as arbitrary values are difficult to compare. Excel vlookup automated comparison – An analyst prepares an Excel workbook using the data extracted from the source system in one worksheet, and the corresponding data extracted from the target system in another worksheet. An automated comparison in a third worksheet is then possible using vlookup and other analytical functions within Excel. This approach requires more preparation, but is usually fastest in execution, especially when inspecting very large numbers of records containing arbitrary values, such as strings (names and addresses), dates, and numerical values. As with report level comparison, differences are investigated to determine whether the root cause was the extraction process (Objective 2) or an error in the source system (Objective 3).
Much like Chinese cooking, most of the labor in a data validation exercise is in the preparation. To that end, validation planning should include an analysis of the data being loaded to the source system, to determine the following:
What user-accessible field mappings have been made? It may be possible to identify one or two users with the access rights to check all of the mappings, using application level comparison. Note that it is not necessary to check multiple records; the purpose is to ensure that the data is “landing on the correct runway.” Based on the records types being loaded, are there delivered audit reports built into the target system that can facilitate a report level comparison with the source? If there isn’t a complete correlation between the two systems, generally a custom report can be derived from an existing report, either on the source or target system, to facilitate the comparison. Which data elements would be difficult to compare visually, in a report level comparison? It is useful to identify the specific fields requiring an automated comparison, so that custom reports can be created in advance to extract the records for loading into Excel. It is also common practice to load the source records into the worksheets and prepare the comparison worksheet while the data is being loaded into the target system, to save time. What dependencies exist? Usually, there are no dependencies in the inspection process, because the data, once loaded, is static. However, if there are issues that will impact the availability of conversion resources, they should be identified in advance.
A well-planned and coordinated validation process can proceed on a broad front, with a number of workers inspecting specific record types, using specified tools and techniques. The team should have the goal of minimizing the time required to conduct validation, as it is the final step before a move to production. This is critical, in that during the time between the final extract of data from the legacy system used as the source, to the move of the new system to production, transaction will continue to be processed. These transactions must then be re-entered into the new system.
The validation process falls between loading the data to the target system and actually using it, in every cycle. Whether that initial use is development, testing, or production, the process needs to be followed. Note that validation findings of the final load before the move to production may have to be subjected to a triage process, in that any corrections will have to be made in that production system. Consequently, the principal measure of success of validation in earlier cycles should be the elimination of sources of error . A solid validation and correction process should reduce the number of corrections in production to nearly zero.
Next week, I’ll address creating a data conversion plan, based on the data conversion cycle, and integrating it into the overall project plan.

Ruma Dak's Blog.
Data is vital for any kind of application. Maintaining the quality & integrity of data is a task of utmost importance and hence any change related to data calls for a formal strategy for testing. The strategy would depend on factors like business criticality of the data, time available, budget etc. and needs to be tailored according to the application itself.
What is Data Migration or Conversion?
Data Migration, in very simple terms, means moving the data from one environment/system to another. It can be done for variety of reasons like upgrading the version of existing DB, change from one DB to another, upgrades in servers, relocation of data centers etc.
For a complex application with large volumes of data, this can be quite a challenging task. The scope of the project needs to be analysed carefully to craft the testing strategy. Data migration projects can be carried out in big bang approach as well as in incremental fashion.
Data corruption: Its highly likely that data gets corrupted during migration. Target DB might allow loading of corrupt data but the application will crash as a result. Loss of data: Doesn’t need much explanation to define how important it is to not loose any data. Semantics Risks: These refer to the faults which can happen if units for some field are not same in source and target Databases. for example unit for currency in source and target DB might differ. Data inconsistency issues would arise if 1 INR is referred to as 1 USD in the two DBs. Another example could be one DB considering the currency filed upto two decimal points as opposed to three in the other. Extended Downtime: If the time taken to do the migration or conversion is long, it may increase the downtime for the application. Applies more to application with strict SLAs like banking applications. Orchestration Risks: The dependency between various objects has to be considered while migrating the data. A person’s details cannot be migrated before migrating the person object itself. The order of migration activities is important. Performance of DB after the migration/Conversion. Application Stability Risk: After the migration, user should be able to perform valid expected operations on migrated data. Similarly, creation of new data and related operations should be possible. Migrated data should not hamper application’s functionality in any way. Operational Risks: If the source DB is used while migrating the data, the data might change leading to inconsistency of data in target DB. It can also cause locking of tables. Target Parameterization Risks: These arise if the target application changes during migration and it becomes incompatible to the migrated data. Assessing the existing Data: The existing data need to be assessed in terms of quality and existing issues. It can be huge pitfall if the nature and behaviour of existing data is unknown or ambiguous beforehand.
All the above risks can be mitigated or catered to by mitigation techniques and strategised testing:
Tests for Data Integrity : The database is checked for any missing data to ensure that all data has been migrated successfully from source to target. Apart from this, testing has to keep an eye on any unwanted data appearing in the target database. UI tests and processing of data will also help identify some issues.
Tests for Semantic Risks : This can be done by comparing the target and source DBs using suitable techniques. Depending on the application, UI tests can also pick up some issues. Sometimes, processing of migrated data might help catch issues. Corrupt Data : This can be the easiest or the most difficult part to test for depending on the complexity of the application, which data gets corrupt, user’s familiarity with the application and so on. Like mentioned in above two points, UI Tests and processing of data are the best testing ways to catch bugs in this area. Integration tests can also be helpful depending on the application. Operational Risks : These risks are to be managed by following a proper process.
What does Testing team need to do/know/take care of?
Understand how your application plays with the data, how can it create/transform/use/process the data.
Identify all the interfaces to and from your application. Save a copy of source and target DBs so you can redo your tests any time on a fresh copy. Involve the stakeholders and Business people in the migration plan. Its very important to get the right people participate at the right time.
Typically, testing for Data Migration is of two types:
These tests aim to :
a) Check Completeness and Integrity of data. b) Find Semantic Errors c) Verify Application Stability d) Verify all Interfaces with the application. e) Perform Appearance Tests which shortlist business critical objects fpr testing after consultation with Business experts.
These validate every aspect of the migration programs from extract, filter & transform and load to the target.
& # 8212; Full Migration tests – Run using the full data set and help find out the time required for the migration.
& # 8212; Partial Migration Run Tests – These can be done to speed-up the development cycles and used to guesstimate the expected execution time which may or may not be accurate.