No quarto trimestre de 2025 migramos a Ameris Wealth Management de um sistema de gestão de portfólios legado para o BRITech. 1.500 portfólios, seis feeds de custodiantes, quatro provedores de dados de mercado, dois anos de transações históricas. O cutover ao vivo rodou num sábado. Na segunda de manhã a produção já estava rodando, sem nenhuma quebra manual para resolver.
Este é o runbook. É também uma lista de três coisas que faríamos diferente na próxima.
O ponto de partida
A Ameris é uma asset e wealth manager de Santiago, com $1.6B em AUM entre mandatos institucionais e de alta renda. O PMS legado deles tinha servido bem por quase uma década, mas havia virado um freio em três prioridades operacionais:
- NAV em tempo real em portfólios multimoeda (o sistema legado calculava no fechamento do dia, com fluxos manuais de override)
- Geração nativa dos indicadores da NCG 507 (o legado exigia exportar para uma ferramenta de compliance separada)
- Um modelo de conectores que não quebrasse toda vez que um custodiante mudasse o formato do arquivo
A decisão de migrar foi tomada em meados de 2025. O alvo era o BRITech, com o nosso time de Backbone operando a camada operacional. Cutover marcado para o quarto trimestre de 2025. O inegociável era: zero perda de dado, conciliação histórica completa, sem interrupção de serviço.
A abordagem em quatro fases
Vimos refinando um playbook de migração há quatro anos. O formato atual são quatro fases, três meses de ponta a ponta:
Fase 1 — Descoberta (3 semanas)
Mapear todo fluxo de dados. Todos. Sem exceção. Catalogamos 47 feeds de entrada, 23 relatórios de saída e 11 fluxos manuais que tinham crescido em volta do sistema antigo. O entregável desta fase é um único diagrama que cabe impresso em uma página — mas o trabalho por trás dele é exaustivo.
A percepção-chave: a maioria dos “fluxos manuais” acaba sendo a parte mais importante do sistema. São o que os operadores construíram para compensar o que a plataforma não faz. Ou você os replica no sistema novo, ou replica os modos de falha que eles estavam compensando.
Fase 2 — Reprocessamento (4 semanas)
Construímos uma ferramenta de migração que reprocessou dois anos de transações históricas pela plataforma nova — uma transação por vez, na ordem original, com os horários originais. A saída: uma instância do BRITech totalmente populada, com posições e histórico batendo no centavo com o sistema legado.
É nesta fase que a maioria das migrações dá certo ou dá errado. Já vimos fornecedores entregarem “migrações” que se resumem a um import de CSV no fim de semana do cutover. São essas as migrações que viram projetos de conciliação de um ano.
Por que o reprocessamento importa: daqui a um ano, quando o regulador perguntar “de onde veio esta posição?”, a resposta tem de ser uma transação, não um import de CSV.
Fase 3 — Operação em paralelo (3 semanas)
Por três semanas, os dois sistemas rodaram em paralelo. Mesmos feeds de entrada, mesmo processamento, dois livros. Toda diferença foi investigada; nada foi varrido para debaixo do tapete. Encontramos 14 categorias de quebra durante a operação em paralelo. Oito eram bugs genuínos da migração. Seis eram problemas latentes do sistema legado que vinham se disfarçando de “ruído tolerável” havia anos.
Fase 4 — Cutover (1 fim de semana)
O cutover rodou da noite de sábado à tarde de domingo. Reprocessamento final das transações da última semana. Conciliação completa do livro contra seis custodiantes e quatro fontes de preço. Aprovação do compliance. Tráfego ao vivo redirecionado na segunda, às 7h.
Três coisas que faríamos diferente
1. Começar a biblioteca de conectores antes
Construímos seis conectores de custodiante durante a migração. Três deles — BCI, BCP, Santander — já tínhamos construído antes, em formatos ligeiramente diferentes. Em vez de padronizar a biblioteca antes da migração, padronizamos durante. Isso custou umas três semanas. Da próxima vez, o trabalho de biblioteca vem primeiro; a migração usa o que já está pronto.
2. Rodar o paralelo por mais tempo em derivativos
As categorias de quebra que encontramos no paralelo foram quase todas em posições de derivativos. Renda variável e renda fixa ficaram limpas em poucos dias. Derivativos levaram as três semanas inteiras para conciliar redondo, sobretudo por causa de eventos corporativos que não tínhamos modelado por completo. Da próxima vez, derivativos ganham quatro semanas de paralelo; o resto ganha duas.
3. Avisar o front office mais cedo
O front office soube que a migração estava próxima cerca de seis semanas antes do cutover. Foi tempo suficiente para retreinar as pessoas na interface nova, mas não para trazer à tona os problemas de fluxo de trabalho. Dois daqueles fluxos manuais da Fase 1 acabaram exigindo esforço real de engenharia para replicar — e descobrimos isso no fim de semana do cutover, não antes. Da próxima vez, o briefing do front office começa na semana um.
Os números
Para quem tem curiosidade, as métricas finais do cutover:
- 1.500 portfólios migrados de ponta a ponta
- 6 / 6 conectores de custodiante no ar na segunda de manhã
- 0 quebras manuais no cutover
- $1.6B em AUM sob governança permanente desde o primeiro dia
- T+0 de atraso de conciliação contra seis custodiantes desde a primeira semana
O memorando da migração para o conselho tinha quatro páginas. Publicaremos a versão editada em separado.
Patricia Donoso lidera as implantações da finnerve. Se você está considerando uma migração de PMS e quer conversar sobre a abordagem, comece uma conversa ou leia a visão geral do serviço de Backbone.