CarneiroTech/cnpj-fast-process.md at ae8f308025928c67d5a17aebf01c3215d3459bcf

ricardo/CarneiroTech

Fork 0

Ricardo Carneiro c6ea9f7fe1 feat: mudança de foco. Novo site de manutenção.

2026-02-16 20:28:27 -03:00

13 KiB

Raw Blame History

title

slug

summary

client

industry

timeline

role

image

Overview

Com a introdução do CNPJ alfanumérico pela Receita Federal brasileira, empresas enfrentavam o desafio de adaptar suas aplicações legadas que armazenavam CNPJ como campos numéricos (bigint, numeric, int).

Criei o CNPJ Fast, uma metodologia estruturada para avaliar, planejar e executar migrações de CNPJ em aplicações e bancos de dados corporativos.

Resultado: Processo vendido para 2 clientes (seguradora e empresa de cobrança) antes mesmo da implementação.

Challenge

Mudança Regulatória Complexa

Contexto regulatório:

Receita Federal brasileira introduziu CNPJ alfanumérico
CNPJ deixa de ser apenas números (14 dígitos)
Passa a aceitar letras e números (formato alfanumérico)

Impacto nas empresas:

-- ANTES: CNPJ numérico
CNPJ BIGINT           -- 12345678000190

-- DEPOIS: CNPJ alfanumérico
CNPJ VARCHAR(18)      -- 12.ABC.678/0001-90

Problemas identificados:

🗄️ Banco de dados: Colunas BIGINT, NUMERIC, INT não suportam caracteres
🔑 Chaves primárias: CNPJ usado como PK em várias tabelas
🔗 Foreign keys: Relacionamentos entre tabelas
📊 Volume: Milhões de registros para migrar
💻 Aplicações: Validações, máscaras, regras de negócio
🧪 Testes: Garantir integridade após migração
⏱️ Downtime: Janelas de manutenção limitadas

Sem um processo estruturado, empresas arriscavam:

Perda de dados
Inconsistências no banco
Aplicações quebradas
Downtime prolongado

Solution: CNPJ Fast Process

Metodologia em 5 Fases

Desenhei um processo estruturado que poderia ser replicado em diferentes clientes:

┌─────────────────────────────────────────────┐
│  FASE 1: DISCOVERY & ASSESSMENT             │
│  - Inventário de aplicações                 │
│  - Análise de schemas de banco              │
│  - Identificação de tabelas impactadas      │
│  - Estimativa de volume de dados            │
└─────────────────────────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│  FASE 2: IMPACT ANALYSIS                    │
│  - Mapeamento de dependências               │
│  - Análise de chaves primárias/estrangeiras │
│  - Identificação de regras de negócio       │
│  - Avaliação de risco                       │
└─────────────────────────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│  FASE 3: MIGRATION PLANNING                 │
│  - Estratégia de migração (phased commits)  │
│  - Scripts SQL automatizados                │
│  - Plano de rollback                        │
│  - Janelas de manutenção                    │
└─────────────────────────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│  FASE 4: EXECUTION                          │
│  - Migração de dados em lotes               │
│  - Atualização de aplicações                │
│  - Testes de integração                     │
│  - Validação de integridade                 │
└─────────────────────────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│  FASE 5: VALIDATION & GO-LIVE               │
│  - Testes de regressão                      │
│  - Validação de performance                 │
│  - Go-live coordenado                       │
│  - Monitoramento pós-migração               │
└─────────────────────────────────────────────┘

Fase 1: Discovery & Assessment

Objetivo: Entender o escopo completo da migração

Entregáveis:

Inventário de Aplicações
- Lista de aplicações que usam CNPJ
- Tecnologias (ASP 3.0, VB6, .NET, microserviços)
- Criticidade de cada aplicação

Análise de Schema

-- Script de descoberta automática
SELECT
    t.TABLE_SCHEMA,
    t.TABLE_NAME,
    c.COLUMN_NAME,
    c.DATA_TYPE,
    c.CHARACTER_MAXIMUM_LENGTH
