Oracle publicó el calendario de retiro de las versiones antiguas de SuiteScript, el lenguaje con el que se programan las personalizaciones de NetSuite. La fecha final es la versión 2028.2.
Si tu empresa usa NetSuite, acá están las decisiones que hay que tomar y cuándo. Si no la usa, el artículo igual tiene sentido, porque el problema de fondo no es de NetSuite. Le pasa a cualquier empresa que construyó parte de su operación sobre un software, y la mayoría se entera cuando algo falla y nadie sabe explicar por qué.
Este no es un artículo técnico. Si lo que buscas es el detalle de cómo se migra un script, lo escribimos aparte en Actualización necesaria, actualice los scripts a SuiteScript 2.1. Acá hablamos de la otra mitad del problema, la que no se resuelve programando.
Lo esencial, en cuatro puntos
- Hay una fecha concreta. En la versión 2028.2 de NetSuite, los scripts que usen SuiteScript 1.0, 2.0 o 2.x dejan de ejecutarse.
- Nada se rompe este año. El calendario es gradual y el primer cambio con efecto real llega en 2027.
- El problema no es técnico. Pasar el código a la versión nueva es el trabajo mecánico. El difícil es saber qué personalizaciones existen, qué procesos sostienen y quién las entiende.
- Dos años alcanzan de sobra. Seis meses, no. Esa es toda la diferencia entre planificar y apagar un incendio.
El calendario, versión por versión
Cada hito está atado a una versión de NetSuite, y las versiones llegan a cada cuenta en momentos distintos. Por eso no existe un día del calendario que valga igual para todas las empresas.
| Versión | Qué cambia | Qué significa para el negocio |
|---|---|---|
| 2026.2 | NetSuite adopta SuiteScript 2.1 como versión de referencia, tanto para desarrollos nuevos como para los que ya existen | Momento de hacer el inventario, sin presión y sin costo de oportunidad |
| 2027.1 | SuiteScript 1.0 queda con soporte solo para problemas críticos | Si un proceso crítico depende de 1.0, pasa a primera prioridad |
| 2028.1 | Los scripts 1.0 no se pueden desplegar en cuentas nuevas y los 2.0 y 2.x se ejecutan como 2.1 por defecto | Las pruebas de compatibilidad tienen que estar hechas antes de esta fecha |
| 2028.2 | Todos los scripts deben usar SuiteScript 2.1 | La transición tiene que estar terminada |
Es el plan que Oracle publica hoy y puede ajustarlo en el futuro, pero la dirección está clara y no hay motivo para esperar una prórroga.
Por qué esto se parece poco a un problema de software
La reacción habitual frente a un anuncio así es derivarlo al área de sistemas o al proveedor, y es razonable. Pero en la práctica el cuello de botella aparece en otro lado.
Una personalización se escribe para resolver algo que el negocio pedía en ese momento. Un circuito de aprobación con los montos que manejaba la empresa hace seis años. Una validación que existe porque un cliente grande exigía un dato en particular. Un cálculo que replica una regla comercial que nadie volvió a escribir en ningún lado.
Ese código sigue corriendo. La razón por la que existe, en cambio, suele haberse ido con la persona que lo pidió o con la que lo programó.
Por eso el trabajo real no es traducir sintaxis. Es reconstruir criterio. Y ese es exactamente el trabajo que se vuelve más caro cuanto más se demora, porque cada año que pasa quedan menos personas que recuerden por qué el sistema hace lo que hace.
Dónde suele estar escondido el riesgo
Las personalizaciones no se ven. Un script se ejecuta cuando alguien guarda una transacción, cuando corre un proceso nocturno o cuando otro sistema intercambia datos con NetSuite. Nadie lo nota hasta que falla.
En las cuentas que revisamos, el riesgo aparece casi siempre en los mismos cuatro lugares.
- Finanzas y cumplimiento. Comprobantes con el formato que exige cada país, cálculos de impuestos, validaciones de cierre. Es el grupo donde una falla silenciosa cuesta más caro, porque se detecta tarde y con el mes cerrado.
- Ventas. Reglas de precios, descuentos por volumen, comisiones, circuitos de aprobación de pedidos. Suelen ser los scripts más modificados a lo largo de los años y los que menos documentación tienen.
- Compras y operaciones. Aprobaciones por monto, recepción de mercadería, movimientos de inventario, reservas de stock.
- Integraciones. Todo lo que conecta NetSuite con el e-commerce, el operador logístico, el banco o un sistema propio. Acá hay un punto extra, estas integraciones suelen apoyarse además en métodos de autenticación que tienen su propio calendario de retiro, así que conviene revisarlas con esa doble mirada.
No es que todos estos procesos vayan a fallar. Es que son los lugares donde vale la pena mirar primero.
La pregunta que casi ninguna empresa puede responder hoy
Si tuviéramos que reducir todo este tema a una sola pregunta, sería esta.
¿Quién mantiene cada una de las personalizaciones que sostienen tu operación, y qué pasa si mañana una de ellas deja de funcionar?
La mayoría de las empresas no puede contestarla. No por desprolijidad, sino porque esa información nunca se centralizó. Se fue acumulando a lo largo de implementaciones, cambios de proveedor, consultores que entraron y salieron, y pedidos urgentes que se resolvieron y nunca se documentaron.
Responder esa pregunta es, en sí mismo, el entregable más valioso de todo este proceso. Sirve para la migración a SuiteScript 2.1, pero también sirve el resto del tiempo, cuando hay que decidir una mejora, evaluar un proveedor o entender por qué un número no cierra.
Si tu empresa no usa NetSuite
El caso de SuiteScript es un ejemplo bien documentado de algo que pasa en todas las plataformas. Tu ERP, tu CRM, tu sistema de facturación o tu plataforma de e-commerce van a retirar versiones, APIs y métodos de autenticación, y lo van a hacer con un aviso que probablemente no llegue a la dirección.
Hay tres preguntas que conviene poder responder sobre cualquier software en el que tu empresa apoye un proceso importante.
- ¿Qué está personalizado? No qué funciones usamos, sino qué se programó a medida para nosotros.
- ¿Sobre qué versión está escrito y hasta cuándo la soporta el proveedor? Esta es la que casi nunca se pregunta, y es la que anticipa el problema con años de margen.
- ¿Quién lo mantiene hoy? Con nombre. Si la respuesta es "el que nos implementó", conviene confirmar que siga estando y que siga teniendo el conocimiento.
Si puedes contestar esas tres sobre tus sistemas críticos, los anuncios de retiro dejan de ser noticias incómodas y pasan a ser tareas con fecha.
Qué estamos haciendo en Deimos Solutions
Decidimos tratar esto como un proyecto nuestro y no como una consulta que esperamos recibir.
- Verificamos el calendario contra la documentación de Oracle, no contra resúmenes de terceros, y publicamos las fuentes al final de este artículo para que cualquiera pueda chequearlas.
- Escribimos la guía técnica completa del proceso de migración y la publicamos abierta, incluso la parte que explica por qué cambiar la etiqueta de versión no alcanza.
- Estamos revisando cuenta por cuenta las personalizaciones de nuestros clientes, con un plan por cliente y no un aviso general.
- Abrimos el inventario sin costo a cualquier empresa que tenga NetSuite, trabaje con nosotros o no, porque el diagnóstico no debería depender de contratar un servicio.
Lo decimos con una intención concreta. Un proveedor que te trae este tema en 2026, con fuentes y con un plan, es distinto de uno que te lo trae en 2028 con una cotización de urgencia.
Cómo se ve un plan que no termina en apuro
El margen que dio Oracle es amplio, así que no hace falta hacer todo junto. Repartido, el trabajo se parece a esto.
2026, el año de saber. Inventario completo de personalizaciones, con la versión real de cada una, el proceso del negocio que atiende y el responsable de mantenerla. Es la etapa más barata y la que habilita todas las decisiones siguientes.
2027, el año de decidir y probar. Con el inventario en la mano, cada personalización recibe una ruta. Se actualiza, se prueba la compatibilidad o se retira si ya no se usa, que es un resultado más común de lo que parece. Las pruebas van en sandbox, con transacciones reales, empezando por lo que toca dinero.
2028, el año de cerrar. Pasaje a producción por etapas, con los procesos críticos ya migrados y validados desde el año anterior. Lo que queda son los desarrollos accesorios y los casos de borde.
Comparado con resolver todo entre dos cierres contables, la diferencia no es de esfuerzo total. Es de riesgo.
Preguntas frecuentes
Nuestra empresa no usa NetSuite. ¿Por qué debería leer esto?
Porque el patrón se repite en cualquier plataforma. Toda empresa que personalizó su software acumula desarrollos que funcionan sin que nadie los revise, hasta que el proveedor retira la versión sobre la que estaban escritos. NetSuite avisó con dos años. No todos los proveedores lo hacen.
¿Qué pasa si no hacemos nada hasta 2028?
En el corto plazo, nada. El riesgo es de concentración. Un trabajo que se puede repartir en dos años, con pruebas tranquilas y correcciones sin presión, pasa a ejecutarse en pocos meses y compitiendo con el cierre contable. Ahí es donde aparecen los errores.
¿Quién debería liderar esto dentro de la empresa?
Conviene que no quede solo en el área técnica. Las decisiones de qué se migra, qué se retira y en qué orden dependen del impacto en el negocio, y eso lo sabe quien usa el proceso todos los días. El esquema que mejor funciona combina un responsable técnico con un referente de finanzas y otro de operaciones.
Nuestro proveedor de NetSuite no nos dijo nada. ¿Es normal?
Es frecuente, y no siempre indica desinterés. El aviso llega con la versión 2026.2 y las cuentas se actualizan de forma escalonada, de modo que muchos equipos todavía no lo vieron. Lo que sí vale es preguntar, porque la respuesta te dice bastante sobre cómo se gestiona tu cuenta.
¿Cómo sabemos si nuestras integraciones también están afectadas?
Hay que revisarlas aparte. Las integraciones hacia sistemas externos suelen apoyarse en desarrollos antiguos y, además, tienen su propio calendario de cambios en los métodos de autenticación. Son dos temas distintos que conviene mirar en la misma revisión.
¿Cuándo deberíamos empezar?
El inventario conviene hacerlo este año, porque es barato, no interrumpe nada y es el único dato que permite decidir el resto. Las migraciones pueden esperar a 2027. Lo que no conviene es llegar a 2028 sin saber cuántas personalizaciones hay ni qué procesos dependen de ellas.
El inventario, sin costo
El primer paso de todo esto no requiere contratar nada, y nos parece que tampoco debería.
En Deimos Solutions hacemos el diagnóstico e inventario inicial sin costo, trabajes con nosotros o no. Incluye la identificación completa de los scripts afectados, la versión real con la que se ejecuta cada uno, y un informe escrito para que lo entienda también quien no es técnico.
Con ese informe puedes priorizar, planificar, pedir presupuesto a quien quieras o simplemente archivarlo sabiendo que tu cuenta está en orden. Si después quieres que nos encarguemos de la migración, te pasamos una propuesta. Sin compromiso, y el inventario queda tuyo en cualquier caso.
Conclusión
Oracle dio un margen inusualmente amplio para un cambio de este tamaño. Lo que no dio, porque no puede darlo, es el mapa de tu propia cuenta.
Ese mapa es lo que termina valiendo más allá de 2028. Una lista de qué está personalizado, para qué proceso, sobre qué versión y a cargo de quién no se usa una sola vez. Se usa cada vez que hay que decidir una mejora, evaluar a un proveedor o entender por qué un número no cierra.
Y conviene insistir en esto, lo que se agota mientras el tema espera no son los años de plazo. Es la cantidad de gente que todavía recuerda por qué el sistema hace lo que hace.
Fuentes
- 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