Migração para Planning Analytics v12: as vantagens reais e o que falta no business case

A conversa sobre migrar de Planning Analytics v11 para v12 costuma começar errada, com a palavra "upgrade".

Não é um upgrade. É uma nova geração de plataforma que mantém o motor de cálculo familiar por dentro e muda quase tudo ao redor dele. A diferença não aparece na demo — a demo é confortável, porque cubos, regras e TurboIntegrator continuam sendo cubos, regras e TurboIntegrator. Ela aparece em tudo que encosta no modelo.

Primeiro, um esclarecimento: v12 não é sinônimo de nuvem

Esse é o mal-entendido mais comum, e ele atrapalha a decisão desde o começo.

A v12 é a geração do Planning Analytics Engine, e ela existe em vários formatos de implantação: SaaS na IBM Cloud, Planning Analytics na AWS, na Azure, o Planning Analytics Cartridge sobre Cloud Pak for Data para cenário híbrido, e também on-premises — a IBM anunciou o Planning Analytics Local 3.1 como uma versão v12 não-containerizada para quem precisa continuar dentro de casa.

Isso importa porque muda a pergunta. Não é "migrar para a nuvem ou ficar onde está". É "quando trocar de geração de motor" e, separadamente, "onde hospedar". São duas decisões, e tratá-las como uma só é o que faz projeto travar em comitê de segurança por seis meses.

O que muda de fato na arquitetura

O TM1 deixa de ser um serviço rodando num servidor com um diretório de dados que você enxerga, e passa a ser um serviço gerenciado pela plataforma, com persistência própria e acessado por API. Quatro consequências práticas:

1. O sistema de arquivos deixa de ser uma interface. Na v11, boa parte das integrações do mundo real era "joga o CSV na pasta", "lê o arquivo que o ERP deixou no compartilhamento", "copia o data directory para backup", "um .bat com tm1runti no agendador do Windows". Nada disso sobrevive na mesma forma: os utilitários de linha de comando dão lugar a chamadas REST e endpoints HTTP.

2. Identidade e autenticação mudam de dono. Modelos de segurança montados em cima de CAM ou de segurança nativa precisam ser revisitados — não como ajuste de configuração, como frente de trabalho.

3. O ciclo de vida do modelo vira promoção versionada. O PAW passa a integrar com repositório Git, onde ficam cubos, dimensões, regras e processos. A promoção entre dev, QA e produção acontece por comando de versionamento, sem parar o database — em vez de copiar objeto na unha e torcer.

4. Os clientes clássicos acabam. Architect e Perspectives saem de cena, e o TM1 Web — que muita gente ainda usa para telas de entrada — também não acompanha. PAW e PAfE passam a ser a interface. Se você usa TM1 Applications para workflow de aprovação, inclua isso no inventário: a linha dos clientes legados encolheu bastante nas versões recentes.

Esse quarto item costuma ser tratado como detalhe técnico e é, na prática, o maior item de gestão de mudança do projeto.

As vantagens que se sustentam

Ambientes deixam de ser artesanais. Promoção versionada com paridade entre dev, QA e produção elimina uma classe inteira de incidente do tipo "funcionava no dev". Para quem sustenta modelo grande, isso sozinho já muda a rotina.

A janela de manutenção deixa de ser um projeto. Patch, upgrade e dimensionamento param de ser uma frente de infraestrutura com orçamento e calendário próprios — especialmente nos formatos gerenciados, onde a atualização passa pela própria administração do PAW.

Elasticidade por database. Ambientes podem ser iniciados, parados e dimensionados separadamente. O pico de fechamento para de dimensionar o ano inteiro.

API-first de verdade. Tudo que a interface faz está disponível via REST. TM1py, pipelines de dados, aplicações próprias e agentes passam a ter um caminho suportado. É a vantagem que mais abre portas no médio prazo e a que menos aparece no business case.

Acesso ao que está sendo desenvolvido. O desenvolvimento novo está concentrado na v12. Ficar na v11 não é "manter estável" — é congelar.

As boas práticas que o mercado já consolidou

Aqui está o que a experiência acumulada de migrações já mostrou que funciona. Vale seguir na ordem.

Faça a faxina antes, não depois. Purgue objetos órfãos, cubos que ninguém consulta, processos desativados e dados que não precisam viajar. Migrar dívida técnica é pagar duas vezes: no esforço de mover e no esforço de conviver.

