Modelo de dados
Entidades, relacionamentos, chaves e restrições desenhados para o seu negócio — e documentados, não apenas implementados.
Método YveTech de Sistemas · Etapa 02
Modelagem e migração
Aqui o mapa vira estrutura. Modelamos a base que passa a ser a fonte da verdade e trazemos o histórico do sistema antigo com conferência de totais — o sistema velho só é desligado depois que os números fecham.
Migração não é copiar tabela: é decidir o que é verdade
O trabalho difícil não é mover o dado. É escolher qual dos três cadastros do mesmo cliente sobrevive.
Todo sistema antigo carrega o mesmo conjunto de heranças: o cliente cadastrado três vezes com grafias diferentes, o produto que mudou de código no meio do caminho, a condição de pagamento que só existe para um cliente específico, o campo de observação onde alguém guardou informação que deveria ter campo próprio. Copiar isso para um sistema novo é trocar de tela e manter o problema.
A modelagem vem antes: definimos as entidades que sustentam o negócio — cliente, produto, pedido, título, movimento de estoque —, os relacionamentos entre elas e as regras que o banco precisa garantir sozinho. Restrição de integridade não é preciosismo técnico; é o que impede um pedido de existir sem cliente e um saldo de estoque de ficar negativo por um caminho torto.
Só então a migração acontece, e ela é iterativa: uma carga de ensaio, um relatório de divergências, correção na origem ou na regra de conversão, nova carga. Repetimos até os totais baterem — saldo por conta, quantidade de registros por período, faturamento por mês, saldo de estoque por item. Fechamento de números é o critério de aceite, não a sensação de que está tudo certo.
O sistema antigo permanece disponível para consulta por um período combinado. Desligá-lo antes de os números fecharem é como queimar o arquivo morto no dia da mudança.
O que a etapa entrega
Da estrutura da base ao relatório que autoriza desligar o sistema antigo.
Regras de conversão
Como cada campo antigo vira campo novo, inclusive o que se perde por não ter equivalente. Escrito e aprovado antes da carga.
Deduplicação de cadastro
Cliente, fornecedor e produto repetidos identificados por critério objetivo, com a decisão de fusão registrada.
Conferência de totais
Faturamento por mês, saldo por conta, quantidade por período e saldo por item comparados entre o sistema antigo e o novo.
Trilha e integridade
O que o banco garante sozinho: nada de pedido órfão, saldo impossível ou data fora de faixa entrando por atalho.
Dados pessoais
O que é dado pessoal ganha tratamento próprio: acesso restrito, política de retenção e anonimização onde ele não precisa ser identificável.
Como a migração é conferida
Os artefatos que mostram, em número, que o histórico chegou inteiro.
Como a etapa acontece
De três a oito semanas, conforme o volume e o estado das bases de origem.
Modelagem
Desenhamos a base a partir do mapeamento e validamos com você em linguagem de negócio, não em diagrama técnico.
Extração e limpeza
Trazemos os dados do sistema atual, tratamos duplicidade, padronizamos formato e registramos toda decisão de conversão.
Cargas de ensaio
Rodadas sucessivas em ambiente separado, cada uma com relatório de divergência. Nenhuma carga acontece direto em produção.
Conferência e aceite
Você confere os totais que conhece de cor. Só com eles fechando é que a base nova assume a operação.
O que mais costuma aparecer no caminho
Nenhum destes é sinal de empresa desorganizada — todos aparecem em quase toda migração.
- Cadastro em triplicata — o mesmo cliente com três grafias e três históricos separados.
- Campo usado para outra coisa — observação guardando dado que precisaria de campo próprio.
- Códigos que mudaram — o produto trocou de código e o histórico ficou partido em dois.
- Saldo que não bate na origem — a diferença já existia antes, e a migração apenas a torna visível.
O que garantimos na virada
Os compromissos que tornam a migração reversível e conferível.
- Nada é apagado na origem — a base antiga permanece intacta e disponível para consulta.
- Toda conversão é registrada — dá para explicar de onde veio cada valor no sistema novo.
- Aceite por número — a virada depende de totais fechando, não de impressão.
- Caminho de volta — enquanto a base nova não é aceita, a operação segue no sistema atual.
O que é conferido antes do aceite
A lista é acordada com você no começo da etapa — e é ela que autoriza desligar o sistema antigo.
| Conferência | Como comparamos | Critério de aceite |
|---|---|---|
| Faturamento | total por mês, dos últimos 24 meses | diferença zero em todos os períodos |
| Contas a receber | saldo em aberto por cliente e por vencimento | saldo idêntico, título a título |
| Estoque | saldo por item na data de corte | diferença zero, com as divergências prévias documentadas |
| Cadastros | quantidade de ativos depois da deduplicação | toda fusão com origem e critério registrados |
| Histórico de pedidos | quantidade e valor por período | diferença zero, incluindo os cancelados |
| Anexos e documentos | quantidade de arquivos por registro | nenhum documento sem o registro correspondente |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
3–8 sem.duração típica conforme o volume
0diferença aceita nos totais conferidos
Origem intactanada é apagado no sistema antigo
24 mesesde histórico conferido período a período
Perguntas frequentes sobre modelagem e migração
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Eu perco o meu histórico na migração?
Não. O histórico migra junto e é conferido registro a registro, com relatório comparando totais por período, saldos e quantidade entre o sistema antigo e o novo. Além disso, a base de origem não é alterada em momento algum: ela permanece disponível para consulta pelo período que você quiser manter.
E se os números não fecharem?
É o resultado esperado nas primeiras cargas — por isso elas são de ensaio. Cada rodada gera um relatório de divergência que aponta se o problema está na regra de conversão ou no dado de origem. Corrigimos e rodamos de novo. O que não fazemos é aceitar diferença "pequena": diferença sem explicação é diferença não entendida.
Preciso mudar os meus códigos de produto e de cliente?
Só se você quiser. Manter os códigos atuais preserva a memória da equipe e do cliente, e é o caminho que recomendamos na maioria dos casos. Quando a codificação atual é a própria fonte do problema — código reaproveitado, faixa esgotada, dois significados no mesmo campo —, propomos a mudança com o mapa de-para registrado, para o histórico continuar rastreável.
Dá para migrar por partes?
Dá, e costuma ser o caminho mais seguro: cadastros primeiro, depois movimentação, por último os anexos. Cada bloco tem a sua conferência. Migração em uma única virada de fim de semana existe, mas só faz sentido quando o volume é pequeno e as bases estão em bom estado.
Quer saber em que estado estão as suas bases?
Fazemos uma leitura inicial e mostramos o que a migração vai encontrar. Conte o seu cenário e retornamos em até 1 dia útil.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Sistemas de InformaçãoVoltar à visão geral da área
Mapeamento dos processosComo a informação circula hoje — inclusive pelas planilhas paralelas
Implantação e integraçãoERP, CRM, fiscal e e-commerce conversando por integrações monitoradas
Treinamento e indicadoresEquipe treinada, painéis publicados e rotina de acompanhamento
Integrações em operaçãoO caminho de um pedido entre os sistemas, do clique ao recebimento
Hub de integraçõesPor que um ponto central vale mais que ligações diretas entre sistemas
Ambiente de Sistemas de InformaçãoA base única, as camadas em volta dela e o que protege cada uma