Quanto tempo leva, de verdade, trocar o provedor de plataforma de uma operação bet.br autorizada — e a partir de que ponto o caminho crítico do projeto deixa de ser a engenharia e passa a ser a fila do regulador? Este texto responde a quem assina o cronograma: diretor de tecnologia, diretor de operações e o compliance officer que vai peticionar.
Resumo executivo
- Mudança de provedor de plataforma de sistemas de apostas está na lista de alterações que só produzem efeito após aprovação da SPA/MF, conforme a Instrução Normativa SPA/MF nº 35, publicada no DOU em 16 de dezembro de 2025.
- O prazo de análise é de até 150 dias contados da formalização do peticionamento, suspenso quando a Secretaria notifica o operador a apresentar documentação complementar.
- O peticionamento ocorre por SEI, com previsão de migração futura para módulo do SIGAP quando disponibilizado — planeje retrabalho de dossiê.
- Sistema novo é evento de certificação: a Portaria SPA/MF nº 722/2024 exige relatório de avaliação por entidade certificadora reconhecida pela SPA, com revalidação anual.
- O maior custo do projeto costuma estar fora da licença: reconstrução de conectores, reconciliação, dupla mensalidade no paralelo e nova certificação.
Trocar de PSP é comunicação. Trocar de PAM é processo
A Instrução Normativa SPA/MF nº 35, assinada pelo secretário Regis Dudena e publicada em 16 de dezembro de 2025, separou as alterações societárias e operacionais de um agente autorizado em duas categorias: as que só produzem efeitos após aprovação da Secretaria e as que têm efeito imediato, bastando comunicação.
Na primeira categoria estão mudanças de marcas comerciais, de domínios bet.br e de provedores de plataforma de sistemas de apostas. Na segunda, alterações de instituições financeiras parceiras, troca de administradores, denominação social e endereço da sede.
A consequência prática é direta: substituir um PSP é um ato de comunicação; substituir o PAM é um processo com análise, exigências possíveis e data de eficácia que não depende do operador. Quem assinou contrato com o novo fornecedor achando que o go-live é uma decisão comercial descobre tarde que a decisão é do regulador.
Os dois cronogramas que não se somam — eles se atropelam
Todo projeto de migração roda em duas trilhas paralelas. A trilha técnica — mapeamento de dados, wallet, reconstrução de integrações, dry-run, freeze e cutover. E a trilha documental — peticionamento, certificação do novo sistema, resposta a exigências, aprovação.
O erro recorrente é sequenciar: primeiro construir o ambiente, depois peticionar. O resultado é uma operação com contrato novo já correndo, mensalidade dupla e plataforma antiga em produção porque a aprovação não saiu. O peticionamento precisa começar quando o desenho técnico estiver fechado o suficiente para ser descrito em dossiê — não quando o ambiente estiver pronto.
Vale registrar o que ainda não está esclarecido em fonte pública: não há definição aberta sobre a aceitação de dois sistemas certificados em operação simultânea durante o paralelo, nem sobre como o prazo de revalidação anual se comporta após a troca. São perguntas a levar formalmente à Secretaria ou à certificadora antes de fixar a data de corte.
O que a norma fixa em dias — e o que ela não fixa
| Etapa | Prazo | Base normativa | Observação para o cronograma |
|---|---|---|---|
| Análise de alteração sujeita a aprovação prévia | Até 150 dias da formalização do peticionamento | IN SPA/MF nº 35, de 16/12/2025 | Suspenso enquanto houver exigência documental pendente |
| Relatório de avaliação para certificação dos requisitos técnicos | Até 90 dias após a publicação do ato de autorização | Art. 8º da Portaria SPA/MF nº 722/2024 | Entidade certificadora precisa ter capacidade reconhecida pela SPA |
| Revalidação dos relatórios de sistemas e plataformas | Anual | Portaria SPA/MF nº 722/2024, art. 8º | A data não se reinicia com a migração; pode haver dois ciclos no mesmo exercício |
| Apresentação do certificado técnico do sistema de apostas | Até 30 dias da notificação da SPA/MF | Art. 14, inciso V, da Portaria SPA/MF nº 827/2024 | Observados os Anexos I, II e III da Portaria 722/2024 |
O que a norma não fixa é justamente o que mais atrasa: fila de laboratório, tempo de resposta do fornecedor que está saindo e qualidade do próprio dossiê. Um pedido mal instruído gera exigência, a exigência suspende o prazo, e os 150 dias viram um número teórico.
Onde se peticiona e o que já se sabe sobre o canal
As comunicações previstas na IN 35 devem ocorrer por peticionamento eletrônico no Sistema Eletrônico de Informações (SEI). O texto prevê que o processo passará a tramitar pelo Sistema de Gestão de Apostas (SIGAP) quando o módulo específico estiver disponível — sem data pública apurada até o fechamento deste texto.
Para quem monta o dossiê hoje, a leitura é simples: estruture os documentos de forma modular, com anexos identificáveis por tema, para reaproveitar o material quando o fluxo mudar de sistema. A disciplina de arquivo aqui é a mesma que sustenta a capacidade de responder a ofício da SPA/MF sem improviso.
Migrar de PAM é evento de certificação, não só de TI
A Portaria SPA/MF nº 722, de 2 de maio de 2024, estabelece as regras gerais de funcionamento dos sistemas de apostas e do fornecimento de dados ao SIGAP. Seu escopo cobre requisitos técnicos da operação, exigências de certificação, estruturação do relatório de avaliação, supervisão e fiscalização, terminais de apostas e o conceito de jogos de fortuna online.
Sistema novo significa avaliação nova. Entre as entidades certificadoras com capacidade operacional reconhecida por portaria publicada estão a Gaming Laboratories International LLC (Portaria SPA/MF nº 504, de 22/03/2024), a eCogra Limited (Portaria nº 588, de 11/04/2024) e a BMM Spain Testlabs (Portaria nº 603, de 15/04/2024). A lógica é a mesma que rege o que entra, sai e quem recertifica no portfólio de slots: agenda de laboratório é recurso escasso e precisa ser reservada cedo.
O custo escondido não está no PAM: está na ponta de cada integração
O preço de tabela da plataforma costuma ser a menor linha do orçamento. O que consome o projeto é a reconstrução e revalidação de cada conector:
- Agregadores e provedores de jogo (RGS), com reconciliação de rodadas e de jackpots
- PSPs e trilhos PIX, incluindo reprocessamento de conciliação e callbacks
- KYC e antifraude, com preservação de evidências de verificação
- Autoexclusão, autolimites e demais controles de jogo responsável
- CRM e comunicação, com base de consentimento e histórico de contato
- BI e data warehouse, com redefinição de esquemas e de janelas de carga
- Afiliados e postbacks, com risco de dupla contagem ou perda de atribuição
- Envio de dados ao SIGAP, com validação de layout e de tempestividade
Some a isso o período de operação em paralelo — com dupla mensalidade — e as horas de engenharia de reconciliação. Não existe fonte aberta confiável sobre custo médio ou duração média de migração de PAM no Brasil; por isso, orce pelo inventário de conectores da sua própria operação, e não por benchmark de corredor de feira.
A independência da camada analítica muda o tamanho dessa conta. Quem já resolveu como não virar refém do PAM no data warehouse migra com histórico próprio e negocia melhor a saída.
Migrar saldo é fácil. O difícil é migrar estado
Saldo é número. Estado é condição jurídica e comportamental do jogador: bônus em rollover pendente, limite de depósito configurado, limite de tempo, autoexclusão em vigor, restrição de marketing, flag de monitoramento.
A Portaria SPA/MF nº 2.579 e a Instrução Normativa SPA/MF nº 31, publicadas em novembro de 2025, regulamentam a autoexclusão em duas modalidades: específica, válida para um operador, e centralizada, que bloqueia o acesso a todas as plataformas autorizadas. Reativar quem se autoexcluiu durante um cutover não é bug de produto — é falha de conformidade. Vale revisar as regras de cancelamento, prorrogação e retorno na autoexclusão antes de desenhar o mapeamento.
O mesmo vale para saldo promocional: um bônus com exigência de apostas em curso precisa chegar do outro lado com contador intacto, sob pena de gerar passivo ou de liberar saque indevido. A aritmética está detalhada em o custo real de cada bônus e o significado de rollover.
Sequência recomendada, contada de trás para frente
- Escreva a tese da troca: o que o PAM atual não entrega em dados, velocidade de release, custo por integração ou dependência. Sem documento, o projeto perde patrocínio na metade.
- Faça due diligence técnica do candidato: certificação vigente pelos Anexos da Portaria 722/2024, envio ao SIGAP em produção, wallet, suporte a autoexclusão centralizada e autolimites, exportação nativa de dados.
- Negocie o contrato de saída antes do contrato de entrada: formato aberto de exportação, janela de retenção, SLA durante o paralelo e propriedade do dado.
- Peticione no SEI o dossiê de alteração de provedor de plataforma. Trate os 150 dias como prazo de análise, não como prazo total do projeto.
- Reserve o laboratório de certificação assim que o escopo técnico estiver fechado.
- Rode o mapeamento e pelo menos dois dry-runs em ambiente espelho: contas, saldos, bônus em rollover, limites, autoexclusões e histórico fiscal.
- Execute o cutover com freeze curto, plano de rollback escrito, comunicação prévia ao apostador e evidência registrada de cada etapa.
- Mantenha 30 a 90 dias de reconciliação diária, validação do envio ao SIGAP e auditoria de trilha antes do desligamento controlado do legado.
Erros que aparecem em quase todo pós-morte de projeto
- Assinar com o novo provedor e só depois descobrir que a mudança depende de aprovação prévia.
- Tratar os 150 dias como prazo fixo, ignorando a suspensão por exigência documental.
- Orçar a licença do PAM e não orçar integrações, paralelo e nova certificação.
- Perder acesso ao histórico do legado e não conseguir sustentar resposta a ofício depois do desligamento.
- Marcar cutover em véspera de evento esportivo de grande audiência ou de fechamento fiscal.
O que medir para saber se a migração deu certo
- Dias entre peticionamento e decisão da SPA e número de exigências recebidas — proxy direto da qualidade do dossiê.
- Percentual de contas reconciliadas na primeira rodada e divergência financeira em centavos por conta.
- Janela real de indisponibilidade contra a planejada.
- Taxa de aprovação de depósito e tempo de saque nas quatro semanas seguintes ao cutover, contra a linha de base anterior.
- Rejeições e inconsistências no envio ao SIGAP nos primeiros 30 dias.
- Custo total por integração reconstruída, somando engenharia, certificação e paralelo.
- Chamados de suporte por mil contas ativas em D+7 e D+30.
Uma observação sobre comparação internacional: reguladores como os do Reino Unido, Malta e Espanha também tratam mudança de plataforma ou de sistema crítico como evento reportável, em geral com teste prévio. Mas o desenho brasileiro tem base própria — Lei 14.790/2023, IN 35/2025 e Portaria 722/2024 — e é por ele que sua operação será fiscalizada.
A conclusão prática para quem está com a decisão na mesa: a data de go-live de uma migração de PAM não se define na sala de arquitetura. Ela se define no dia em que o peticionamento é protocolado com dossiê completo o bastante para não gerar exigência. Tudo o mais é execução.
Monte o inventário antes do contrato
Liste hoje cada integração ativa da sua operação e o dono técnico de cada uma — é esse inventário, e não a proposta comercial do novo provedor, que define o custo e o prazo da migração. Para receber a análise do que muda para operadores, assine a newsletter do iGBRASIL.
