Cómo migrar un sistema de gestión documental heredado sin interrumpir la actividad empresarial

La migración de un sistema de gestión documental heredado no consiste simplemente en transferir archivos o rediseñar formularios. En un entorno de misión crítica, la generación de documentos puede depender de aplicaciones clave, fuentes de datos, reglas de negocio, plantillas, fuentes tipográficas, flujos de impresión, impresoras, canales digitales y archivos.

La presión por la modernización es real. En 2024, Kyndryl informó de que el 44 % de los componentes de TI de misión crítica, como servidores, almacenamiento, redes y sistemas operativos, se acercaban o ya habían alcanzado el final de su vida útil.

En DocPath, recomendamos un enfoque que priorice la continuidad: comprender el entorno de producción, migrar en fases controladas, validar los resultados frente a las referencias aprobadas, mantener la posibilidad de revertir los cambios y retirar el sistema heredado solo cuando sus dependencias hayan desaparecido.

Resumen rápido

La migración de un sistema de gestión documental heredado consiste en la sustitución controlada de una plataforma de generación de documentos o de gestión del ciclo de vida del contenido (CCM) en producción, conservando al mismo tiempo las plantillas, las reglas de negocio, las entradas de datos, los formatos de salida, las impresoras, los archivos y las aplicaciones que la invocan. Se debe utilizar cuando sea necesario modernizar un sistema que ya no recibe soporte o que es inflexible sin interrumpir las comunicaciones con los clientes. Comience con un inventario completo de dependencias y, a continuación, migre y valide por fases mientras se mantiene la producción en paralelo. Advertencia: la equivalencia de los resultados debe definirse en función de los requisitos empresariales y de cumplimiento, y no solo por la similitud visual.

En DocPath, definimos una migración que da prioridad a la continuidad en torno a seis principios fundamentales:

• Realizar un inventario de todo el entorno de producción.
• Conservar las interfaces existentes siempre que sea posible.
• Retirar los activos obsoletos antes de convertirlos.
• Crear pruebas de regresión antes de la transición.
• Ejecutar las cargas de trabajo críticas en paralelo.
• Retirar del servicio solo después de haber verificado los usuarios y los procesos posteriores.

Para las organizaciones que estén evaluando plataformas heredadas específicas, nuestrasopciones de migración de documentos heredados de incluyen vías compatibles con JetForm/Adobe Central, InfoPrint Designer/AFP Utilities y Control-D.

¿Qué es y qué no es la migración de un sistema de documentos heredado?

Definimos la migración de un sistema de documentos heredado como la sustitución de la tecnología que compone, genera, enruta, imprime, distribuye o archiva documentos empresariales, al tiempo que se conserva el comportamiento del que dependen las aplicaciones circundantes. Se diferencia de una migración de repositorios porque los documentos se generan dinámicamente a partir de datos, reglas, plantillas, recursos e integraciones en tiempo de ejecución.

La cadena de producción que solemos evaluar tiene el siguiente aspecto:

Aplicación de origen → fuente de datos → reglas de negocio → plantillas y recursos → motor de composición → formato de salida → impresora o canal digital → archivo

Esa cadena define el alcance real de la migración.

Desde nuestro punto de vista, esta distinción es importante porque un PDF que parece correcto no garantiza que un trabajo AFP se imprima correctamente, que se conserven los metadatos del archivo o que la aplicación solicitante haya recibido la respuesta esperada.

Actualmente documentamos las rutas de migración para JetForm/Adobe Central, InfoPrint Designer/AFP Utilities y Control-D.

Para las organizaciones latinoamericanas, también tenemos en cuenta entornos que pueden contener variantes del español y del portugués, terminología específica de cada país, centros de impresión locales y diferentes aplicaciones de destino. Esas diferencias deben tratarse como dependencias explícitas, en lugar de integrarse en una única configuración regional.

¿Qué se debe inventariar antes de iniciar una migración?

Antes de convertir nada, recomendamos hacer un inventario de todos los activos y dependencias necesarios para reproducir el comportamiento en producción. Las plantillas son solo una capa; también deben incluirse en el alcance los llamadores, las fuentes de datos, las reglas, las fuentes tipográficas, los formatos de salida, las impresoras, las colas, los archivos, las programaciones y los procesos de excepción.

Recomendamos asignar a cada elemento una disposición clara: migrar, consolidar, rediseñar, conservar temporalmente o retirar.

