O que significa para a sua empresa o NetSuite aposentar o SuiteScript 1.0, 2.0 e 2.x

A Oracle publicou o calendário de aposentadoria das versões antigas do SuiteScript, a linguagem com a qual são programadas as personalizações do NetSuite. O marco final é a versão 2028.2.

Se a sua empresa usa NetSuite, aqui estão as decisões a tomar e quando tomá-las. Se não usa, o artigo ainda faz sentido, porque o problema de fundo não é do NetSuite. Acontece com qualquer empresa que construiu parte da sua operação sobre um software, e a maioria descobre quando algo falha e ninguém sabe explicar por quê.

Este não é um artigo técnico. Se o que você procura é o detalhe de como se migra um script, escrevemos isso separadamente em Atualização necessária, atualize os scripts para o SuiteScript 2.1. Aqui falamos da outra metade do problema, a que não se resolve programando.

O essencial, em quatro pontos

• Existe uma data concreta. Na versão 2028.2 do NetSuite, os scripts que usem SuiteScript 1.0, 2.0 ou 2.x param de ser executados.
• Nada quebra este ano. O calendário é gradual e a primeira mudança com efeito real chega em 2027.
• O problema não é técnico. Levar o código para a versão nova é o trabalho mecânico. O difícil é saber quais personalizações existem, quais processos elas sustentam e quem as entende.
• Dois anos são mais do que suficientes. Seis meses, não. É nisso que está toda a diferença entre planejar e apagar incêndio.

O calendário, versão por versão

Cada marco está atrelado a uma versão do NetSuite, e as versões chegam a cada conta em momentos diferentes. Por isso não existe um dia do calendário que valha igual para todas as empresas.

É o plano que a Oracle publica hoje e pode ser ajustado no futuro, mas a direção está clara e não há motivo para contar com uma prorrogação.

Por que isso se parece pouco com um problema de software

A reação habitual diante de um anúncio assim é encaminhá-lo para a área de sistemas ou para o fornecedor, e é razoável. Mas, na prática, o gargalo aparece em outro lugar.

Uma personalização é escrita para resolver algo que o negócio pedia naquele momento. Um fluxo de aprovação com os valores que a empresa movimentava seis anos atrás. Uma validação que existe porque um cliente grande exigia um campo específico. Um cálculo que reproduz uma regra comercial que ninguém voltou a escrever em nenhum outro lugar.

Esse código continua rodando. A razão pela qual ele existe, por outro lado, geralmente foi embora com a pessoa que o pediu ou com a que o programou.

Por isso o trabalho real não é traduzir sintaxe. É reconstruir critério. E é exatamente o trabalho que fica mais caro quanto mais se demora, porque cada ano que passa deixa menos pessoas que lembram por que o sistema faz o que faz.

Onde o risco costuma estar escondido

As personalizações não se veem. Um script é executado quando alguém salva uma transação, quando roda um processo noturno ou quando outro sistema troca dados com o NetSuite. Ninguém percebe até que falhe.

Nas contas que revisamos, o risco aparece quase sempre nos mesmos quatro lugares.

• Finanças e conformidade. Documentos no formato que cada país exige, cálculos de impostos, validações de fechamento. É o grupo em que uma falha silenciosa custa mais caro, porque é detectada tarde e com o mês já fechado.
• Vendas. Regras de preço, descontos por volume, comissões, fluxos de aprovação de pedidos. Costumam ser os scripts mais modificados ao longo dos anos e os que têm menos documentação.
• Compras e operações. Aprovações por valor, recebimento de mercadoria, movimentações de estoque, reservas.
• Integrações. Tudo o que conecta o NetSuite ao e-commerce, ao operador logístico, ao banco ou a um sistema próprio. Há um ponto extra aqui, essas integrações frequentemente também se apoiam em métodos de autenticação com seu próprio calendário de aposentadoria, então merecem ser revisadas com esse olhar duplo.

Não se trata de afirmar que todos esses processos vão falhar. É onde vale a pena olhar primeiro.

A pergunta que quase nenhuma empresa consegue responder hoje

Se tivéssemos que reduzir todo este tema a uma única pergunta, seria esta.

Quem faz a manutenção de cada uma das personalizações que sustentam a sua operação, e o que acontece se amanhã uma delas parar de funcionar?

A maioria das empresas não consegue responder. Não por desorganização, mas porque essa informação nunca foi centralizada. Ela foi se acumulando ao longo de implementações, trocas de fornecedor, consultores que entraram e saíram, e pedidos urgentes que foram resolvidos e nunca documentados.

Responder a essa pergunta é, por si só, o entregável mais valioso de todo este processo. Serve para a migração ao SuiteScript 2.1, mas serve também no resto do tempo, quando há uma melhoria a decidir, um fornecedor a avaliar ou um número que não fecha.

Se a sua empresa não usa NetSuite

O caso do SuiteScript é um exemplo bem documentado de algo que acontece em todas as plataformas. O seu ERP, o seu CRM, o seu sistema de faturamento ou a sua plataforma de e-commerce vão aposentar versões, APIs e métodos de autenticação, e vão fazê-lo com um aviso que provavelmente não chega à diretoria.

Há três perguntas que vale a pena conseguir responder sobre qualquer software em que a sua empresa apoie um processo importante.

1. O que está personalizado? Não quais funções usamos, mas o que foi programado sob medida para nós.
2. Sobre qual versão está escrito e até quando o fornecedor a suporta? Esta é a que quase nunca se pergunta, e é a que antecipa o problema com anos de margem.
3. Quem faz a manutenção hoje? Com nome. Se a resposta for "quem fez a nossa implementação", convém confirmar que essa pessoa ainda esteja por aí e ainda tenha o conhecimento.