FROM INFORMATION_SCHEMA.TABLES t
JOIN INFORMATION_SCHEMA.COLUMNS c
    ON t.TABLE_NAME = c.TABLE_NAME
WHERE c.COLUMN_NAME LIKE '%CNPJ%'
    AND c.DATA_TYPE IN ('bigint', 'numeric', 'int')
ORDER BY t.TABLE_SCHEMA, t.TABLE_NAME;

Estimativa de Volume
- Total de registros por tabela
- Tamanho em GB
- Tempo estimado de migração

Exemplo de output:

Tabela	Coluna	Tipo Atual	Registros	Criticidade
Clientes	CNPJ_Cliente	BIGINT	8.000.000	Alta
Fornecedores	CNPJ_Fornecedor	NUMERIC(14)	2.500.000	Média
Transações	CNPJ_Pagador	BIGINT	90.000.000	Crítica

Fase 2: Impact Analysis

Objetivo: Mapear todas as dependências e riscos

Análise de chaves:

-- Identifica PKs e FKs envolvendo CNPJ
SELECT
    fk.name AS FK_Name,
    tp.name AS Parent_Table,
    cp.name AS Parent_Column,
    tr.name AS Referenced_Table,
    cr.name AS Referenced_Column
FROM sys.foreign_keys fk
INNER JOIN sys.tables tp ON fk.parent_object_id = tp.object_id
INNER JOIN sys.foreign_key_columns fkc ON fk.object_id = fkc.constraint_object_id
INNER JOIN sys.columns cp ON fkc.parent_column_id = cp.column_id
    AND fkc.parent_object_id = cp.object_id
INNER JOIN sys.tables tr ON fk.referenced_object_id = tr.object_id
INNER JOIN sys.columns cr ON fkc.referenced_column_id = cr.column_id
    AND fkc.referenced_object_id = cr.object_id
WHERE cp.name LIKE '%CNPJ%' OR cr.name LIKE '%CNPJ%';

Avaliação de Risco:

🔴 Alto: Tabelas com CNPJ como PK e >10M registros
🟡 Médio: Tabelas com FK para CNPJ
🟢 Baixo: Tabelas sem constraints

Fase 3: Migration Planning

Estratégia de migração gradual:

Para evitar travamento de banco, desenhei estratégia de phased commits:

-- Estratégia para tabelas grandes (>1M registros)

-- 1. Adicionar nova coluna VARCHAR
ALTER TABLE Clientes
ADD CNPJ_Cliente_New VARCHAR(18) NULL;

-- 2. Migração em lotes (commits faseados)
DECLARE @BatchSize INT = 100000;
DECLARE @RowsAffected INT = 1;

WHILE @RowsAffected > 0
BEGIN
    UPDATE TOP (@BatchSize) Clientes
    SET CNPJ_Cliente_New = FORMAT(CNPJ_Cliente, '00000000000000')
    WHERE CNPJ_Cliente_New IS NULL;

    SET @RowsAffected = @@ROWCOUNT;
    WAITFOR DELAY '00:00:01'; -- Pausa entre lotes
END;

-- 3. Remover constraints (PKs, FKs)
ALTER TABLE Clientes DROP CONSTRAINT PK_Clientes;

-- 4. Renomear colunas
EXEC sp_rename 'Clientes.CNPJ_Cliente', 'CNPJ_Cliente_Old', 'COLUMN';
EXEC sp_rename 'Clientes.CNPJ_Cliente_New', 'CNPJ_Cliente', 'COLUMN';

-- 5. Recriar constraints
ALTER TABLE Clientes
ADD CONSTRAINT PK_Clientes PRIMARY KEY (CNPJ_Cliente);

-- 6. Remover coluna antiga (após validação)
ALTER TABLE Clientes DROP COLUMN CNPJ_Cliente_Old;

Por que essa abordagem?