Rode um SaveDataAll na v11 antes de exportar. Garante que os feeders sejam gravados no formato mais recente. Detalhe pequeno, com efeito grande na validação — e vale a ironia de que essa mesma função não existe na v12.

Use o utilitário oficial, no lugar certo. A IBM disponibiliza o TM1 to Planning Analytics Engine Database Migration Utility (Fix Central e área de administração do PAW), com versões para Windows e Linux. Ele deve rodar na máquina que hospeda o database v11 — é o que preserva informação de locale e evita perda de objetos. Rodar de fora é um erro que só aparece depois.

Inventarie todo processo TI, um por um. Referência de fonte de dados, caminho de arquivo, método de autenticação. Essa é reconhecidamente a parte mais trabalhosa da migração, e é onde as estimativas erram feio.

Mapeie as funções que não existem mais. ExecuteCommand e SaveDataAll são as mais citadas. O caminho para a primeira é ExecuteHTTPRequest: onde antes havia um script de sistema operacional, passa a haver uma chamada HTTP. Acesso direto ao SO é incompatível com arquitetura isolada por definição — então cada chamada externa precisa virar REST ou sair para um orquestrador de fora.

Cheque os cubos de controle. O comportamento muda, e há automações que dependem deles sem que ninguém lembre.

Valide contra a v11, número por número. Enquanto o ambiente antigo estiver de pé, ele é o seu gabarito. Depois que sai do ar, você perdeu a única referência confiável que tinha.

Os fatores que quase nunca entram na conta

Reescrita de integrações. Tudo que usava o sistema de arquivos. Costuma ser a maior linha do projeto, e a que mais surpreende, porque metade dessas integrações não está documentada em lugar nenhum — está no agendador de um servidor que alguém montou em 2016.

A saída dos clientes legados. Usuário-chave com planilha Perspectives de dez anos cheia de macro, ou com um conjunto de telas em TM1 Web, é uma frente própria do projeto. Estime a migração de relatórios e telas como workstream separada, com nome e responsável.

Fontes on-premise. Bancos dentro da rede precisam de um caminho seguro para fora — a menos que você fique on-premises, que é justamente por que a decisão de motor e a de hospedagem devem ser separadas.

Ferramentas de terceiros e scripts internos. Monitoramento, backup, deployment, aquele utilitário que uma pessoa escreveu e todo mundo usa.

A forma do custo muda. A comparação relevante não é licença contra licença. É custo total: licença + infraestrutura + as horas de time que hoje mantêm servidor, patch e backup. Em vários casos o número fecha; em outros não fecha, e é melhor saber disso no começo.

Região e residência de dados — quando a escolha for por um formato gerenciado. Em setor regulado no Brasil, isso é conversa de verdade, não formulário, e às vezes é o item que define o cronograma.

O erro mais comum: migrar e modernizar na mesma frente

A tentação é sempre a mesma: "já que estamos migrando, vamos aproveitar para arrumar o modelo".

É o caminho mais rápido para um projeto ruim. Dobra a superfície de risco e destrói a única vantagem metodológica que uma migração tem: poder comparar o resultado novo com o antigo, número por número. Se o modelo mudou junto, qualquer diferença tem duas causas possíveis, e você vai passar semanas descobrindo qual.

Vale distinguir isso da faxina recomendada acima, porque parecem contraditórios e não são. Apagar o que ninguém usa é higiene — não muda resultado nenhum e reduz o que precisa ser validado. Redesenhar o que está em uso é modernização — muda resultado, e por isso não pode acontecer enquanto você ainda está tentando provar que o ambiente novo devolve os mesmos números.

Migre iso-funcional, valide contra a v11 até bater, estabilize. Depois modernize, num ciclo separado, onde cada diferença tem uma causa só.

Quando adiar é uma escolha legítima

Se o ambiente atual está estável, o risco de suporte foi avaliado e mitigado conscientemente, e existe uma transformação maior nos próximos doze meses que vai mudar o modelo de qualquer jeito — migrar duas vezes é pior do que migrar depois.

A diferença entre adiar e empurrar com a barriga é uma só: adiar tem data e tem dono. Se não tem, não é decisão, é deriva.

A v12 ainda está evoluindo, e detalhes de recursos, formatos de implantação e disponibilidade mudam entre releases. Trate o que está acima como mapa do terreno e confirme os pontos críticos na documentação corrente da IBM antes de fechar escopo.

---

Conduzimos migrações de TM1 sem interromper o ciclo de planejamento — veja nossa atuação em IBM Planning Analytics ou fale com a gente para um diagnóstico do seu ambiente.