Preferimos mantener las dependencias desconocidas visibles como riesgos hasta que se resuelvan, en lugar de convertirlas silenciosamente en suposiciones.

¿Qué plantillas, reglas, fuentes y recursos reutilizables deben registrarse?

Recomendamos hacer un inventario tanto de la plantilla visible como de los recursos que controlan su comportamiento. La lógica condicional, los fragmentos compartidos, las fuentes, los gráficos, los códigos de barras, las superposiciones, las variantes lingüísticas y las muestras aprobadas deben adjuntarse a la familia de documentos correspondiente.

Incluir como mínimo:

• ID de la plantilla, versión y estado.
• Responsables de negocio y técnicos.
• Variantes por país e idioma.
• Texto condicional y reglas de supresión.
• Encabezados, pies de página y cláusulas compartidos.
• Logotipos, gráficos, superposiciones y firmas.
• Familia tipográfica, grosor, versión y licencia.
• Códigos de barras y otros elementos legibles por máquina.
• Muestras de producción aprobadas.

También recomendamos probar las sustituciones de fuentes, ya que pueden afectar al salto de línea, la paginación y el diseño de impresión. Para los resultados en español y portugués, incluimos caracteres acentuados, signos diacríticos, monedas locales y formatos numéricos representativos en el conjunto de regresión.

Ofrecemos admitimos la conversión automatizada de recursos para determinadas tecnologías de origen heredadas, aunque el proceso exacto depende de la plataforma de origen y del alcance del proyecto.

¿Qué aplicaciones de llamada y fuentes de datos dependen del motor heredado?

Recomendamos identificar todas las aplicaciones que invocan el motor heredado antes de que se finalice la arquitectura de destino. La cuestión importante no es solo qué datos se envían, sino cómo el solicitante invoca la generación y qué comportamiento espera a cambio.

Registro:

• Sistema de llamada.
• Método de invocación.
• Esquema de la carga útil o estructura del registro.
• Codificación de caracteres.
• Parámetros.
• Códigos de retorno o de estado.
• Comportamiento de reintento y repetición.
• Dependencias de programación.
• Autenticación.
• Requisitos de supervisión.

Utilizamos esta información como base para un contrato de interfaz.

Nuestrascapacidades de integración empresarial « » incluyen entornos IBM i, IBM z/OS, ERP, CRM, bancarios y de seguros.

¿Qué salidas, impresoras, archivos y sistemas posteriores deben incluirse en el inventario?

Desde nuestro punto de vista, una migración está incompleta si el nuevo motor genera un documento visualmente correcto, pero provoca fallos en el sistema que lo imprime, distribuye, almacena o recupera. Por lo tanto, todos los destinos físicos y digitales deben formar parte del proceso de identificación.

Recomendamos realizar un inventario de:

• Formatos PDF, AFP, PCL, PostScript, etiquetas y otros formatos que se utilicen realmente.
• Modelos de impresoras y colas de impresión.
• Bandejas, soportes, comportamiento en dúplex y acabados.
• Insertadoras o escáneres que funcionan con códigos de barras.
• Canales de distribución digital.
• Repositorios de archivo y valores de índice.
• API de recuperación y sistemas de supervisión.

IBM describe AFP como una arquitectura que puede depender de fuentes, definiciones de formularios, segmentos de página, superposiciones, definiciones de página y otros recursos.

Si la impresión está descentralizada en toda América Latina, recomendamos certificar los entornos locales pertinentes en lugar de dar por sentado que una única configuración de impresora representa a toda la región.

¿Qué enfoque de migración protege mejor la continuidad de la producción?

Para un parque documental de misión crítica, solemos utilizar la migración por fases con coexistencia controlada como base de planificación más segura, a menos que el análisis inicial respalde otro modelo. El enfoque adecuado depende de la criticidad de los documentos, las dependencias de las interfaces, los requisitos de reversión y de si ambos entornos pueden funcionar temporalmente.

En 2025, Kyndryl informó de que el 80 % de los 500 altos directivos de TI y empresariales encuestados habían cambiado su estrategia de modernización de mainframes durante los 12 meses anteriores.

En ese mismo estudio de 2025, el 99 % de las organizaciones encuestadas operaban en un entorno híbrido.

Recomendamos definir criterios de entrada, criterios de salida y condiciones de reversión para cada fase de migración.

