Probar una migración a SAP S/4HANA significa verificar, antes del go-live, que los procesos críticos de tu empresa —facturar, despachar, cobrar, pagar y cerrar el mes— siguen funcionando igual o mejor en el sistema nuevo, incluidas las customizaciones y las integraciones con bancos, organismos fiscales y otras aplicaciones. En QActions, consultora de testing de software con sedes en Buenos Aires, Asunción y Miami, partner de Tricentis desde 2018, diseñamos y ejecutamos esas pruebas con Tricentis Tosca y LiveCompare para empresas de Argentina, Paraguay y el resto de LATAM. Esta guía explica qué probar, en qué orden, cuánto cuesta y cómo usar la inteligencia artificial para llegar al go-live sin apostar la operación.
El reloj ya corre. SAP confirmó que el mantenimiento estándar de SAP Business Suite 7 —lo que casi todos llaman ECC— termina a fines de 2027, con un mantenimiento extendido opcional hasta fines de 2030 (SAP News, febrero de 2020). Y según Gartner, a fines de 2024 el 61 % de los cerca de 35.000 clientes de ECC en el mundo todavía no había licenciado S/4HANA (The Register, marzo de 2025).
Si tu empresa está en ese grupo, o ya firmó y el cronograma aprieta, este artículo es para ti.
¿Qué pasa el lunes después de un go-live que salió mal?
Hagamos el ejercicio. Es lunes, primer día hábil con S/4HANA en producción. A las 9:15 llama el gerente de logística: el sistema no libera las órdenes de despacho porque una regla de crédito que en ECC estaba en una customización Z no se migró igual. A las 10:00, facturación avisa que la integración con el organismo fiscal rechaza los comprobantes por un campo con otro formato. A las 11:30, tesorería no puede generar el archivo de pagos para el banco. Los camiones esperan en el andén. Los clientes llaman. Y el equipo del implementador está, con toda la buena voluntad, buscando la causa en un sistema que hace tres días no existía.
Nadie hizo nada «mal» en particular. Lo que pasó es más simple y más común: se probó lo que el proyecto construyó, pero no se probó lo que el negocio necesita para operar. Esa diferencia, que en una planilla de proyecto parece un detalle, es la que se paga en pedidos que no salen, multas, horas extra y, sobre todo, en la confianza del directorio en el área de sistemas.
Ese es el dolor central de esta guía: el miedo a que el go-live de S/4HANA frene la operación. Todo lo que sigue —fechas, costos, inteligencia artificial, herramientas— está al servicio de una sola pregunta: cómo llegar a ese lunes sabiendo, con evidencia, que todo va a funcionar.
⚠️ Revlon: 64 millones de dólares en pedidos que no salieron
No hace falta imaginar el escenario: ya ocurrió, y quedó documentado ante la SEC de Estados Unidos. En febrero de 2018, Revlon puso en marcha un nuevo ERP de SAP en su planta de Oxford, Carolina del Norte, para integrar planificación, abastecimiento, manufactura, distribución y finanzas de buena parte de su negocio norteamericano. Según sus propias presentaciones, los problemas durante el cambio hicieron que la planta recuperara capacidad más lento de lo previsto y la empresa no pudo despachar pedidos por unos US$ 64 millones de ventas netas, además de incurrir en US$ 53,6 millones de cargos adicionales para remediar la caída en el nivel de servicio (Computer Weekly, mayo de 2019).
La historia no terminó ahí. Revlon reconoció una «debilidad material» en sus controles internos vinculada a la implementación, y varios estudios de abogados presentaron demandas colectivas en nombre de sus accionistas. Un proyecto de sistemas se convirtió en un problema de ventas, de auditoría y de mercado de capitales.
¿El ERP era malo? No. SAP funciona en decenas de miles de empresas. El problema estuvo en la transición: en cómo se validaron los procesos, los controles y la capacidad operativa antes de encender el sistema nuevo. Exactamente lo que una estrategia de testing seria está diseñada para atrapar.
¿Cuánto tiempo queda realmente para migrar a S/4HANA?
Menos del que parece. Estas son las fechas que importan, con su fuente:
- 31 de diciembre de 2027: fin del mantenimiento estándar de los componentes centrales de SAP Business Suite 7 (ECC).
- 31 de diciembre de 2030: fin del mantenimiento extendido opcional, que se paga aparte; The Register informó un recargo del 2 % para esa extensión.
- 2033: en casos especiales, y solo para quienes contratan con anticipación un paquete de migración a la nube de SAP, el soporte puede extenderse hasta ese año, según la misma publicación (The Register, octubre de 2025).
- 2040: compromiso de mantenimiento de SAP para S/4HANA.
Ahora suma el calendario real de un proyecto: selección del implementador, diseño, construcción, varias rondas de pruebas, capacitación, congelamiento de cambios, go-live e hypercare. Para una empresa mediana o grande, eso se mide en trimestres, no en semanas. Y si todas las empresas que hoy no licenciaron —recordemos, el 61 %— se mueven al mismo tiempo, los especialistas buenos van a escasear exactamente cuando más se los necesite.
La duda también es real. Una encuesta de Freeform Dynamics a 455 CIO, gerentes de sistemas y especialistas SAP, patrocinada por Rimini Street, encontró que el 95 % considera que armar un caso de negocio positivo para migrar exige un gran esfuerzo o es directamente difícil, y que el 83 % no entiende del todo las políticas y plazos de migración de SAP. Si estás en esa incertidumbre, no estás solo. Pero la incertidumbre no detiene el calendario.
¿Por qué el testing es el cuello de botella de toda migración SAP?
Porque una migración a S/4HANA no es una actualización de versión. Cambia el modelo de datos, cambian transacciones, se simplifican tablas y aparece una nueva experiencia de usuario. Y sobre todo eso descansan años de decisiones propias de tu empresa: customizaciones Z, reportes a medida, interfaces con bancos, con la DNIT o ARCA, con el WMS, con el e-commerce, con el sistema de RR. HH.
Cada una de esas piezas es un punto donde algo puede romperse sin que nadie lo note hasta producción. Y cuantas más adaptaciones tiene un sistema, más grande es la superficie a probar. El caso de Lidl lo ilustra a la perfección: la cadena de supermercados abandonó en 2018 su proyecto eLWIS tras siete años y una inversión estimada en 500 millones de euros. Entre las causas reportadas, Lidl valuaba su inventario a precio de compra mientras el estándar de SAP para retail trabajaba con precios de venta; en lugar de adaptar el proceso, se adaptó el software, y con cada adaptación el rendimiento cayó y los costos subieron (Consultancy.uk, agosto de 2018; ni Lidl ni SAP confirmaron oficialmente la cifra).
La lección para tu migración no es «no customices». Es que cada customización que conservas es una deuda de pruebas que vas a tener que pagar en cada ciclo: en la migración, en cada paquete de soporte y en cada actualización futura. Por eso el testing no es una etapa al final del proyecto. Es la columna vertebral del plan.
Las cuatro formas de probar una migración (y por qué tres no alcanzan)
Todas las empresas eligen, consciente o inconscientemente, una de estas estrategias. Seamos honestos con cada una.
1. «Que lo prueben los usuarios clave.» Los key users conocen el negocio mejor que nadie y su validación es imprescindible. El problema es pedirles que además ejecuten cientos de casos a mano, mientras siguen haciendo su trabajo diario. Lo que pasa en la práctica: se prueba el camino feliz, se saltean los casos raros y la tercera ronda de regresión se hace con cansancio. Sirven para aceptar, no para cubrir.
2. «Que lo pruebe el implementador.» Es cómodo y parece lógico: ellos construyeron, ellos saben. Pero es el mismo que tiene que cumplir fechas el que certifica que todo está bien. No es una cuestión de buena o mala fe, es un conflicto de incentivos que cualquier auditor señalaría. En un proyecto donde el go-live mueve facturación, nadie debería corregir su propio examen.
3. «Probemos todo, por las dudas.» La estrategia del miedo. Suena prudente y es la más cara: miles de casos, ciclos interminables, equipos agotados y, paradójicamente, menos foco en lo que de verdad cambió. Salt River Project, una empresa de agua y energía de Arizona que abastece a más de dos millones de personas, describía así su enfoque anterior: «probar todo», con ciclos de aceptación largos e intensivos en mano de obra.
4. «Ya lo arreglamos en hypercare.» La versión más arriesgada: salir a producción con lo que haya y corregir sobre la marcha. A veces funciona. Cuando no funciona, se parece mucho a la historia de Revlon.
La alternativa que sí funciona combina lo mejor de las tres primeras sin sus defectos: pruebas basadas en riesgo, con análisis de impacto, regresión automatizada y validación final de los usuarios clave, ejecutadas por un equipo independiente del que construye. Veamos cómo se hace, paso a paso.
Cómo planificar el testing de una migración a S/4HANA: 8 pasos
Paso 1: Inventaría los procesos que, si fallan, frenan la empresa
Empieza por el negocio, no por el sistema. ¿Cuáles son los diez a veinte procesos que, si se detienen un día, cuestan dinero o reputación? Casi siempre aparecen order-to-cash (pedido, despacho, facturación, cobro), procure-to-pay (compra, recepción, pago a proveedores), record-to-report (cierre contable) y, según la industria, producción, mantenimiento o liquidación de sueldos. Para cada uno anota su volumen, sus picos y quién es el dueño funcional. Ese mapa define el alcance mínimo de las pruebas.
Paso 2: Mide el impacto real del cambio con análisis asistido por IA
En lugar de «probar todo», identifica qué objetos, transacciones y código propio toca efectivamente la migración. Herramientas de análisis de impacto como Tricentis LiveCompare cruzan los cambios técnicos con el uso real del sistema y devuelven una lista priorizada de lo que hay que probar. Salt River Project, al usar LiveCompare en su migración a SAP HANA y EHP8, redujo un 25 % sus pruebas de integración y un 50 % sus pruebas de aceptación de usuario frente a su proyecto anterior (Tricentis, caso Salt River Project). Menos casos, pero los correctos.
Paso 3: Elige la estrategia de pruebas según el tipo de migración
No se prueba igual una conversión técnica del sistema existente (brownfield) que una implementación desde cero (greenfield) o una migración selectiva de datos y procesos. En una conversión, el peso está en la regresión: que todo lo que funcionaba siga funcionando. En un greenfield, el peso está en las pruebas funcionales de procesos rediseñados y en la migración de datos maestros. Definirlo temprano evita construir pruebas que después no sirven.
Paso 4: Prepara datos de prueba sin copiar producción
La tentación es clonar producción en el ambiente de pruebas. Es rápido y es un riesgo: datos de clientes, sueldos y cuentas bancarias circulando entre consultores y entornos con menos controles. En Argentina rige la Ley 25.326 de protección de datos personales y en Paraguay la nueva Ley 7593/2025, que entra en vigencia plena en noviembre de 2027, en medio de la ola de migraciones. La alternativa es generar datos de prueba sintéticos o enmascarados que conserven la lógica del negocio sin exponer a nadie. En QActions trabajamos esto con Synthesized.
Paso 5: Automatiza la regresión de los procesos críticos
Una migración no tiene una ronda de pruebas: tiene varias. Más todos los paquetes de soporte y actualizaciones que vengan después. Probar a mano los mismos procesos cinco veces es caro y propenso a error; automatizarlos una vez y ejecutarlos cuantas veces haga falta es lo que cambia la ecuación. Tricentis Tosca permite automatizar procesos SAP de punta a punta con un enfoque basado en modelos, sin escribir código, y sus capacidades agénticas aceleran la creación y el mantenimiento de las pruebas. Lo explicamos en detalle en nuestro artículo sobre Tricentis Tosca Agentic y el testing con IA.
Paso 6: Prueba las integraciones de punta a punta
SAP casi nunca vive solo. Un pedido que nace en el e-commerce, se factura en SAP, se informa al organismo fiscal, se cobra por el banco y se despacha desde el WMS atraviesa cinco sistemas. Si pruebas cada uno por separado, el día del go-live descubres que el problema estaba en el medio. Las pruebas end to end recorren el flujo completo con datos realistas, incluidas las interfaces con terceros que el implementador no controla.
Paso 7: Prueba el rendimiento antes del primer cierre
Un sistema puede funcionar perfecto con diez usuarios y colapsar con quinientos el día del cierre de mes. Las pruebas de performance y carga simulan los picos reales —cierre contable, campaña comercial, liquidación de sueldos— antes de que los vivas en producción. Es la diferencia entre descubrir un cuello de botella en un ensayo o en el peor momento posible.
Paso 8: Define criterios de salida y una decisión de go/no-go con evidencia
Antes de empezar a probar, escribe qué tiene que pasar para salir a producción: porcentaje de casos críticos aprobados, cero defectos bloqueantes abiertos, regresión completa ejecutada, rendimiento dentro de los umbrales acordados y aceptación firmada por los dueños de cada proceso. Ese documento convierte la reunión de go-live en una decisión basada en datos, no en presión de calendario. Y prepara el hypercare con las mismas pruebas automatizadas listas para correr ante cada corrección.
¿Ya tienes fecha de go-live y no sabes si el plan de pruebas alcanza? ESCRÍBENOS POR WHATSAPP y lo revisamos contigo en 30 minutos, sin costo.
¿Cuánto cuesta (y cuánto ahorra) probar bien una migración SAP?
Empecemos por los números publicados, con su contexto. Un estudio Total Economic Impact de Forrester Consulting, encargado por Tricentis y basado en entrevistas con sus clientes, encontró para sus soluciones de calidad SAP un retorno sobre la inversión del 403 %, una cobertura de riesgo con 84 % menos pruebas, una reducción del 83 % en el tiempo de salida a producción, un 45 % menos de costos de hypercare y un repago en menos de seis meses (Tricentis, marzo de 2026). Es un estudio encargado por el fabricante: tómalo como orden de magnitud, no como promesa.
Ahora un ejemplo propio, hipotético y con los supuestos a la vista, para que lo adaptes a tu caso. Una empresa con 1.200 casos de regresión manuales, de 30 minutos cada uno, necesita 600 horas por ciclo completo. Una migración razonable tiene al menos cuatro ciclos: 2.400 horas. A un costo cargado de US$ 30 por hora entre key users y consultores, son US$ 72.000 solo en ejecución manual, sin contar el costo de oportunidad de sacar a los usuarios clave de su trabajo. Si el análisis de impacto reduce el alcance a la mitad —en línea con lo que logró Salt River Project en aceptación— y los procesos críticos se automatizan, los ciclos siguientes se ejecutan en horas en lugar de semanas. Y cada paquete de soporte futuro reutiliza esa misma regresión.
Del otro lado de la balanza, recuerda los números de Revlon: un trimestre con decenas de millones en ventas no despachadas. No hace falta que tu empresa sea Revlon para que una semana de facturación frenada cueste más que todo el presupuesto de pruebas. Si quieres profundizar en el cálculo, lo desarrollamos en nuestra guía sobre el ROI del software testing manual vs. automatizado.
¿Qué cambia la inteligencia artificial en el testing de SAP?
Mucho, pero no todo. La IA ya resuelve bien tres problemas concretos del testing SAP. Primero, decidir qué probar: el análisis de impacto cruza cambios técnicos con el uso real para priorizar. Segundo, construir y mantener las pruebas: los motores de automatización con capacidades agénticas generan casos a partir de procesos y se adaptan cuando cambia una pantalla, que es justamente lo que más encarece la automatización tradicional. Tercero, analizar fallas: agrupan errores similares y acortan el diagnóstico.
Lo que la IA no hace es reemplazar el criterio sobre qué es crítico para tu negocio, ni hacerse responsable de un defecto que llega a producción. Y conviene desconfiar de las promesas exageradas: Gartner advirtió que más del 40 % de los proyectos de IA agéntica serán cancelados antes de fines de 2027 y que muchos proveedores rebautizan como «agentes» herramientas que no lo son (Gartner, junio de 2025). Pide siempre una demostración sobre tu propio sistema.
La parte incómoda: lo que el testing no puede hacer por tu migración
Preferimos decirlo antes de que lo descubras en el proyecto.
El testing no corrige un mal diseño. Si el proceso que se definió para S/4HANA no responde a cómo opera tu negocio, las pruebas lo van a mostrar, pero no lo van a arreglar. El caso Lidl fue, antes que nada, un problema de decisiones de diseño. Lo que sí hace un buen equipo de pruebas es detectarlo temprano, cuando corregirlo todavía es barato.
No existe el go-live con cero incidentes. Cualquiera que te lo prometa está vendiendo algo. El objetivo realista es que no haya incidentes que detengan la operación, y que los menores se detecten y corrijan rápido con la regresión automatizada lista para validar cada arreglo.
La automatización cuesta más al principio. El primer ciclo automatizado suele llevar más esfuerzo que el manual. El ahorro aparece a partir del segundo ciclo y se multiplica en cada actualización posterior. Si tu proyecto tuviera un único ciclo de pruebas y nunca más fueras a tocar el sistema —algo que en SAP no pasa—, quizás no convendría.
Los usuarios clave siguen siendo indispensables. La automatización no reemplaza su validación de negocio: les saca de encima la repetición para que puedan concentrarse en lo que solo ellos saben juzgar.
¿Por qué confiar en QActions para probar tu migración SAP?
Porque es, literalmente, nuestra especialidad. QActions nació en 2011 como consultora de testing de software y hoy somos un equipo de alrededor de 57 personas en Buenos Aires, Asunción y Miami. Somos partners de Tricentis desde 2018, reconocidos como Best Services Partner LATAM en 2020 y 2022, trabajamos con Synthesized para datos de prueba y estamos certificados bajo ISO 9001:2015 por TÜV Rheinland.
Pero hay algo más importante que los sellos: somos independientes del implementador. No construimos tu S/4HANA; verificamos que lo que se construyó sostenga tu operación. Eso nos permite trabajar codo a codo con el integrador SAP que ya elegiste —sin competir con él— y darle al directorio una opinión que no depende de quién tiene que cumplir la fecha. Es el mismo principio por el que nadie audita sus propios estados contables.
Puedes ver cómo trabajamos en nuestros casos de éxito y en nuestro servicio de automatización de pruebas con IA.
¿Y si tu empresa es mediana y el presupuesto es acotado?
Entonces la estrategia basada en riesgo es todavía más importante, porque no hay margen para probar de más ni para fallar. Tres recomendaciones concretas:
Empieza por un flujo crítico. Elige el proceso que más dinero mueve —casi siempre order-to-cash— y automatiza su regresión de punta a punta antes que nada. Es la mejor póliza de seguro por peso invertido.
Pide una prueba de concepto acotada. Antes de comprometer un presupuesto grande, valida con un solo flujo automatizado en tu propio sistema. Si el proveedor no te ofrece hacerlo, es una señal.
Negocia el testing independiente desde el contrato. Si todavía no firmaste con el implementador, incluye en el plan una etapa de pruebas independiente con criterios de salida claros. Es mucho más fácil acordarlo al principio que imponerlo cuando el proyecto está atrasado.
Checklist: ¿tu migración está lista para probarse?
- ¿Tienes identificados los 10 a 20 procesos críticos y sus dueños?
- ¿Sabes cuántas customizaciones Z e interfaces vas a conservar?
- ¿Hay un análisis de impacto que diga qué cambia y qué hay que probar?
- ¿Los ambientes de prueba usan datos sintéticos o enmascarados, no copias de producción?
- ¿La regresión de los procesos críticos está automatizada o lo estará antes del segundo ciclo?
- ¿Las integraciones con bancos, fisco y otras aplicaciones se prueban de punta a punta?
- ¿Hay pruebas de performance con volúmenes de cierre de mes?
- ¿Están escritos los criterios de salida para el go/no-go?
- ¿Quien certifica las pruebas es independiente de quien construye?
Si respondiste «no» a tres o más, no es motivo de pánico, pero sí de acción inmediata.
Te ofrecemos una estimación gratuita del plan de pruebas de tu migración a S/4HANA, a partir de tu cronograma: qué probar, en qué fase, cuánto esfuerzo lleva y qué conviene automatizar. Te quedas con el análisis, trabajes o no con nosotros. HAZ CLIC AQUÍ y escríbenos por WhatsApp.
Porque el riesgo real no es que la migración sea difícil: ya sabemos que lo es. El riesgo real es llegar a ese lunes sin saber si la operación va a arrancar. Y esa incertidumbre, a diferencia de la fecha de 2027, sí se puede eliminar.
Preguntas frecuentes sobre testing en migraciones SAP S/4HANA
¿Cuándo termina el soporte de SAP ECC?
El mantenimiento estándar de SAP Business Suite 7 (ECC) termina el 31 de diciembre de 2027. Existe un mantenimiento extendido opcional, con costo adicional, hasta el 31 de diciembre de 2030, y en casos especiales vinculados a paquetes de migración a la nube puede llegar a 2033.
¿Qué hay que probar en una migración a S/4HANA?
Los procesos críticos de negocio de punta a punta (order-to-cash, procure-to-pay, cierre contable y los propios de cada industria), las customizaciones que se conservan, las integraciones con bancos, organismos fiscales y otras aplicaciones, la migración de datos maestros y el rendimiento en los picos de uso.
¿Cuánto tiempo lleva el testing de una migración SAP?
Depende del alcance, la cantidad de customizaciones y el tipo de migración, pero en general son varias rondas a lo largo del proyecto. El análisis de impacto y la automatización de la regresión son las dos palancas que más reducen la duración de cada ciclo.
¿Puede el implementador SAP hacer las pruebas?
Puede y debe hacer sus pruebas unitarias e integradas, pero la certificación final conviene que la haga un equipo independiente. Quien construye y tiene que cumplir la fecha no es el mejor posicionado para declarar que todo funciona.
¿Se pueden usar datos reales de producción en las pruebas?
Es una práctica riesgosa. Expone datos personales y financieros a más personas y entornos, y choca con leyes de protección de datos como la Ley 25.326 de Argentina o la Ley 7593/2025 de Paraguay. La alternativa recomendada son datos sintéticos o enmascarados.
¿Qué es Tricentis LiveCompare y para qué sirve en SAP?
Es una herramienta de análisis de impacto que identifica qué objetos y procesos de SAP afecta un cambio y qué pruebas hay que ejecutar. Permite pasar de «probar todo» a probar lo que realmente cambió, reduciendo ciclos sin perder cobertura de riesgo.
¿La inteligencia artificial puede automatizar el testing de SAP?
Puede acelerar mucho la priorización, la creación y el mantenimiento de pruebas automatizadas, y el análisis de fallas. No reemplaza la definición de qué es crítico para el negocio ni la validación final de los usuarios clave.
Fuentes citadas: SAP News (febrero de 2020) · The Register sobre datos de Gartner (marzo de 2025) · The Register sobre encuesta de Freeform Dynamics (octubre de 2025) · Computer Weekly, caso Revlon (mayo de 2019) · Consultancy.uk, caso Lidl (agosto de 2018) · Tricentis, caso Salt River Project · Tricentis sobre estudio Forrester TEI (marzo de 2026) · Gartner (junio de 2025).