✅ Evita lock de tabela inteira
✅ Permite pausar/retomar migração
✅ Minimiza impacto em produção
✅ Facilita rollback se necessário

Fase 4 & 5: Execution e Validation

Checklist de execução:

Backup completo do banco
Executar scripts de migração em lotes
Atualizar aplicações (validações, máscaras)
Testes de integração
Validação de integridade referencial
Testes de performance
Go-live coordenado
Monitoramento 24h pós-migração

Sales Enablement: Apresentação UX

Colaboração com Gestor de UX:

O gestor de UX da empresa criou uma apresentação visual impactante do processo CNPJ Fast:

Conteúdo da apresentação:

📊 Infográficos do processo de 5 fases
📈 Exemplos de estimativas de tempo/custo
🎯 Casos de uso (seguradoras, bancos, fintechs)
✅ Checklist executivo
📋 Templates de documentação

Resultado: Apresentação usada pelo time comercial para prospecção.

Results & Impact

Vendas Realizadas

Cliente 1: Seguradora

Stack: ASP 3.0, VB6 components, .NET, microserviços
Escopo: Migração completa de aplicações legadas
Status: Projeto vendido (execução por outra equipe)
Valor: [Confidencial]

Cliente 2: Empresa de Cobrança

Escopo: Migração de banco de dados (~100M registros)
Status: Projeto vendido e em execução (por mim)
Particularidade: Processo foi reestruturado para atender necessidades específicas
Ver case completo: Migração CNPJ - 100M Registros

Impacto no Negócio

💰 2 projetos vendidos antes mesmo da primeira execução 📈 Processo replicável para novos clientes 🎯 Posicionamento como especialista em migrações regulatórias 📚 Base de conhecimento para futuros projetos similares

Impacto Técnico

🔧 Metodologia testada em cenários reais 📖 Documentação reutilizável (scripts, checklists, templates) 🚀 Aceleração de projetos similares (de semanas para dias)

Tech Stack

SQL Server Migration Strategy Process Design Regulatory Compliance ASP 3.0 VB6 .NET Microservices Batch Processing Database Optimization

Key Decisions & Trade-offs

Por que processo estruturado?

Alternativas:

❌ Abordagem ad-hoc por projeto
❌ Consultoria manual sem metodologia
✅ Processo replicável e escalável

Justificativa:

Reduz tempo de Discovery
Padroniza entregas
Facilita vendas (apresentação pronta)
Permite execução por diferentes equipes

Por que separar em 5 fases?

Benefícios:

Cliente pode aprovar fase a fase
Permite ajustes durante o processo
Facilita gestão de riscos
Entregas incrementais

Lessons Learned

1. UX/Apresentação Importa para Vendas

A apresentação visual feita pelo gestor de UX foi crucial para fechar os 2 contratos. Processo técnico bom + apresentação ruim = sem vendas.

2. Processo Vende, Não Apenas Execução

Criar uma metodologia documentada tem mais valor comercial do que apenas oferecer "horas de consultoria".

3. Cada Cliente é Único

O cliente pediu reestruturação do processo. Um bom processo deve ser:

Estruturado o suficiente para ser replicável
Flexível o suficiente para customizar

4. Colaboração Multidisciplinar

Trabalhar com o gestor de UX (apresentações) + time comercial (vendas) + técnico (execução) = sucesso.

Next Steps

Oportunidades futuras:

🌎 Expansão: Oferecer CNPJ Fast para mais setores (bancos, fintechs, varejo)
📦 Produto: Transformar em ferramenta automatizada (SaaS)
📚 Treinamento: Capacitar equipes internas de clientes
🔄 Evolução: Adaptar processo para outras migrações regulatórias (PIX, Open Banking)

Resultado: Metodologia estruturada que virou produto vendável, gerando receita antes mesmo da primeira execução técnica.

Quer implementar CNPJ Fast na sua empresa? Entre em contato

13 KiB Raw Blame History