Para las organizaciones latinoamericanas con diferentes sistemas locales o requisitos normativos, podemos recomendar fases por país o por unidad de negocio para reducir el impacto de cualquier incidencia.

Si su entorno actual contiene dependencias desconocidas, recomendamos comenzar con la identificación de las mismas en lugar de con la conversión. Póngase en contacto con nosotros para revisar el alcance de la migración.

¿Cómo se migra un sistema de gestión documental heredado sin interrumpir la producción?

En DocPath, recomendamos avanzar a través de etapas controladas en lugar de tratar la migración como un único evento de conversión. Cada fase debe aportar pruebas de que la siguiente fase puede llevarse a cabo de forma segura.

Nuestra hoja de ruta práctica para la migración consta de 12 pasos:

1. Establecer la gobernanza y los criterios de aceptación. Definimos los responsables, los requisitos de continuidad, los criterios de equivalencia y la autoridad para dar luz verde o rechazar la migración.
2. Crear el inventario de producción. Utilizamos el marco de inventario anterior para identificar plantillas, fuentes de datos, reglas, recursos, resultados, impresoras y archivos.
3. Trazar el gráfico de dependencias. Seguimos el recorrido de cada familia de documentos desde la aplicación de origen a través de los datos, las reglas, la representación, la salida, la distribución y el archivo.
4. Racionalizar el parque de sistemas. Identificamos los formularios obsoletos y los duplicados antes de invertir en la conversión y las pruebas.
5. Recopilamos los contratos de interfaz. Documentamos cómo cada aplicación llamante invoca el motor heredado y qué respuestas espera.
6. Capturamos los recursos y las reglas de negocio. Identificamos fuentes, superposiciones, gráficos, códigos de barras, lógica condicional y reglas de enrutamiento.
7. Creamos los entornos de destino. Separamos los controles de desarrollo, pruebas, preproducción y producción de acuerdo con los requisitos de la organización.
8. Creamos datos de prueba de referencia. Elaboramos casos representativos normales, extremos, multilingües, de varias páginas y de excepción.
9. Realizamos pruebas de regresión por capas. Validamos el significado empresarial, el diseño, el formato de salida, las impresoras, los archivos, la accesibilidad y el comportamiento operativo.
10. Ejecutamos la producción en paralelo. Procesamos entradas controladas a través de ambos entornos y conciliamos los resultados sin generar comunicaciones duplicadas con los clientes.
11. Realizamos la migración por fases. Solo trasladamos las familias de documentos, los países o las cargas de trabajo aprobadas, manteniendo la supervisión y la posibilidad de revertir los cambios.
12. Estabilizamos y desactivamos el sistema. Eliminamos el entorno heredado solo después de haber verificado todos los usuarios restantes y los procesos posteriores.

Los controles detallados para las pruebas, la producción en paralelo, la reversión y la desactivación se describen en las secciones siguientes.

Nuestrocaso práctico de migración de Fifth Third Bank con « » describe una migración en la que no fue necesario modificar las aplicaciones existentes.

¿Cómo se conservan las aplicaciones que realizan llamadas, las fuentes de datos y las reglas de negocio?

En DocPath, nuestro objetivo es minimizar los cambios innecesarios en las capas superiores y hacer explícito el comportamiento de las interfaces existentes. Si la plataforma de destino puede conservar el contrato de interfaz heredado, el motor de composición puede sustituirse sin forzar cambios en todas las aplicaciones circundantes.

Esto es importante cuando el sistema central sigue siendo adecuado para su finalidad. Sustituir la generación de documentos no implica automáticamente sustituir el ERP, la carga de trabajo del mainframe, el sistema de administración de pólizas o la aplicación IBM i que lo invoca.

Nuestraarquitectura de integración « » incluye conectividad con IBM i e IBM z/OS.

Para determinadas migraciones de JetForm/Adobe Central, también admitimos el procesamiento de los mismos datos de entrada sin que sea necesario modificar la aplicación empresarial.

Seguimos validando esa capacidad comparándola con la versión original real, el código personalizado, el preprocesamiento y los flujos de datos.

¿Qué debe contener un contrato de interfaz entre el sistema heredado y el de destino?

Utilizamos un contrato de interfaz para definir lo que envía el solicitante, lo que hace la plataforma documental con ello y lo que recibe el solicitante a cambio. De este modo, convertimos una dependencia no documentada en algo que podemos probar.

Incluye:

• Aplicación de origen y propietario.
• Método de invocación.
• Formato de la carga útil.
• Campos obligatorios y opcionales.
• Codificación.
• Reglas de denominación de archivos o recursos.
• Parámetros.
• Seguridad.
• Códigos de retorno/estado.
• Comportamiento de reintentos y repeticiones.
• Programación.
• Registro e identificadores de seguimiento.

Si alguno de estos comportamientos cambia de forma intencionada, recomendamos que el responsable de la aplicación apruebe la diferencia antes de la transición.

¿Dónde suele encontrarse la lógica de negocio oculta de un documento?

Según nuestra experiencia, la lógica de negocio puede encontrarse en la plantilla, el código de preprocesamiento, la aplicación host, los scripts, las tablas de enrutamiento, las reglas de extracción de datos o la configuración de la impresora. Por lo tanto, migrar únicamente la plantilla visible puede preservar la apariencia al tiempo que se modifica el resultado empresarial.

Buscamos la lógica que controla:

• Cálculos.
• Párrafos condicionales.
• Selección de idioma.
• La selección de la entidad jurídica.
• Variantes de producto.
• Supresión de páginas.
• Enrutamiento de impresión.
• Clasificación de archivos.
• Selección de destinatarios o canales.

Una pregunta útil que utilizamos es: «¿Qué hace que este documento se comporte de forma diferente?».

Cada respuesta debería apuntar al componente que implementa ese comportamiento y a una prueba de regresión que demuestre que sigue funcionando.

¿Cómo se migran las plantillas, las fuentes, AFP/PCL y las dependencias de impresora?

En DocPath, consideramos que las características de las que dependen los dispositivos y procesos posteriores son requisitos de producción, no meros detalles estéticos. Por lo tanto, las plantillas, las fuentes, el comportamiento de AFP/PCL, los códigos de barras, la paginación y los controles de impresión deben validarse independientemente de si un PDF se ve correctamente en pantalla.

IBM describe AFP como una arquitectura capaz de utilizar fuentes, superposiciones, segmentos de página, definiciones de formularios y definiciones de página.

HP describe PCL como una familia de lenguajes de comandos de impresora, lo que refuerza la idea de que el propio flujo de salida puede afectar al comportamiento de la impresora.

