Estratégia de migração 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 teste 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 no banco 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-se melhor” aos 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 a seco 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 facto para testar dados e migrações de conteúdo depende da amostragem, em que algum subconjunto de dados ou conteúdo aleatórios é selecionado e inspecionado para garantir que a migração foi 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 sobre 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 as 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.

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 projeto 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 causaram 8 semanas de atraso do 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, para garantir 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 considerados 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.
Assegure-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 funcionar, 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 prazo para um atraso de oito 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 pré-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.
Além disso, não confie apenas em uma cópia em carbono de um plano de projeto de migração de dados anterior, seu plano será ditado pelas condições encontradas no local e pelos compromissos mais amplos do programa que seu projeto em particular determina.
Você configurou sua plataforma de colaboração de projetos?
Idealmente, isso deve ter sido criado antes do início do projeto, mas se não for agora, é hora de implementá-lo.
Existem alguns ótimos exemplos dessas ferramentas listadas em nosso site da comunidade irmã aqui:
Você criou seus documentos de projeto padrão?
Durante esta fase, você deve criar a documentação típica do projeto, como registro de riscos, registro de problemas, critérios de aceitação, controles de projeto, descrições de cargos, relatório de andamento do projeto, relatório de gerenciamento de alterações, RACI etc.
Eles não precisam ser completos, mas precisam ser formalizados com um processo que todos conhecem.
Você definiu e formalizou seus contratos e requisitos de fornecedores terceirizados?
A iniciação do projeto é um excelente ponto de partida para determinar qual expertise adicional é necessária.
Não deixe suposições ao se envolver com recursos externos, deve haver instruções claras sobre o que exatamente precisa ser entregue, não deixe isso muito tarde.
Você programou suas próximas tarefas de fase de forma adequada?
Nesta fase você deve planejar meticulosamente as atividades da sua próxima fase para garantir que as comunidades de negócios e de TI estejam cientes dos workshops em que estarão envolvidos.
Você resolveu algum problema de segurança e obteve acesso aprovado aos conjuntos de dados herdados?
Não presuma que, como seu projeto foi encerrado, você receberá automaticamente acesso aos dados.
Obtenha aprovações de representantes de segurança (antes dessa fase, se possível) e consulte a equipe de TI sobre como você poderá analisar os sistemas herdados e de origem sem afetar os negócios. Extratos completos de dados em uma plataforma de análise segura e independente é a melhor opção, mas você pode ter que comprometer.
É aconselhável criar uma política de segurança para o projeto, para que todos estejam cientes de suas responsabilidades e da abordagem profissional que você estará assumindo no projeto.
Você definiu os requisitos de hardware e software para as fases posteriores?
Em quais máquinas a equipe funcionará? Qual software eles precisarão? Quais licenças você precisará em cada fase? Parece óbvio, não para um gerente de projeto recente que esqueceu completamente de fazer o pedido e teve que assistir sete membros de sua equipe sentados à toa enquanto o pedido de compra era rastreado através de compras. Não cometa o mesmo erro, examine cada fase do projeto e determine o que será necessário.
Ferramentas de reengenharia de modelos? Ferramentas de perfil de qualidade de dados? Ferramentas de limpeza de dados? Software de gerenciamento de projetos? Software de apresentação? Software de relatórios? Emitir software de rastreamento? Ferramentas de ETL?
Você também precisará determinar quais sistemas operacionais, hardware e licenciamento são necessários para construir seus servidores de análise, teste, controle de qualidade e produção. Muitas vezes, pode levar semanas para adquirir esse tipo de equipamento, de modo que você, idealmente, precisa ter feito isso antes mesmo do início do projeto.
Fase 3: Análise de Paisagem.
Você criou um dicionário de dados detalhado?
Um dicionário de dados pode significar muitas coisas para muitas pessoas, mas é aconselhável criar um catálogo simples de todas as informações que você recuperou nos dados sob avaliação. Torne esta ferramenta fácil de pesquisar, acessível, mas com segurança baseada em funções, sempre que necessário. Um wiki de projeto é uma ferramenta útil nesse aspecto.
Você criou uma fonte de alto nível para direcionar a especificação de mapeamento?
Neste estágio, você não terá uma especificação completa de origem para destino, mas deverá ter identificado os objetos e relacionamentos de alto nível que serão vinculados durante a migração. Estes serão analisados ​​posteriormente na fase posterior do projeto.
Você já determinou a volumetria de alto nível e criou um relatório de escopo de alto nível?
É importante que você não tenha problemas com o problema de afunilamento de taxa de carregamento, portanto, para evitar essa situação, assegure-se de avaliar completamente o escopo e o volume de dados a serem migrados.
Concentre-se na remoção de dados históricos ou excedentes de requisitos (consulte aqui para obter conselhos). Crie um relatório de escopo final detalhando o que estará no escopo para a migração e faça a empresa assinar isso.
O processo de gerenciamento de riscos foi compartilhado com a equipe e eles atualizaram o registro de riscos?
Haverá muitos riscos descobertos durante essa fase, para facilitar a gravação de riscos. Crie um formulário on-line simples, onde qualquer um pode adicionar riscos durante a análise, você também pode filtrá-los mais tarde, mas, por enquanto, precisamos reunir o maior número possível e ver de onde vêm os principais problemas.
Você criou um processo de gerenciamento de qualidade de dados e um relatório de impacto?
Se você tem acompanhado nossas chamadas de coaching on-line, saberá que, sem um processo robusto de gerenciamento de regras de qualidade de dados, seu projeto quase certamente falhará ou sofrerá atrasos.
Entenda o conceito de descoberta, gerenciamento e resolução de regras de qualidade de dados para que você forneça uma migração que seja adequada ao propósito.
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.