Se você consegue responder a essas três sobre os seus sistemas críticos, os anúncios de aposentadoria deixam de ser notícias incômodas e passam a ser tarefas com data.

O que estamos fazendo na Deimos Solutions

Decidimos tratar isso como um projeto nosso e não como uma consulta que esperamos receber.

• Verificamos o calendário contra a documentação da Oracle, não contra resumos de terceiros, e publicamos as fontes no final deste artigo para que qualquer pessoa possa conferir.
• Escrevemos o guia técnico completo do processo de migração e o publicamos aberto, inclusive a parte que explica por que mudar a etiqueta de versão não basta.
• Estamos revisando conta por conta as personalizações dos nossos clientes, com um plano por cliente e não um aviso geral.
• Abrimos o inventário sem custo para qualquer empresa que tenha NetSuite, trabalhe com a gente ou não, porque o diagnóstico não deveria depender de contratar um serviço.

Dizemos isso com uma intenção concreta. Um fornecedor que traz este tema em 2026, com fontes e com um plano, é diferente de um que o traz em 2028 com um orçamento de urgência.

Como é um plano que não termina em correria

A margem que a Oracle deu é ampla, então não é preciso fazer tudo de uma vez. Distribuído, o trabalho se parece com isto.

2026, o ano de saber. Inventário completo das personalizações, com a versão real de cada uma, o processo de negócio que ela atende e o responsável pela manutenção. É a etapa mais barata e a que habilita todas as decisões seguintes.

2027, o ano de decidir e testar. Com o inventário em mãos, cada personalização recebe uma rota. É atualizada, tem sua compatibilidade testada ou é aposentada se já não é usada, o que é um resultado mais comum do que parece. Os testes vão em sandbox, com transações reais, começando pelo que envolve dinheiro.

2028, o ano de fechar. Passagem para produção por etapas, com os processos críticos já migrados e validados no ano anterior. O que sobra são os desenvolvimentos acessórios e os casos de borda.

Comparado com resolver tudo entre dois fechamentos contábeis, a diferença não é de esforço total. É de risco.

Perguntas frequentes

Nossa empresa não usa NetSuite. Por que deveríamos ler isso?

Porque o padrão se repete em qualquer plataforma. Toda empresa que personalizou seu software acumula desenvolvimentos que seguem funcionando sem que ninguém os revise, até que o fornecedor aposente a versão sobre a qual foram escritos. O NetSuite avisou com dois anos de antecedência. Não todos os fornecedores fazem isso.

O que acontece se não fizermos nada até 2028?

No curto prazo, nada. O risco é de concentração. Um trabalho que pode ser distribuído em dois anos, com testes tranquilos e correções sem pressão, passa a ser executado em poucos meses e competindo com o fechamento contábil. É aí que aparecem os erros.

Quem deveria liderar isso dentro da empresa?

Convém que não fique só com a área técnica. As decisões sobre o que migrar, o que aposentar e em que ordem dependem do impacto no negócio, e isso quem sabe é quem usa o processo todos os dias. O esquema que funciona melhor combina um responsável técnico com um referente de finanças e outro de operações.

Nosso fornecedor de NetSuite não falou nada. Isso é normal?

É frequente, e não indica necessariamente desinteresse. O aviso chega com a versão 2026.2 e as contas são atualizadas de forma escalonada, de modo que muitas equipes ainda não o viram. Vale perguntar, porque a resposta diz bastante sobre como a sua conta é gerenciada.

Como sabemos se nossas integrações também estão afetadas?

É preciso revisá-las separadamente. As integrações com sistemas externos costumam se apoiar em desenvolvimentos antigos e, além disso, têm seu próprio calendário de mudanças nos métodos de autenticação. São dois temas distintos que convém olhar na mesma revisão.

Quando deveríamos começar?

O inventário vale a pena ser feito este ano, porque é barato, não interrompe nada e é o único dado que permite decidir o resto. As migrações podem esperar até 2027. O que não convém é chegar a 2028 sem saber quantas personalizações existem nem quais processos dependem delas.

O inventário, sem custo

O primeiro passo de tudo isso não exige contratar nada, e achamos que também não deveria.

Na Deimos Solutions fazemos o diagnóstico e inventário inicial sem custo, você trabalhe com a gente ou não. Inclui a identificação completa dos scripts afetados, a versão real com que cada um é executado, e um relatório escrito para que também quem não é técnico entenda.

Com esse relatório você pode priorizar, planejar, pedir orçamento a quem quiser ou simplesmente arquivá-lo sabendo que a sua conta está em ordem. Se depois quiser que a gente cuide da migração, enviamos uma proposta. Sem compromisso, e o inventário fica com você de qualquer forma.

Conclusão

A Oracle deu uma margem incomumente ampla para uma mudança deste tamanho. O que ela não deu, porque não pode dar, é o mapa da sua própria conta.

Esse mapa é o que acaba valendo bem depois de 2028. Uma lista do que está personalizado, para qual processo, sobre qual versão e sob responsabilidade de quem não se usa uma única vez. Se usa cada vez que há uma melhoria a decidir, um fornecedor a avaliar ou um número que não fecha.

E vale insistir nisto, o que se esgota enquanto o tema espera não são os anos de prazo. É a quantidade de gente que ainda lembra por que o sistema faz o que faz.

Fontes

• Oracle NetSuite, Transitioning To SuiteScript 2.1. docs.oracle.com
• Oracle NetSuite, Identifying Scripts That Are Not Using SuiteScript 2.1. docs.oracle.com
• Oracle NetSuite, Choosing A Migration Path. docs.oracle.com
• Oracle NetSuite, Enabling SuiteScript 2.1 at the Account Level. docs.oracle.com
• Oracle NetSuite, NetSuite 2026.2 September Minor Release Notes. docs.oracle.com