En nuestro caso práctico de 2026 Reliable Parts, la migración abarcó aproximadamente 500 impresoras en sus operaciones de EE. UU. y Canadá, al tiempo que se mantenía el flujo de documentos de AS400 en las fases previas. (https://global.docpath.com/en/blog/how-reliable-parts-replaced-jetform-with-a-cloud-ready-document-solution-on-aws)

¿Cómo deben migrarse las plantillas, las fuentes y los recursos compartidos?

Convertimos las plantillas como activos de producción estructurados, en lugar de tratar los resultados heredados como capturas de pantalla que hay que reproducir. Las fuentes, los fragmentos reutilizables, los logotipos, las superposiciones y los códigos de barras deben seguir siendo identificables y comprobables, ya que las sustituciones pueden alterar la paginación y el resultado físico.

Para cada familia de plantillas, recomendamos:

1. Asignar las estructuras heredadas a las estructuras de destino.
2. Separar la conversión automatizada de la corrección manual.
3. Identificar los recursos compartidos.
4. Registrar los archivos de fuentes y sus versiones.
5. Verificar las licencias y la incrustación de las fuentes.
6. Validar logotipos, firmas y superposiciones.
7. Comprobación de códigos de barras.
8. Comprobación del español, el portugués y otras variantes lingüísticas requeridas.

También podemos aprovechar la migración como una oportunidad para reducir duplicaciones innecesarias, pero la consolidación no debe eliminar diferencias legítimas, como cláusulas específicas de cada país o la lógica de enrutamiento.

¿Cómo deben validarse los formatos AFP y PCL, las colas de impresión y la salida física?

Recomendamos validar la migración de AFP y PCL tanto a nivel del flujo generado como en dispositivos de producción representativos. Las pruebas deben abarcar los comportamientos que realmente importan para las operaciones de impresión.

Cuando los equipos posteriores incluyan insertadoras, clasificadoras o escáneres, recomendamos probar también esos procesos.

¿Cómo se demuestra la equivalencia de los resultados con las pruebas de regresión?

Utilizamos pruebas de regresión para demostrar que el documento de destino conserva el significado requerido y el comportamiento posterior. La comparación visual por sí sola no es suficiente, ya que un documento puede parecer correcto aunque contenga valores erróneos, contenido condicional incorrecto, metadatos dañados o controles de impresión incompatibles.

Recomendamos definir la equivalencia antes de comenzar las pruebas. Para una familia de documentos, puede ser necesario un diseño exacto. Para otra, puede ser aceptable un rediseño aprobado si el significado empresarial, las reglas, los resultados y las obligaciones de cumplimiento siguen siendo correctos.

Recomendamos conservar la evidencia que respalda el resultado de «aprobado» o «suspendido». Esto permite rastrear las excepciones y ofrece a los responsables de negocio algo concreto que aprobar.

¿Qué debe incluir un conjunto de datos de regresión de referencia?

Creamos conjuntos de datos de referencia para poner a prueba todas las ramificaciones significativas del comportamiento de los documentos, en lugar de limitar la reproducción a transacciones medias. El objetivo es incluir los casos con mayor probabilidad de poner de manifiesto diferencias.

Recomendamos incluir:

• Valores mínimos y máximos.
• Campos opcionales vacíos.
• Una o varias partidas.
• Nombres y direcciones largos.
• Contenido en español y portugués.
• Caracteres especiales.
• Variantes de país y de entidad jurídica.
• Documentos de varias páginas.
• Cláusulas condicionales.
• Mensajes de excepción.
• Códigos de barras.
• Lotes de gran volumen.
• Reimpresiones y casos de repetición.

Cada regla de material debería corresponderse con al menos un caso de prueba conocido. De lo contrario, una ejecución de regresión satisfactoria podría significar simplemente que la regla nunca se ha puesto a prueba.

¿Qué debería comprobar realmente la comparación automatizada de resultados?

Utilizamos varias capas de comparación porque ninguna diferencia por sí sola puede demostrar la equivalencia. Las comprobaciones automatizadas deben centrarse en las áreas en las que las máquinas pueden identificar de forma consistente diferencias significativas y, a continuación, derivar las excepciones para su revisión humana.

Entre las comprobaciones útiles se incluyen:

• Comparación de campos y valores.
• Texto extraído.
• Cálculos.
• Contenido condicional.
• Recuento de páginas.
• Diferencias visuales o de coordenadas.
• Uso de fuentes y recursos.
• Códigos de barras.
• Validez de AFP/PCL.
• Metadatos de archivo.
• Validación de la accesibilidad.
• Recuento de documentos por lotes.

La automatización identifica la diferencia. A continuación, colaboramos con los responsables técnicos y de negocio para determinar si se trata de un defecto, un cambio de modernización aprobado o una variación de representación aceptable.

¿Cómo deberían funcionar la producción paralela, la transición y la reversión?

Utilizamos la producción en paralelo como puente entre las pruebas controladas y la migración completa. Las cargas de trabajo críticas deben generarse a través de ambos sistemas, conciliarse y trasladarse únicamente cuando se cumplan los criterios de aceptación predefinidos y aún sea posible revertir el enrutamiento.

En análisis de interrupciones de servicio de 2025 del Uptime Institute, el 54 % de los encuestados afirmó que su interrupción más reciente, ya fuera significativa, grave o severa, les costó más de 100 000 dólares.

No se trata de un punto de referencia para la migración de documentos, pero ilustra por qué preferimos controles de producción explícitos y procedimientos de contingencia.

Antes de que comience una fase, recomendamos acordar:

• Ventana de cambios.
• Cambios en el enrutamiento.
• Comprobaciones de validación.
• Umbrales de supervisión.
• Autoridad para dar luz verde o rechazar.
• Desencadenantes de reversión.
• Procedimientos de recuperación y repetición.
• Criterios de estabilización.

Consideramos la transición como un procedimiento operativo, no simplemente como una fecha en el calendario del proyecto.

¿Cómo se debe llevar a cabo la producción en paralelo de forma segura?

Durante una ejecución en paralelo, podemos procesar las entradas de producción a través de ambos sistemas, al tiempo que permitimos que solo la ruta de producción aprobada distribuya los resultados destinados a los clientes. Esto nos permite comparar el comportamiento real sin enviar comunicaciones duplicadas.

Un patrón sencillo es:

Datos de producción → Generación en el sistema heredado → Entrega aprobada

Datos de producción → Generación en el sistema de destino → Resultados de comparación aislados

Resultados heredados + de destino → Conciliación → Aprobación

Comparamos el recuento de documentos, los valores empresariales, el número de páginas, los errores, los eventos de archivo, los resultados de impresión y el comportamiento de reimpresión.

Recomendamos determinar el periodo paralelo basándonos en el ciclo operativo real del documento. Es posible que sea necesario observar situaciones como el cierre de mes, las renovaciones, la facturación o situaciones específicas de cada país antes de considerar que la carga de trabajo es estable.

Antes de programar la coexistencia o la transición, ponte en contacto con nosotros para revisar la arquitectura de migración.

¿Qué hace que un plan de reversión sea ejecutable en lugar de teórico?

Desde nuestro punto de vista, un plan de reversión solo es viable cuando se puede restablecer realmente el enrutamiento, se puede conciliar el trabajo en cola y se pueden evitar las comunicaciones duplicadas o perdidas. El equipo debe conocer el desencadenante, la persona responsable de la decisión, el cambio técnico y la secuencia de recuperación antes de que comience la transición.

Recomendamos que un manual de procedimientos de reversión práctico defina:

1. Quién puede activar la reversión.
2. Qué condiciones lo justifican.
3. Si el entorno heredado está listo para reanudarse.
4. Cómo se restablece el enrutamiento.
5. Qué ocurre con los trabajos ya procesados por el destino.
6. Qué entradas se pueden reproducir de forma segura.
7. Cómo se evitan los duplicados.
8. Cómo se concilian los registros de archivo.
9. Cómo se verifica que la recuperación se ha realizado correctamente.
10. Qué pruebas se conservan posteriormente.

Siempre que sea posible, recomendamos ensayar la reversión. Un plan que dependa de credenciales, colas o enrutamientos no probados aún no es un plan de contingencia ejecutable.

¿En qué momento deben incorporarse la accesibilidad y el cumplimiento normativo al plan de migración?

En DocPath, recomendamos definir los requisitos de accesibilidad y cumplimiento normativo durante el diseño de la plantilla de destino e incluirlos en los criterios de aceptación de las pruebas de regresión. Una migración es una oportunidad práctica para mejorar la estructura de los documentos mientras ya se están revisando las plantillas y la lógica de representación.

En 2024, la Organización Mundial de la Salud informó de que más de 1.300 millones de personas en todo el mundo viven con algún tipo de discapacidad, lo que representa aproximadamente el 16 % de la población mundial.

En 2025, el análisis automatizado de WebAIM de un millón de páginas de inicio con mucho tráfico detectó incumplimientos de las WCAG en el 94,8 % de ellas.

Esa cifra se refiere a páginas web y no a archivos PDF, por lo que no la consideramos una tasa de accesibilidad de los PDF.

Ofrecemosfunciones para crear archivos PDF accesibles según las P dentro de nuestra plataforma de documentos.

¿Cómo deben comprobarse los requisitos de accesibilidad de los PDF durante la migración?

Si se requiere un PDF accesible, recomendamos definir la norma aplicable y el proceso de validación antes de rediseñar las plantillas. La validación automatizada puede identificar defectos técnicos, aunque puede seguir siendo necesaria una revisión humana para comprobar el orden de lectura, el significado semántico, el texto alternativo y el uso de tecnologías de apoyo.

La norma ISO 14289-2:2024 define los requisitos para la creación de documentos PDF 2.0 accesibles y se conoce comúnmente como PDF/UA-2.

WCAG 2.2 es una Recomendación del W3C sobre la accesibilidad de los contenidos web.

No presentamos PDF/UA y WCAG como normas intercambiables.

Recomendamos realizar pruebas, cuando sea aplicable:

• Estructura etiquetada.
• Orden de lectura.
• Encabezados, listas y tablas.
• Texto alternativo.
• Idioma del documento.
• Semántica de enlaces y formularios.
• Texto buscable.
• Validación automática.
• Revisión humana.
• Comportamiento de las tecnologías de apoyo.

La Ley Europea de Accesibilidad entró en vigor el 28 de junio de 2025 para los productos y servicios incluidos en su ámbito de aplicación.

Para las organizaciones latinoamericanas, recomendamos evaluar los requisitos de la UE únicamente en aquellos casos en que los mercados, los servicios, los contratos o las entidades jurídicas generen obligaciones pertinentes.

¿Cómo deben abordarse los requisitos de cumplimiento en Latinoamérica?

Consideramos a Latinoamérica como un conjunto de jurisdicciones, en lugar de un único régimen de cumplimiento. Los requisitos de conservación, privacidad, accesibilidad, facturación electrónica, divulgación, firma y entrega deben clasificarse por país y tipo de documento.

Recomendamos utilizar una matriz como la siguiente:

Nuestro objetivo no es crear una única «configuración de cumplimiento normativo para Latinoamérica». Se trata de vincular cada requisito a una fuente fidedigna, una plantilla, una norma, un caso de prueba y una aprobación.

¿Qué errores de migración provocan interrupciones evitables en el negocio?

Según nuestra experiencia, la mayoría de los fallos evitables en la migración comienzan antes del cambio de sistema. Los equipos subestiman el entorno, migran solo plantillas, pasan por alto reglas ocultas o descubren demasiado tarde que, en realidad, no es posible revertir el proceso.

En el análisis de 2025 del Uptime Institute, casi el 40 % de las organizaciones informaron de una interrupción grave causada por un error humano durante los tres años anteriores, y el 85 % de esos incidentes se debieron a que el personal no siguió los procedimientos o a fallos en los propios procedimientos.

Esas cifras abarcan la infraestructura digital en general, pero refuerzan la razón por la que hacemos hincapié en contar con manuales de migración claros y procedimientos ensayados.

Otro riesgo al que prestamos atención es el de combinar demasiados cambios en un mismo evento de producción. Una migración también puede incluir rediseños, nuevas API, infraestructura en la nube, mejoras de accesibilidad, cambios en los archivos y nuevos canales de distribución. Cuando el riesgo es elevado, recomendamos secuenciar esas mejoras en lugar de activarlas todas a la vez.

¿Cuándo es seguro retirar el sistema heredado?

Consideramos la retirada del servicio como una etapa formal de la migración, no como una tarea administrativa de limpieza. El entorno heredado debe permanecer disponible hasta que se hayan trasladado las cargas de trabajo aprobadas, se hayan retirado los requisitos de reversión, los archivos estén funcionando y la supervisión indique que no quedan dependencias de producción.

Antes del apagado, recomendamos confirmar:

Producción

• Las fases de migración han sido dadas por concluidas.
• Los ciclos de los documentos críticos se han completado con éxito.
• Las excepciones y las colas están estables.
• Se han resuelto las discrepancias paralelas.

Aplicaciones e interfaces

• No aparecen en los registros llamadas heredadas pendientes.
• Se han comprobado los trabajos programados y los que se utilizan con poca frecuencia.
• Se han cubierto las rutas manuales y de emergencia.

Documentos y recursos

• Se han aprobado las plantillas necesarias.
• Los proyectos de origen heredados se conservan cuando es necesario.
• Se han documentado las reglas de negocio y los recursos.

Archivos y registros

• El contenido histórico sigue siendo recuperable.
• Los nuevos resultados se envían al archivo correcto.
• Se dispone de los metadatos necesarios.
• Se han revisado los requisitos de conservación.

Operaciones y seguridad

• La supervisión de objetivos está operativa.
• Los manuales de procedimientos están completos.
• Se ha establecido la responsabilidad del soporte técnico.
• Las cuentas e infraestructuras heredadas pueden retirarse mediante los procesos habituales de seguridad y gestión de activos.

Recomendamos dejar que sean los datos los que determinen la fecha de cierre, en lugar de basarse únicamente en el calendario del proyecto.

Nuestrosservicios profesionales de « » incluyen consultoría, diseño inteligente de formularios, formación, generación de documentos SaaS y soporte técnico. (https://docpath.com/services/)

¿Cómo puede DocPath apoyar una migración de sistemas heredados que priorice la continuidad?

Para los entornos heredados compatibles, nuestro objetivo es modernizar la producción de documentos minimizando al mismo tiempo los cambios innecesarios en las aplicaciones y los procesos operativos relacionados. Combinamos capacidades de migración con integración empresarial, generación de documentos, salida física y digital, y servicios técnicos.

Nuestra cartera actual de migración incluye:

• JetForm/Adobe Central, que incluye escenarios compatibles capaces de procesar datos de entrada existentes.
• InfoPrint Designer/AFP Utilities, que incluye compatibilidad con IBM i y formatos de salida como PDF, HTML5, PCL y etiquetas.
• Control-D, con una ruta de modernización para la gestión de informes y salidas.

Nuestraarquitectura de integración « » también incluye conectividad con IBM z/OS e IBM i, además de con sistemas ERP, CRM, bancarios y de seguros.

Dos de nuestros casos de clientes ilustran el principio de continuidad. En nuestrocaso de con Fifth Third Bank, describimos la sustitución de un ejecutable JetForm heredado, permitiendo al mismo tiempo que las aplicaciones existentes continuaran funcionando sin modificaciones.

En nuestrocaso práctico de con BBVA, informamos de que los formularios existentes se convirtieron automáticamente sin necesidad de cambios en las aplicaciones y que la implementación era compatible con la salida AFP.

Para nosotros, la pregunta clave sobre la migración no es simplemente: «¿Podemos convertir estas plantillas?».

Sino:

«¿Podemos sustituir la plataforma de generación de documentos y, al mismo tiempo, garantizar que las aplicaciones, las fuentes de datos, las reglas, las salidas, las impresoras, los archivos y los procesos operativos relacionados sigan funcionando según lo previsto?».

Ese es el criterio que recomendamos utilizar para planificar la migración.

¿Está planificando el cambio desde un entorno heredado de generación de documentos o de gestión de comunicaciones con el cliente (CCM)? Póngase en contacto con nosotros para revisar sus plantillas, interfaces, flujos de datos, salidas y requisitos de continuidad.

Preguntas frecuentes

¿Qué es la migración de un sistema de documentos heredado?

Definimos la migración de un sistema de gestión documental heredado como la sustitución controlada del software que compone, genera, imprime, distribuye o archiva documentos empresariales, conservando al mismo tiempo las plantillas, los datos, las reglas, las interfaces y los procesos posteriores de los que depende la producción.

Se diferencia de la migración de repositorios porque el principal objeto de la modernización es un proceso activo de producción de documentos, y no solo los archivos almacenados.

¿Se puede migrar un sistema de gestión documental heredado sin modificar las aplicaciones que lo invocan?

A veces. Si la plataforma de destino puede conservar el contrato de interfaz heredado y utilizar los mismos datos de entrada o parámetros, es posible que no sea necesario modificar las aplicaciones de origen.

Documentamos este enfoque para determinadas migraciones compatibles con JetForm/Adobe Central.

¿Cómo se comprueba si el nuevo sistema genera los mismos documentos?

Recomendamos comprobar la equivalencia en cuanto a datos, reglas de negocio, texto, maquetación, paginación, recursos, formato de salida, comportamiento de la impresora, archivos y accesibilidad, cuando proceda.

Definimos las diferencias aceptables antes de realizar las pruebas, de modo que el resultado sea una decisión de aceptación cuantificable, en lugar de una revisión visual subjetiva.

¿Deben funcionar en paralelo el sistema de documentos antiguo y el nuevo?

A menudo recomendamos el funcionamiento en paralelo para cargas de trabajo críticas para el negocio cuando esto proporciona pruebas útiles de que el sistema de destino se comporta correctamente en condiciones de producción representativas.

Un modelo habitual consiste en generar documentos en ambos entornos, aunque solo la ruta de producción aprobada distribuya los documentos destinados a los clientes.

¿Cómo se migra la producción de documentos AFP o PCL?

Tratamos AFP y PCL como interfaces de producción, en lugar de simples formatos de exportación. Validamos el flujo generado, las fuentes y los recursos, la paginación, los códigos de barras, las bandejas, el comportamiento en dúplex, el acabado, las colas y las impresoras físicas representativas.

IBM describe el procesamiento de AFP como dependiente de recursos que incluyen fuentes, superposiciones, segmentos de página, definiciones de formularios y definiciones de página.

¿Es necesario trasladar los archivos históricos durante la migración de la generación de documentos?

No necesariamente. A menudo podemos dejar el contenido histórico en su repositorio actual si se siguen cumpliendo los requisitos de recuperación, seguridad, conservación y auditoría.

Si los documentos históricos también deben trasladarse, recomendamos gestionar la migración del archivo como un flujo de trabajo independiente con sus propias pruebas de integridad, metadatos y recuperación.

¿Debería incorporarse la accesibilidad durante la migración de documentos heredados?

Sí, cuando la organización, sus clientes, los contratos, los mercados o la normativa aplicable exijan una salida accesible. Consideramos que la migración de plantillas es un momento oportuno para introducir requisitos de accesibilidad en los documentos, ya que la estructura de destino y la lógica de representación ya se están revisando.

La norma ISO 14289-2:2024 define los requisitos para los documentos PDF 2.0 accesibles.