Migração de dados e o esforço que exige.

Os números refletem os padrões que vi em programas de SAP, Oracle e Dynamics nos últimos 25 anos. Eles servem para ancorar uma conversa de planejamento, não para substituir um exercício de profiling nos seus dados reais.

O fator que mais pesa na precisão é ter rodado consultas de profiling na origem. Uma faixa de custo construída com um indicador de qualidade honesto se sustenta. Uma faixa construída com o otimismo dos workshops, não. Use o resultado do estimador como número de referência na conversa com o seu integrador. Se a estimativa dele for bem menor, pergunte qual premissa de qualidade de dados ele está adotando e como a validou.

Para a maioria dos programas, a resposta certa é partidas em aberto mais saldos iniciais, com o histórico consultável no sistema legado por meio de um arquivo somente leitura ou de uma camada de relatórios. Migrar todo o histórico transacional multiplica o esforço, atrasa a reconciliação e raramente compensa o custo.

A exceção são os setores regulados, em que a retenção legal exige que o histórico fique no sistema de registro, ou os negócios em que comparações anuais contínuas no novo sistema são uma necessidade operacional de fato. Nos dois casos, o multiplicador de esforço do estimador para dados históricos reflete o trabalho mais pesado.

Ela escolhe o ponto de partida com base no ERP de destino, no conjunto de objetos e nos volumes. S/4HANA greenfield com objetos padrão normalmente cai em Migration Cockpit. Conversões brownfield e migrações seletivas tendem à abordagem híbrida. Volumes altos, vários sistemas de origem ou muita transformação levam a recomendação para ETL customizado na BTP ou para uma plataforma equivalente do lado da Oracle ou da Microsoft.

A recomendação é um ponto de partida. A decisão de verdade acontece depois de uma prova de conceito com uma amostra dos seus dados, não a partir de uma calculadora. Trate o resultado como a hipótese de trabalho que você leva para esse exercício.

A calculadora roda inteira no navegador. Você pode tirar um print do resultado ou copiar os números por objeto para a sua própria planilha de planejamento. Não há conta, não há exportação para PDF e nada é armazenado no servidor. É proposital. Se quiser uma análise mais detalhada dos números, agende uma conversa de 30 minutos e traga o print.

Não. O estimador dimensiona apenas dados mestre e dados transacionais. Dados de configuração, papéis de segurança, desenvolvimentos customizados e objetos de integração ficam em outras frentes de trabalho, com seus próprios fatores de esforço, e não devem ser misturados na linha de dados. Juntar tudo em um único número é um dos motivos pelos quais as estimativas de migração de dados estouram já na fase de planejamento.

O estimador dimensiona um único evento de migração. Em uma implantação multirregional, rode-o uma vez por onda e some as ondas, aplicando um fator de redução para os modelos, mapeamentos e ferramentas que você reaproveita a partir da primeira onda. Na minha experiência, a segunda onda custa cerca de 60 a 70% da primeira, a terceira cai para uns 50% e estabiliza daí em diante. Os objetos de dados de natureza legal local (impostos, folha de pagamento, bancos) costumam ser a parte que não se reaproveita bem.

Sim, e ela ajusta o esforço menor dos objetos que são convertidos no próprio sistema em comparação com os que precisam de novo mapeamento. Uma conversão brownfield costuma ficar entre 40 e 60% do esforço de dados de uma migração greenfield equivalente, porque as estruturas de clientes, fornecedores, materiais e plano de contas passam adiante sem nova extração. O trabalho mais pesado costuma ser a conversão para parceiro de negócios e o impacto do novo razão sobre os lançamentos históricos.

Sim. Sem cadastro, sem exigir e-mail, sem pagamento. O cálculo roda no seu navegador e nada é armazenado nem enviado para lugar nenhum. Se quiser ajuda para montar o business case da migração de dados depois de ter um número, agende uma conversa de 30 minutos.