Data migration strategies.
Even though from some points of view data migration seems problematical and difficult to apply, no one actually doubts in its necessity. More or less regularly almost all companies which operate on data have to update their systems, applications, platforms. It's a natural situation which originates from the fact that not only computer systems are changing, but also so is business. What it means is the fact that a need for data migration might not only be a consequence of data storage system becoming outdated, but also the result of changing business condition. Ensuring the best data quality, also through efficient data migration, is crucial to responsible management in 21st century world.
Data migration, being a method for letting data originated from one source be compatible with another which it's going to be loaded into, is simple only at first sight. The deeper one knows the problem, the more questions he has, beginning with the most important one - how to make company suffer least because of data migration. In fact, it depends on chosen strategy. Basically, there are two different strategies, two different approaches to data migration. And they differ mainly in the way migration is proceeded.
Big bang migration.
The first strategy, called big bang migration, is someway uncompromising. In a word, it suggests shutting all applications and databases immediately, stopping the work and putting all force in data migration. In fact, it really seems to be a good option, because only this way guarantees that the migration lasts as short as possible. Moreover, it almost eliminates the risk that something unpredicted happens during the process. On the other hand though big bang migration might be destructive to organization's work. Especially in cases of companies which depend on data in a real time, being cut from data might be a real problem.
There is, of course, a way to minimize the negative influence of big bang migrations. In most companies which decide to choose this type of data migration strategy, the process is being initialized after work hours or on holidays. This way, cutting off the access to data may cause the least problems.

Data conversion migration strategy

