Epicor 10 a Kinetic Actualización: Qué implica realmente el proyecto
Qué se transfiere, y qué no.
Gonzalo Nuñez
Chief Technology Officer
Una actualización de Epicor Kinetic mueve la base del ERP y los datos empresariales hacia adelante.
El historial de transacciones, el plan de cuentas, los maestros de artículos, las órdenes abiertas, los registros de clientes y la configuración financiera viajan con la base de datos.
Lo que la actualización no avanza automáticamente es todo lo que se ha construido sobre esa base: las personalizaciones, BAQs, tableros, integraciones, informes, diseños de impresión y comportamientos del flujo de trabajo que el negocio ha agregado a Epicor a lo largo de los años.
Esas requieren una segunda línea de trabajo, y el alcance de esa línea de trabajo es lo que define el proyecto.
Comprender qué se encuentra en cada categoría es la primera tarea, y vale la pena hacerlo antes de cualquier otra cosa.
Lo que avanza
El núcleo del ERP avanza. Los datos avanzan. La funcionalidad estándar de Epicor disponible en Kinetic está disponible tras la actualización sin una línea de trabajo de conversión. Si el negocio ejecuta procesos estándar en pantallas estándar, la transición se centra en la base de datos e infraestructura, con menos trabajo a nivel de la capa de aplicación.
Qué requiere trabajo del proyecto
La capa de aplicación es donde vive el proyecto. Cada una de las siguientes áreas requiere revisión y, dependiendo de lo que encuentre el inventario, trabajo de conversión o reconstrucción:
- Personalizaciones: Las personalizaciones de formularios clásicos creadas para el Smart Client no se ejecutan en la interfaz del navegador Kinetic. Requieren conversión o rediseño en Application Studio.
- BAQs: Las BAQs (Consultas de Actividad Empresarial) deben revisarse para la compatibilidad con el modelo de datos de Kinetic y la capa de interfaz.
- Dashboards: Los tableros creados en el entorno clásico deben desplegarse de nuevo para la interfaz del navegador. No se convierten automáticamente.
- Integraciones: Las integraciones externas llevan mapeos de campos, lógica de disparo y patrones de autenticación que deben volver a probarse en el entorno actualizado.
- Informes y diseños de impresión: Los informes SSRS y los diseños de impresión personalizados se comportan de manera diferente dependiendo de cómo fueron construidos y de qué ruta de implementación está tomando el negocio. El inventario es donde se clasifica cada uno.
- Comportamientos dependientes del flujo de trabajo: Las directivas BPM, la lógica de notificación y las automatizaciones de procesos deben verificarse frente al modelo de procesamiento de Kinetic.
La dirección del navegador de Epicor
Epicor ha estado moviendo su arquitectura de interfaz hacia el navegador durante varias versiones. Con Kinetic 2021.1, Epicor movió los formularios clásicos al soporte de mantenimiento, con las nuevas funciones disponibles exclusivamente en los formularios del navegador. Kinetic 2025.2 es la versión final en la que está disponible el Smart Client. Con 2026.1, Epicor reemplaza el Smart Client por formularios del navegador.
Esa dirección es relevante para el proyecto de actualización porque establece la expectativa para cada personalización y flujo de trabajo construido sobre la interfaz clásica. Todo lo diseñado para el Smart Client necesita ser evaluado para el entorno del navegador.
Para una comparación de lo que cambió entre Epicor 10 y Kinetic como producto, vea Epicor Kinetic vs. Epicor ERP: ¿Qué es Diferente?. Este artículo cubre el proyecto de actualización.
Comience con un inventario, no con una cotización
Una cotización de proyecto producida antes de inventariar el entorno es una estimación. El inventario es lo que convierte la actualización de un plan general en una línea de trabajo con alcance definido, y es el paso que determina si el alcance del proyecto refleja el entorno real.
El inventario abarca cada objeto y dependencia que el negocio ha construido o configurado sobre Epicor:
- Cada personalización, incluidas las personalizaciones de formularios, directivas BPM y capas de código
- Cada BAQ, incluidas aquellas que alimentan tableros, informes y herramientas externas
- Cada tablero, incluidos aquellos utilizados en operaciones diarias e informes ejecutivos
- Cada integración, incluyendo conectores de terceros, flujos EDI y dependencias de API
- Cada informe SSRS y diseño de impresión personalizado, incluidos aquellos vinculados a impresoras específicas o rutas de salida
- Cada dependencia de almacenamiento de archivos, incluidos adjuntos, rutas de documentos y archivos alojados en el servidor
- Cada comportamiento dependiente del flujo de trabajo, incluyendo la lógica de notificación, las cadenas de aprobación y las automatizaciones de procesos
Clasifique antes de delimitar el alcance
Una vez que el inventario esté completo, cada elemento recibe una clasificación: conservar tal cual, convertir para Kinetic, reconstruir desde cero, reemplazar por un equivalente estándar de Kinetic o retirar. Esa clasificación impulsa la estimación del alcance. Los elementos que se pueden retirar reducen el proyecto. Los elementos que requieren reconstrucción son los que necesitan tiempo, pruebas y aprobación.
Para una actualización de Epicor 9 o 10 a Kinetic, lo que normalmente necesita reconstruirse son las personalizaciones, BAQs, tableros e integraciones. Para una migración de Kinetic local a Kinetic en la nube, el enfoque se desplaza hacia personalizaciones dependientes del servidor, integraciones y enrutamiento de impresión.
El inventario y la fase
Para empresas que gestionan entornos multiempresa o con múltiples sitios, el inventario es también donde se establece la viabilidad de la fase. Si una actualización por fases es realista depende de cómo esté estructurado el entorno: cómo comparten datos las empresas, cómo se delimitan las integraciones y cómo se distribuyen las personalizaciones entre entidades. Eso no se puede determinar desde fuera. Proviene del inventario.
El inventario no es un entregable de proyecto que venga después del alcance. Es la entrada que hace posible el alcance.
Los plazos de soporte son otra razón para completar el inventario antes que cualquier otra cosa. El soporte para una versión de Epicor dada depende de la versión y de la política de ciclo de vida de Epicor. El equipo de actualización puede evaluar eso frente a los resultados del inventario y incorporarlo en la cronología del proyecto.
Elija la ruta: Kinetic en local o Kinetic en la nube
El inventario le dice al negocio lo que tiene. La decisión de la ruta le dice al equipo de actualización cómo se ve el plan de trabajo. En local y en la nube no son el mismo proyecto, con diferentes entornos de hosting. Cuatro criterios guían la decisión.
Profundidad de la personalización
Cuanto más haya construido el negocio sobre Epicor, más importa la ruta. Las personalizaciones que dependen del acceso del lado del servidor, de los sistemas de archivos locales o de la interacción directa con la base de datos se comportan de manera diferente en un entorno en la nube que en local. El inventario mostrará qué personalizaciones llevan esas dependencias. Ese hallazgo alimenta directamente la decisión de la ruta.
Informes y configuración de impresión
La arquitectura de informes es el siguiente factor a considerar. Los informes SSRS construidos con estilos de informe estándar de Epicor tienen una ruta de conversión diferente a los informes construidos fuera de esos estilos. La enrutación de impresión que depende de configuraciones de impresoras que residen en el servidor debe ser replanteada para la nube. El inventario identifica qué informes caen en cada categoría.
Diseño de integraciones
Cómo se construyen las integraciones determina cuánta retesting requiere la ruta. Las integraciones que dependen del entorno del servidor deben verificarse con respecto a la ruta elegida.
Cómo quiere operar el departamento de TI el sistema
En local mantiene la gestión de la infraestructura en interno. En la nube la transfiere a Epicor. Eso es una decisión operativa tanto como técnica, y afecta al personal, al ritmo de los parches, y a cómo el negocio maneja futuras versiones de Epicor.
El equipo de actualización desglosa estos criterios con el negocio antes de que el alcance del proyecto se finalice. La ruta no es predeterminada; es una decisión con consecuencias para el plan de trabajo.
Para más información sobre Opciones de implementación de Epicor Kinetic, incluyendo lo que cubre un compromiso de actualización estructurada, esa página tiene los detalles.
Reconstruir y probar en una copia
El trabajo de conversión y retest se realiza en una copia de no producción del entorno.
El equipo de actualización no reconstruye las personalizaciones ni vuelve a probar las integraciones en el sistema en vivo.
La copia es donde se procesan los elementos clasificados del inventario antes de tomar cualquier decisión de producción.
Qué convierte y retesta el equipo de actualización
Para una actualización de Epicor 9 o 10 a Kinetic, el equipo de actualización revisa y convierte las personalizaciones y BAQs para Kinetic, y vuelve a probar las integraciones.
Para una migración de local a nube, las personalizaciones dependientes del servidor se rehacen, y la enrutación de impresión y el almacenamiento de archivos se trasladan al nuevo entorno.
Los dashboards que se construyeron para la interfaz clásica deben desplegarse de nuevo para la interfaz del navegador. Las directivas BPM deben verificarse frente al modelo de procesamiento de Kinetic, no asumir que se transfieren intactas. Los informes SSRS se prueban según la ruta de despliegue, porque lo que sobrevive en local y lo que sobrevive en la nube no es lo mismo.
Pruebas por rol, no por objeto
La fase de retest abarca más que objetos técnicos. El equipo de actualización ejecuta flujos de trabajo por rol: lo que hace un gerente de compras desde la creación del pedido hasta la recepción, lo que hace un planificador de producción desde la liberación del trabajo hasta la captura de mano de obra, lo que hace un representante de ventas desde la cotización hasta la factura. Esos recorridos basados en roles revelan problemas que las pruebas a nivel de objeto no descubren.
Los criterios de aprobación se definen antes de que comience la prueba, no después. Se documenta la salida esperada, el movimiento de datos esperado, el manejo de excepciones esperado y la salida de informes esperada. Un elemento pasa cuando cumple esos criterios, no cuando se ejecuta sin un mensaje de error.
Registro de incidencias y aceptación
Cada incidencia encontrada en el entorno de copia se registra, se prioriza y se resuelve antes de que el proyecto pase al corte.
El proceso de aceptación no es un único evento de aprobación. Es un registro continuo de lo que se probó, lo que pasó, lo que se corrigió y lo que se volvió a probar. Ese registro se convierte en parte de la documentación del proyecto y la base para la decisión de corte.
Las pruebas en una copia no son opcionales. Es el mecanismo que separa un corte planificado de una recuperación no planificada.
Planifique el corte alrededor de la producción
Una planta 24/7 no puede detenerse un fin de semana. La planificación de corte para un entorno de fabricación parte de esa restricción, no de una ventana de mantenimiento genérica.
El equipo de actualización elabora el plan de corte en función de lo que la producción realmente requiere: cuándo funciona la planta, cuándo no, cómo se ve la ventana mínima viable y qué sucede si la ventana no es suficiente.
Dos puntos de control que controla el cliente
El plan de corte incluye dos puntos de control que son propiedad del negocio, no del equipo de actualización.
El primero es la aprobación del mapa de campos antes de que se mueva cualquier cosa.
El negocio confirma que el plan de migración de datos asigna correctamente los campos de origen a los campos de destino, que se comprende la lógica y que la salida es la que espera el negocio.
Nada se mueve hasta que ese visto bueno esté en su lugar.
El segundo es la confirmación de que los conteos coinciden antes de que el sistema antiguo pase a lectura solamente.
Los conteos de registros, los totales de transacciones y los saldos de partidas abiertas se reconcilian entre la fuente y el destino.
El sistema antiguo no pasa a lectura solamente hasta que el negocio confirme que los números coinciden.
Estos dos puntos de control son controlados por el cliente porque son los dos momentos del proyecto en los que una mala decisión no puede deshacerse rápidamente.
El equipo de actualización proporciona los datos y las herramientas. El negocio proporciona la aprobación.
Soporte de la primera semana
Go-live no es el fin del proyecto. La primera semana tras la puesta en producción es donde surgen los casos límite: flujos de trabajo que no se cubrieron en las pruebas, salidas de informes que difieren de lo esperado, preguntas de los usuarios que no surgieron durante la capacitación.
El equipo de actualización ejecuta un modelo estructurado de soporte en la primera semana, con triage de incidencias definido, niveles de prioridad y rutas de resolución.
La formación basada en roles es parte de la preparación para la puesta en producción. Los usuarios que han trabajado en la interfaz clásica durante años necesitan tiempo guiado en el entorno del navegador antes del corte, no después.
Prueba
Greenpaper, un cliente TCP, ejecutó Epicor en local desde 2015 y se movió a la nube de Kinetic en 2022 mientras operaba una planta 24/7.
Hable con TCP sobre su actualización de Kinetic
Integraciones y agentes después de la actualización
Las integraciones no se transfieren por suposición. Una integración que funcionaba en Epicor 10 debe volver a probarse en Kinetic, porque la actualización cambia el entorno contra el que opera la integración. Los mapeos de campos, la lógica de disparo, los patrones de autenticación, la temporización, las rutas de movimiento de archivos y el manejo de excepciones deben verificarse en el entorno actualizado antes de la puesta en producción.
Qué cubre la retest
El alcance de la retest para las integraciones refleja la clasificación del inventario. Cada integración se prueba contra los escenarios que maneja en producción: los datos que mueve, las condiciones que lo desencadenan, los resultados que produce y los errores que se supone que debe capturar. El problema práctico en una actualización no es siempre que una integración esté completamente rota. Es que un campo específico, un disparador o un escenario operativo se comporta de manera diferente en el nuevo entorno. Las pruebas a nivel de escenario revelan esas diferencias. La confianza a nivel de conector no es suficiente.
Agentes Fluent
Los agentes Fluent se conectan a través de la capa de conectores, no a través de las personalizaciones dentro de SugarAI o Kinetic. Esa arquitectura significa que una actualización necesita una prueba, no una reconstrucción. La capa de conectores es lo que se verifica en el entorno actualizado. Los propios agentes no necesitan reconstruirse desde cero.
La integración Epicor y CRM
La integración entre Epicor y un sistema CRM requiere atención cercana durante la retest de la actualización. La lógica de sincronización de datos, el mapeo de objetos entre registros de ERP y CRM, los disparadores de proceso que se activan entre ambos sistemas y los puntos de entrega donde un flujo de ventas pasa a uno operativo deben confirmarse en el entorno actualizado.
Para empresas que gestionan una Integración Epicor y CRM, la actualización es el momento para verificar que cada escenario de sincronización funciona como se espera, no para asumir que la integración sobrevivió intacta porque el conector sigue conectado. La Integración SugarAI en particular lleva dependencias a nivel de campo y de disparadores que requieren pruebas de escenarios, no solo una verificación de conexión.
Qué preguntar a quien gestione su actualización
Los proveedores le ofrecen herramientas de actualización y documentación. No limpian sus datos, no reconstruyen las personalizaciones que se rompen ni rehacen los informes. Ese es el trabajo que el socio de actualización posee, y es el trabajo a evaluar antes de que comience el proyecto.
Estas preguntas separan a un socio que ha gestionado este proyecto antes de uno que lo está gestionando por primera vez en su entorno.
¿Quién posee el inventario, y qué produce? El inventario es la base del alcance. Pregunte qué se catalogará, cómo se clasifican los ítems y cuál es la salida antes de que comience cualquier trabajo.
¿Qué se reconstruye frente a lo que se retira? No todo en el inventario necesita avanzar. Pregunte cómo distingue el socio entre ítems que vale la pena convertir y aquellos que vale la pena reemplazar con la funcionalidad estándar de Kinetic.
¿Cómo cambia la ruta elegida el alcance? Local y nube son proyectos diferentes. Pregunte cómo cambia el alcance del socio entre las dos rutas y qué significa la decisión de ruta para las personalizaciones, los informes y las integraciones específicamente.
¿Cómo se gestionan los informes y la enrutación de impresión? Pregunte qué informes se trasladan, cuáles requieren conversión y cuáles deben reconstruirse. Pregunte cómo se maneja la enrutación de impresión para la ruta de implementación elegida.
¿Cómo se vuelven a probar las integraciones? Pregunte si las pruebas de integración se basan en escenarios o en conexiones. Las pruebas basadas en escenarios detectan los problemas que importan. Las pruebas basadas en conexiones determinan si el conducto está abierto.
¿Cómo se planea el corte alrededor de la producción? Pregunte cómo es el plan de corte para un entorno de fabricación. Pregunte cuáles son los dos puntos de control controlados por el cliente y cómo se maneja la reversión si algo sale mal.
¿Quién es el responsable de la aceptación por parte del usuario, y cuándo ocurre? Pregunte si los usuarios del negocio participan en las pruebas antes de la puesta en producción, no solo después.
Vea cómo TCP realiza actualizaciones de Epicor
Si usted está planificando una actualización de Epicor Kinetic, TCP realiza actualizaciones de Epicor 10 a Kinetic con precio fijo y movimientos de local a la nube, con el corte planeado alrededor de la producción.
Preguntas Frecuentes
Las personalizaciones clásicas que no se convirtieron antes de la puesta en producción siguen funcionando en el cliente clásico, cuando ese cliente aún está disponible. No se ejecutan en la interfaz del navegador de Kinetic. Con Kinetic 2026.1, Epicor reemplaza el Smart Client por formularios del navegador, lo que significa que los usuarios que trabajan en el navegador no tendrán acceso a las personalizaciones clásicas no convertidas en absoluto. Cualquier personalización que la empresa necesite en la interfaz Kinetic debe volver a desarrollarse o redesplegarse en Application Studio antes de la puesta en producción. Dejar las conversiones para después de la migración crea una brecha entre lo que esperan los usuarios y lo que entrega el sistema.
Ambas rutas son válidas, y la decisión depende del entorno. Epicor mismo ofrece la opción de actualizar a Kinetic en la nube y de adoptar la experiencia basada en navegador en un solo movimiento, lo que reduce el número de eventos de transición por los que pasa la empresa. Ejecutarlas como proyectos separados le da al equipo un mayor control sobre cada flujo de trabajo y limita las variables en cualquier corte de migración. Los factores decisivos son la profundidad de la personalización, la complejidad de la integración, cuánto debe cambiar la arquitectura de informes y cuánto cambio puede absorber la empresa de una sola vez.
Depende de cómo fueron construidos y de qué ruta de implementación está tomando la empresa. Los informes SSRS construidos con los estilos de informe estándar de Epicor y definiciones de datos de informes tienen una ruta de conversión diferente a los informes construidos fuera de esos estándares. Los informes construidos fuera de los estilos de informe estándar de Epicor deben ser verificados con respecto a la ruta de implementación elegida, y el inventario determina cuáles de ellos requieren conversión. Los diseños de impresión personalizados siguen la misma lógica. El paso de inventario es donde cada informe se clasifica y se establece el alcance de la conversión.
La ventana de corte es donde la integración de CRM necesita un plan para usted. Antes de que el sistema antiguo entre en modo de solo lectura, usted debe pausar la sincronización para que las transacciones creadas durante la conmutación de los sistemas no generen registros duplicados en ambos entornos. El orden en que se vuelva a apuntar el endpoint es importante: usted debe apuntar el CRM al entorno Epicor actualizado solo después de que se confirme el punto de verificación de la reconciliación de conteos. Usted debe revisar cualquier transacción creada durante la ventana en relación con ambos sistemas antes de que la sincronización se reinicie.
La primera decisión es si una solución de contingencia documentada mantiene el flujo de trabajo en funcionamiento mientras se prepara una corrección, o si el problema detiene la producción y requiere una corrección inmediata. Si se necesita una corrección, se construye y se prueba en el entorno de copias antes de que se mueva a producción. Se utiliza la misma copia que el proyecto de actualización. La versión de solo lectura del sistema antiguo puede servir como referencia para el comportamiento esperado mientras la corrección está en curso. La corrección no pasa a producción hasta que cumpla los mismos criterios de aceptación utilizados durante la fase de pruebas original.
Antes. Los datos que se introducen en el entorno de actualización son los datos con los que opera la empresa después de la puesta en marcha. Limpiar registros, resolver duplicados, archivar elementos inactivos y corregir errores a nivel de campo después de la actualización significa realizar ese trabajo en el nuevo entorno bajo presión de producción. Hacerlo antes de la actualización significa que la migración mueve datos limpios, la aprobación del mapeo de campos se basa en registros precisos, y el punto de control de conciliación de conteos refleja el estado que la empresa realmente desea. La limpieza de datos previa a la migración es parte del proyecto, no una iniciativa separada.
Depende de cómo esté estructurado el entorno. Si un enfoque por fases es realista para un entorno específico, depende de cómo las empresas comparten datos, de cómo se definen los alcances de las integraciones y de cómo las personalizaciones se distribuyen entre las entidades. Eso no se puede determinar desde fuera. Proviene del inventario.
Más personas que TI. La fase de inventario requiere la aportación de las personas que usan las personalizaciones, las BAQs, los tableros y los informes que se están revisando. La fase de pruebas requiere que los usuarios de negocio ejecuten flujos de trabajo basados en roles y confirmen que los resultados coinciden con las expectativas. Los puntos de verificación de la migración requieren la aprobación de las personas que entienden cómo deben verse los datos. Finanzas, operaciones, producción, compras y ventas tienen flujos de trabajo que deben verificarse. TI administra el entorno. La empresa es dueña de los criterios de aceptación.
Un socio de actualización debería entregar el registro del proyecto que las herramientas de actualización no producen: el registro de inventario con cada objeto catalogado y clasificado; el registro de pruebas que muestra qué se probó, qué pasó y qué se corrigió; el mapa de campos firmado del punto de control previo a la migración; la conciliación de recuentos que confirme que los registros coincidían antes de que el sistema antiguo pasara a ser de solo lectura; y el runbook de corte que documenta cada paso tomado durante la ventana de corte. Esos documentos son la evidencia de que el proyecto se llevó a cabo con disciplina, y el punto de referencia por si surge algo después de la puesta en marcha.
Puede ser, si el alcance se gestiona cuidadosamente. Un proyecto de actualización que también introduce una integración de CRM o agentes de IA está ejecutando dos flujos de cambio de forma simultánea, lo que aumenta la complejidad de las pruebas y el número de variables en el corte. La actualización es un momento natural para evaluar esas adiciones porque la arquitectura de integración ya está siendo revisada. Si ejecutarlas juntas o de forma secuencial depende de la capacidad de cambio de la empresa y de la complejidad de cada flujo de trabajo. La decisión de inventario y la de ruta son buenas entradas para esa conversación.