Data migration is the process of making a copy of data and moving it from one device or system to another, preferably without disrupting or disabling active business processing. After data is transferred, processing uses the new device or system. There are a variety of business drivers that cause enterprises to undertake a data migration, including:
Deployment of a new operating or application system Take-on of new users or businesses onto an existing system (mergers, acquisitions, etc.) Server or storage technology replacement or upgrade Server or storage consolidation Changes to database schemas and structure Relocation of the data center Server or storage equipment maintenance Workload balancing or other performance-related tuning.
In most organizations, data migrations are routine operations – according to a 2005 survey by Softek, more than 60% of respondents migrate data quarterly or more often - with 19% migrating weekly. So they have to be done effectively and in a controlled environment to assure data integrity, compatibility, low downtime, and security as well as a seamless migration process.
Effective data migration strategies.
Many organizations migrate data as part of the process of upgrading controls (think Sarbanes-Oxley), systems, or storage. Enterprises need to minimize the business impacts of data migration - downtime, data integrity issues, costs, control problems, and so on. The way to do this is to utilize a robust methodology for migrations, which we discuss in this note. A majority of respondents to data migration surveys report one problem or another with these migrations. Simply scheduling migrations during “off-hours” is not always a sufficient strategy, since:
it increases migration costs and decreases employee morale due to staff overtime migrations which go over schedule can disrupt processing during normal hours most enterprises no longer have a significant “off-hour” window for activities like data backups or data migrations due to their global operations or other customer demands for availability.
Effective data migration strategies go a step further and can avoid such risks, as we will see.
Specific operational goals of effective data migration.
There are specific goals associated with implementing an effective data migration strategy. Primarily, data must be migrated from the source platform to the target platform completely and accurately, and according to company and regulatory policies on information controls and security. This means no dropped or incomplete records, and no data fields that fail validation or other quality controls in the target environment. Another goal of data migration is that the process be done quickly, with as short a downtime window as possible (given the enterprise's Maintenance Time Objective targets.) Finally, the cost of data migration must be manageable, in terms of technology and staff requirements.
There are many metrics that can measure the effectiveness and efficiency of data migrations: Number of online customizations required Percentage of migrated records Percentage of migrated tables Percentage of migrated records by technology Percentage of migrated records by application Percentage of data with quality problems Number of migration errors Migration impact on database size Downtime due to migration Required staging storage / hardware Percentage of reconciliation errors Percentage of cleansed data.
Risks of implementing an effective data migration strategy.
Migrating data brings many risks and challenges:
Migration might be done as part of a larger chain of dependencies (operating system upgrades, application upgrades or implementations, database structural changes, etc.) – thereby increasing complexity. Data requirements are not clearly defined - data rules for integrity, controls, security, availability and recoverability are often ill-defined. In the absence of such rules, data is migrated incorrectly. Migration acceptance criteria may not be defined. Data is often too distributed to be migrated easily (think end-user computing). Budgets may limit technology options for performing migrations. Expertise in data migration and management may not be present. Management attention might be insufficient (migrations are typically “routine” operations and not major attention-getting projects). There could be poor support from the storage vendor(s), making migrations all the more taxing.
The effective data migration strategy.
The business driver for effective data migrations is to strike the optimal balance between data accuracy, migration speed, low or no downtime, and minimum costs. We will see how to formulate such a strategy.
Expectations (Out-of-scope)
To a large extent the enterprise’s storage technology, storage management tools, and storage network capabilities define the range of possibilities for data migration strategies. Selection of such is out of scope of this note; however, we will introduce a methodology for data migration strategy that can work under most technology environments.
Analyze phase.
The first stage of data migration is data classification. It is important to know how and where data is stored, backed up, and archived. Data structures must be well understood, and there should be visibility into the data’s usage, capacity, and growth patterns. Various interfaces and reports utilizing the to-be-migrated data must be considered. It is also important to understand the network connections between data points (especially required bandwidth and controls). Data classification also describes conditions for data access, retention requirements and control & security measures such as encryption. Next, migration requirements are determined. Beyond the “top three” requirements of what must be migrated, how much downtime is acceptable, and how much budget is available, there are other needs that must be considered. These can include quality requirements, new or modified service-level agreements, expectations for the new storage infrastructure, and objectives such as reduced management costs, reduced storage expenditures, greater insight into expenditure, a simplified vendor model or greater technical flexibility or stability. If the organization has standards or policies concerning data, these must be factored in. Finally, analysts must take into account historical data to be migrated (which is often forgotten until it is late in the game).
Then there are technology considerations, such as:
How old is the operating system(s) under which data is to be migrated? Some migration tools do not support legacy operating systems. Which storage tiers and devices are involved? Can identical data structures be used for the target data (this will reduce the time and complexity of migration)? What staging area requirements are present, given current technologies and data migration requirements? Do you need or want the option to recover quickly from the source disk, or to fall back to the original storage device as a fail-over? There are both procedural and technological ways of accomplishing this. Is a central console needed to manage data migrations across multiple servers? Is there a need to control the data migration from a local server – or a remote server? If remote, which protocols must be supported? Is there a requirement to throttle or control data flows between servers? Must data integrity be checked during (not just after) migration? Which staff or consultants are available to assist with migration analysis, design, and deployment?
Data may be migrated in several ways:
All at once In logical sections (by application, operating system, database, business function, etc.) Via a pilot migration or parallel run for “proof of concept” or risk mitigation. In phases (first critical data, then less critical or historical data).
Acceptance Test Considerations.
The Analyze Phase is complete when data has been classified, data migration requirements are clear, and technology considerations have been considered. For organizations with an established data classification program (that typically includes government entities, regulated firms, and enterprises complying with quality standards) this can be done in a week or two. If a full data classification must be done as well, that can add another few weeks.
Key analysis milestones.
Milestones in the Analysis Phase typically include the following:
Legacy data and report analysis and profiles has been completed. There is an updated data classification document. The data migration strategy document has been written. Data exception report requirements are clear. Audit and reconciliation report requirements are defined. Data migration requirements (business and technology) are documented.
Design phase.
The design phase involves taking the data classification and requirements defined in the analysis phase and puts definition around how these will be realized:
The responsibilities, roles and tasks for each individual, department, or external consultant involved in migration are determined. Data elements are mapped from source to target. A plan for freezing physical data structures during the migration is put together. Any tools to be used in the migration (data transformation tools, migration options, data mapping tools, CASE or other data modeling tools, simple spreadsheets, etc.) are identified or acquired. Any software to facilitate data extraction or checking is developed. Clear acceptance criteria are determined and agreed.
Where economically viable (large volumes of data to migrate, frequent mission-critical migrations, complex data structures, high data quality requirements) data transformation tools can offer the following advantages over simple spreadsheets:
They provide flexible reporting of data elements and rules. They can generate migration code or scripts directly from the mapping rules. They can detect data integrity violations.
Acceptance test considerations.
The Design Phase is complete when migration staffing has been confirmed, data mapping is complete, a plan for freezing data structures is in place, tools have been identified, and acceptance criteria have been agreed. The length of the design phase depends mainly on the need to acquire additional migration tools and the need to develop extraction, loading, and quality checking software. If such tools and software are in place and simply need to be customized, the design phase can take place in a few weeks; otherwise, this process can take a few months.
Key design milestones.
Milestones in the Design Phase include the following:
Roles, responsibilities, and task assignments are clear and accepted. Data elements are mapped from source to target. A plan for freezing physical data structures during the migration is put together. Migration tools are identified. Migration software is developed. A migration strategy is chosen. Acceptance criteria are agreed. Funding for staff, consultants, and tools has been secured.
Deploy phase.
The first step in the design stage is to put together a project plan and structure. As part of this process there should be close analysis of any dependencies in data migrations; where possible, such dependencies and complexities should be reduced to better manage deployment risk. During the deploy phase the following occurs:
Physical data structures are frozen on source and target. Interfaces and processing on source and target are brought down where required. Data is staged from the source location. Quality reports are run and any data errors or inconsistencies identified. Data quality issues are fixed in the staging area. A preliminary reconciliation takes place in the staging area, and any reconciling items are investigated and resolved. Data is migrated to the target location. Reconciliation reports are run. Acceptance criteria are check; if reconciliation errors or other criteria are not met, the system is rolled back to the original data source. Otherwise, interfaces and processing from the source is discontinued and then activated on the target. The above may be conducted in phases, or as part of a parallel run or pilot depending upon the migration approach chosen.
Acceptance Test Considerations.
Testing and implementation are inseparable in a data migration. Physical errors are typically syntactical in nature and can be easily identified and resolved through syntax corrections in the migration scripts. Logical errors are due to problems with the data mapping. Looking into these requires asking questions like:
How many records did we expect this script to create? Did the correct number of records get created? If not, why? Has the data been loaded into the correct fields? Is the data load complete – or are certain fields missing? Has the data been formatted correctly? Are any post-migration clean-up tasks in order?
The goal of a successful data migration is to keep the length of the deploy phase(s) to a minimum. What is acceptable depends upon the organization – some will want this phase to last no more than a day (or less), others can tolerate a deployment that lasts a few days if availability is not a major concern.
Key deployment milestones.
Milestones in the Deploy Phase include the following:
Project plan in place and agreed. Project team is formed. A test plan is written. The migration takes place. Reconciliation / data checking reports are run. Acceptance criteria and performance metrics are evaluated. A go / no-go decision takes place. Data issues may be resolved post-migration.
Initiative summary.
Data migrations are rarely seen as “value-added” technology activities, but rather as a “necessary evil” deriving from the need to consolidate storage, implement stronger technology controls, upgrade / replace systems, and merge / rationalize technologies. This makes keeping management focus – the holders of IT budget – a particular challenge. Therefore it is necessary to present a strong business case to them that outlines the business advantages of controlled data migrations, justified in traditional cost-benefit form. A clear migration must support that business case, bringing together all of the pieces of the puzzle – storage and tool vendor support, internal or external staffing, requirements, and performance metrics.
Where the enterprise already possesses staffing, tools, and experience, migrations become a matter of staffing costs and the objective becomes minimizing staff time necessary to perform migrations (accomplished through clear strategy, requirements, design, and implementation planning). Data migration tools can cost from tens to hundreds of thousands of dollars, and good data analysts and developers can cost from $80,000 to over $100,000 in major IT markets.

Organize and code your data migration effectively.
There are several valuable articles around the internet that provides general overview and strategy for data migration or data conversion method (for example The Complete Data Migration Methodology by Joseph R. Hudicka, Dulcian, Inc., dulcian/papers/The%20Complete%20Data%20Migration%20Methodology. html) but I couldn’t find an article that described more technical information about data migration. This article tries to fill this gap and only shortly describes chosen strategy and provides more technical details that are specific for data migration from an old application to the new one.
Data migration from the old system was part of a new application we recently finished. Data model of the old system was completely different from the new one. Old data were stored in 8i Oracle and had to be moved to new application in Oracle 9i. Total amount of data to migrate wasn’t very big (several gigabytes) but it was spread off on.
100 tables and included more than 40 million records. We had one definite positive factor – our client knew old application well even in table and column level, so our task was to gather information, identify what should be migrated and what shouldn’t, develop SRS for migration, develop code and test results.
Establishing migration strategy.
In order to avoid a big monstrous migration problem all data were divided in several logically separated groups called data groups that can be processed serially. Of course they had some dependencies, for example classifier data group has to be migrated first of all. Division provided obvious benefits such as easier planning for project manager, each analyst could focus on a tighter problem and software for migration of each data group could be produced separately.
All data groups were migrated by the same scenario – source data from the system that has to be migrated were moved to migration environment, I’ll refer to them as migration data later. In migration environment they were processed in such a manner that they could be almost without any change moved to our new application data base, let’s call them target data . Such a process gave us following benefits:
Source data remained unchanged. In case of emergence no harm was done to them; All migration process except initial data copy could be done away from old production server; All changes in migration process could easily be tracked. One could without any problems restore link from migration data to source data, track how they has been changed and how they looked when inserted into target data base; Migration process could be easily restarted if necessary.
During the migration process two kinds of operations were applied to migration data:
Validations – checked whether a row satisfied a certain criteria e. g. if a column was not null or values was in specified range. Validations were either warnings i. e. a flag was set for a row that violated a validation but further processing could be done or errors i. e. a row violated validation and couldn’t be processed further. Validations didn’t change any business data they only set the appropriate flag. Both warnings and errors were logged in a separate table for further examination if necessary. Transformations – made actual changes to business data and examples started with simple sequence number assign and ended with complex data derivation depending on some other data.
During migration analysis all validations and transformations were identified and they were uniquely ordered for each data group. Of course such an approach led to identification of global validations and transformations that improved overall data migration quality i. e. helped us not to forget a common validation and transformation and make them in a consistent way.
As a result separate System Requirements/Design Specification ( SRS ) for each data group and one global SRS was produced generally containing following information:
Listed prerequisites for the migration of a particular data group; Identified source tables that has to be migrated for the particular data group; Described all migration tables that stored migration data; Described and enumerated all validations and transformations that had to be applied to the data group.
Next chapter will describe how logical units mentioned in SRSes can be mapped to real PL/SQL code.
Transforming requirements to code.
All migration was done in PL/SQL packages. Generally one package was created for each data group and one procedure for one or more validation and transformation. In development of migration code one has to consider following differences between migration code and usual OLTP application code:
Used once vs. used many times for many years. Normally migration code has to be developed, tested and then run only once to move data from source data base to target data base. If you don’t plan using old and new systems in parallel only a critical bug in migration process can force you to run it more than once in production. Can be pretty static and deal only with current situation vs. more dynamic and easy to evolve. By static I mean that in migration software one can for example hardcode classifier values, think only about current data structures and doesn’t pay much effort how this code would handle alternating future requirements. Performed by one user simultaneously vs. performed by many users simultaneously. Generally in migration you run one migration process at the same time and you don’t have to worry about other users. If you have underutilized resources you can run several parallel processes if possible, but you can definitely control how many they would be. Can use all computer’s resources vs. can use only a part of computer’s resources. Generally the migration is done on a separate box and you can consider all resources provided by it. It gives you sense of stability, there isn’t any chance that someone would intrude, spawn hundreds of processes and take away all your so valuable resources.
You can modify usual approach for developing application code according to above mentioned differences. Next chapter will list some tips how to make your migration run faster. Some of them will be a usual good programming practise you have to use for every application development, some the very opposite – you’d like to avoid in normal OLTP application.
Coding techniques.
Following coding and environment setup tips and techniques arrived in our project. I’ll try to explain them in order how they appeared. If you avoid the same mistakes we have met the goal of this article will be achieved.
1. We found I/O our main bottleneck. More than half of I/O operations overall was done on migration data, and here I mean only data, not indexes. Undo, migration indexes, source data, target data each took about 10% of overall I/O and temp.
5%. So the conclusion for us was to reduce I/O contention as much as we could on migration data. If you experience the same problems and haven’t access and/or resources for high level I/O load balancing schemes you can use at least poor man’s striping for migration data. We didn’t care much about source and target data load balancing because source tables where accessed only once when all data moved to migration tables and target tables also where mostly accessed once when inserting migrated data. Only small amount of additional lookup was necessary to target data in migration process.
2. Adjust enough space for temp and undo. Think in gigabytes here, not megabytes.
3. Use some kind of logger to log start and finish of each transformation and validation. You can use autonomous transaction for this purpose. Measure time each transformation and validation requires and focus on tuning only those that run significant time. If overall migration process takes 3 hours you don’t care about transformation that runs 10 seconds even if you can reduce necessary running time 10 times. But you do care if you can reduce a transformation that takes 2 hours by a small 10%.
4. Most probably you don’t care about media failure during migration (it would be easier restart the process from beginning) so you can use INSERT with APPEND hint and CREATE INDEX with NOLOGGING option. This helps reducing a big amount of redo generation. These two options are especially useful when moving data from source tables to migration tables and later when doing inserts in target tables. But remember that inserting with VALUES keyword always generates redo as well as redo is generated if you have any indexes on the table or database is in FORCE LOGGING mode.
5. In initial load from source tables to migration tables try to filter out data that obviously aren’t possible to migrate to reduce the migration data size that will be changed over and over again. Each full scan on table (although generally these aren’t bad see paragraph 14) will go through all table blocks even those you’ll never need.
6. Use referential integrity for migration data only where you really need it. This is contrary to normal applications where you have to define referential integrity as much as possible in database. Por quê? Because your code would be the only one modifying migration data. Because migration data would be interesting only in migration process and shortly after it, normally you don’t need to enforce integrity constraints because in future someone could easily corrupt integrity. In migration process you don’t care about distant future, you do care about current moment and speed. Of course if you are doubtful and think that your code cannot guarantee uniqueness of some column(-s) and parent/child relationship between some of your tables then you should enforce primary keys and foreign keys respectively. Enforcing them in the database is the fastest way if you think they could be broken.
7. Consider seriously PCTFREE parameter for migration tables. If these are subjects of heavily updates then default value of 10 is too less. With default value you’ll end up with so many chained rows that they will very much slow down updates and selects on your tables. After testing the „real migration” (see paragraph 16) ANALYZE your tables and look for CHAIN_CNT in dba/all/user_tables view. If it is larger than some percents of total rows in table you should increase PCTFREE. Of course it all depends and I cannot give you exact value, but I become suspicious for values larger than 5%.
8. Standardize your migration tables e. g. if you use some kind of logging info then use it in a consistent way. If you have a flag that indicates whether row has to be moved to target tables then name it in the same manner and use the same data type everywhere. We used following standard columns for all our migration tables:
Last transformation or validation that processed this row; Timestamp when it was last processed; Does it must be migrated? Timestamp when it has been migrated to target system.
9. Use SQL and set operations as much as you can. Use row by row operations only if these are really necessary. Remember that you have such constructions like DECODE and its younger brother CASE, NVL, various string functions, WITH keyword for SELECTS, INSERT into multiple tables that somehow helps you calculate and manipulate with values based on current row. And become familiar with ANALYTIC functions that give you ability to look on other rows and their products in a result set. Remember that you can create as many migration tables as you really need. Consider row by row operations and cursors only as a last option.
10. If you really cannot avoid loops and row by row operations (see paragraph above) then use some kind of tool that provides you with information how much work is done already. This tool for example can be DBMS_APPLICATION_INFO. SET_SESSION_LONGOPS. For more information read Oracle9i Supplied PL/SQL Packages and Types Reference or PL/SQL Packages and Types Reference 10g Release 1.
11. Calculate constants only once. Do not recalculate some lookup parameters (for example current user or user’s organization) for every row. Even if you have some classifier that has several values it is better to initialize some variables or constants in the beginning of package or procedure than to query from a lookup classifier table for each row. Your code wouldn’t be dynamic and probably not so elegant, but it would be much faster and that is main goal at least for migration code.
12. Consider using sysdate everywhere. Do you really care whether row was transformed in 10:31:46 when it really was transformed or all rows were transformed in 10:31:00 when transformation started? It is especially important if you use a construction SELECT sysdate INTO variable FROM dual. Why not simply initialize a variable in beginning of each transformation rather than doing this for each row? If you are concerned whether it costs anything just run dbms_profiler and look at results.
13. In your requirements gathering process you should identify some common transformations and/or validations for migration data. How to realize them? There are two possibilities: as a common procedure/function or everybody uses his own solution. Common solution would give consistent results every time but probably wouldn’t be the fastest one, in opposition to everyone’s own solution. So you have to understand what benefits and disadvantages would give each solution (for example how big the risk is that somebody would code transformation in a way that isn’t compatible with others) and make a decision.
14. Be suspicious about user-defined functions that are called for each row and do some queries on their own. Better incorporate them into upper statement.
15. Full scans aren’t bad. Especially in migration process. Migration involves many transformations and validations that affect all or most of the data in a table. If you have to process all data in a table then do it! Do it with full scan! Try hash joins. Nested loops and access path via indexes can give you wonderful results in an OLTP application where you have to select or update several records, but it can be very slow process if you have to select or update all records. And one more benefit from full scans and hash joins - you can monitor them in v$session_longops and some tools like Enterprise Manager even can visualise them. I prefer to know how much work has been done and how much remained.
16. Before loading data into target schema turn off all auditing and drop all indexes if possible. Consider creating audit data later especially if this is some kind of home grown auditing via triggers. Loading audit data in one single move will be much faster than firing a trigger on each row. The other thing is indexes and constraints on target tables. Creating indexes later would avoid possible fragmentation issues as well as with NOLOGGING will save your time. Enabling constraints NOVALIDATE also will save your time.
17. Measure overall migration performance! We have tried to measure and compare many overall statistics and events from v$session_event and v$mystat and found that only reliable measurement is how many rows package migrated in the given time . Our migration rate was from 20 000 till 100 000 rows in a minute for various data groups. Unfortunately it was obvious that data groups with lowest rate wasn’t the most complicated ones with most quantity or most sophisticated transformations. The biggest reason was the programming style of each developer. Developers having the least ratio didn’t follow at least one or several suggestions given here.
Some more advices for migration performance measurement:
Do that on the same hardware with the same environment; You can measure either target or source rows depending on your specificity. We measured target row count; Analyze the best and worst cases (assuming the complexity is comparable) and try to use practices from best case and avoid those used in worst case.
18. Test migration process at least once on all your real data. This would give you following benefits:
Provide with a real case how long it takes to migrate all the data; Ensure that you have dealt with all possible data combinations at least in that given moment; Give you real information about physical parameters such as overall disk space both for migration data and target data, necessary temp and undo space, PCTFREE parameter (more in paragraph 7); Provide possibility to test target data whether anything isn’t forgotten; Give you at least a little guarantee that main migration would run without emergency cases.
19. In actual migration be prepared for emergency. You should monitor migration process even if you have tested it several times, especially if data has been changed since then. New unexpected classifier values, changed execution plans – at least these are things that could affect you without notice.
20. And the last but not least: if you have any doubts about statements written here as well as anything else you’ve heard is a correct approach, try it yourself! Test possible scenarios, measure results and draw a conclusion.
Data migration method described in this article is suitable for complicated transformations and validations in migration process. It can be used for small and middle sized data migration projects because it requires much additional storage along with source data and target data storage. And there are also involved two steps of big data movement from source to migration and from migration to target environments. For big databases without complicated transformations you probably may choose some kind of direct data moving from source to target environment.
Migration software design and coding issues highlighted above should give you some insight what problems you’ll have, some tips how to avoid them and provide with overview of the successful experience.

Data conversion migration strategy

The terms data conversion and data migration are still sometimes used interchangeably on the internet. However, they do mean different things. Data conversion is the transformation of data from one format to another. It implies extracting data from the source, transforming it and loading the data to the target system based on a set of requirements.
Data migration is the process of transferring data between silos, formats, or systems. Therefore, data conversion is only the first step in this complicated process. Except for data conversion, data migration includes data profiling, data cleansing, data validation, and the ongoing data quality assurance process in the target system.
Both terms are used as synonymous by many internet resources. I think the reason for that might be that there are very few situations when a company has to convert the data without migrating it.
Data conversion possible issues.
There are some data conversion issues to consider, when data is transferred between different systems. Operating systems have certain alignment requirements which will cause program exceptions if these requirements are not taken into consideration. Converting files to another format can be tricky as how you convert it depends on how the file was created. These are only few examples of possible conversion issues.
There are some ways to avoid data conversion problems:
1. Always transform objects into printable character data types, including numeric data.
2. Devise an operating system-neutral format for an object transformed into a binary data type.
3. Include sufficient header information in the transformed data type so that the remainder of the encoded object can be correctly interpreted independent of the operating system.
Data conversion is often the most important part of data migration. You have to be very careful during this stage to assure data quality in your target system.