Resumen rápido: La migración de Xerox VIPP a la generación moderna de documentos implica sustituir la lógica PostScript integrada en la impresora por una plataforma que lee directamente los mismos datos heredados y genera resultados para todos los canales que utiliza una empresa en la actualidad, no solo la impresión.
Para las empresas que aún utilizan el software Variable data Intelligent PostScript Printware (VIPP), este sigue funcionando, y esa es precisamente la razón por la que aún no se ha sustituido. En esta entrada se explica qué es VIPP, por qué una arquitectura centrada en la impresión acaba llegando a un punto muerto, en qué consiste en la práctica una migración con DocPath, qué posibilidades se abren una vez que los documentos ya no están vinculados a una impresora y las normas de cumplimiento que se aplican cuando los documentos dejan de estar en papel.
El «Variable data Intelligent PostScript Printware» (VIPP) es un sistema de producción de impresión de Xerox que ensambla cada documento en la propia impresora, utilizando macros PostScript almacenadas en el dispositivo en lugar de compuestas de forma centralizada. Xerox desarrolló VIPP a partir de un formato de flujo de impresión más antiguo denominado «Line Conditioned Data Stream» (LCDS), que reducía la carga de la red al mantener las fuentes, los formularios y las imágenes en la propia impresora y enviar únicamente los datos variables en el momento de la impresión. VIPP funciona según el mismo principio. Un archivo de plantilla conocido como «Job Descriptor Ticket» (JDT) indica a la impresora cómo fusionar esos datos variables con los recursos precargados, un modelo que Xerox denomina «Dynamic Document Construction».
Empresas de los sectores de seguros, banca, logística y administración pública adoptaron VIPP porque resultaba eficiente para su finalidad original: la impresión a gran escala de extractos, facturas y documentos de pólizas de gran volumen, con un envío mínimo de datos a través de la red. Décadas más tarde, muchas de esas mismas empresas siguen utilizándolo. El software sigue generando resultados correctos, el parque de impresoras sigue funcionando y sustituir un sistema que no presenta fallos visibles resulta poco competitivo a la hora de obtener presupuesto frente a proyectos con un retorno más claro e inmediato.
Esa suele ser toda la explicación. El VIPP nunca se diseñó para ser una solución permanente, pero acabó siéndolo de todos modos porque nada impulsó el debate al respecto. Cada año que pasa sin una migración se suman más formularios, más personalizaciones específicas para cada impresora y más conocimientos institucionales que solo existen en la mente de las pocas personas que aún saben cómo editar una macro de PostScript.
Una arquitectura de «impresión primero» como el VIPP no tiene una vía nativa hacia el correo electrónico, los dispositivos móviles o la entrega digital, ya que su lógica de formato reside en la impresora en lugar de en el documento. Cada trabajo VIPP depende de un «Job Descriptor Ticket» y de recursos como formularios e imágenes que se almacenan físicamente en esa impresora concreta. Trasladar un documento a un nuevo canal implica reconstruir esa lógica en otro lugar, con soluciones provisionales una tras otra, en lugar de reutilizar lo que ya existe.
Esto se manifiesta más como una deuda técnica acumulada que como un único punto de fallo. Las fuentes, los formularios y las imágenes residen en dispositivos de impresión distribuidos, en lugar de en un repositorio central, por lo que un cambio realizado en una impresora no se aplica automáticamente en ningún otro sitio. El número de personas capaces de escribir y solucionar problemas en macros PostScript no deja de reducirse, ya que cada vez son menos los desarrolladores formados en un lenguaje con el que la mayoría del software moderno ya no interactúa directamente.
Cada nuevo requisito de distribución debe resolverse como un caso especial. Un extracto enviado por correo electrónico, una notificación de WhatsApp, un PDF optimizado para móviles… Ninguno de estos elementos tiene cabida de forma nativa en una arquitectura diseñada para producir una página impresa y nada más. Las soluciones provisionales se acumulan, y la propia plataforma nunca se acerca a resolver el problema subyacente.
Una migración de Xerox VIPP con DocPath comienza leyendo directamente los datos VIPP existentes, por lo que los equipos de TI no necesitan intervenir en las aplicaciones de negocio que los generan. Los motores de generación de documentos de DocPath procesan los mismos tipos de archivos que ya produce un entorno VIPP: archivos Job Descriptor Ticket (JDT), archivos de formulario (FRM), gráficos Encapsulated PostScript (EPS), registros de longitud fija y archivos de spool de mainframe formateados para Line Conditioned Data Stream (LCDS) o salida VIPP nativa. No es necesario cambiar nada en las fases previas para iniciar la migración, y se puede acceder a los datos del mainframe directamente desde la fuente, incluso a través del spool de JES, sin alterar las aplicaciones que los generan.
Una vez que esos datos llegan a DocPath, la lógica residente en la impresora en la que se basa VIPP se sustituye por una composición dinámica. En lugar de que un Job Descriptor Ticket recurra a recursos almacenados físicamente en un dispositivo, el motor DocGeneration de DocPath fusiona automáticamente los datos entrantes con plantillas preaprobadas, sin intervención manual en el momento de la impresión. Esas plantillas se crean y gestionan en un entorno de diseño visual sin código, en lugar de escribirse como macros PostScript, e incorporan control de versiones y reglas de representación condicional, de modo que un formulario puede comportarse de forma diferente en función de los datos que reciba sin que un desarrollador tenga que reescribir nada.
La plataforma funciona en entornos Windows, Linux e IBM i, tanto en las propias instalaciones como en la nube, y se conecta a los sistemas existentes a través de API REST (Representational State Transfer) o conectores ejecutables. Esto significa que una aplicación desarrollada en torno a un host AS/400 o mainframe puede seguir enviando los mismos datos de siempre, mientras que la salida pasa a PDF, PostScript, Printer Command Language (PCL) y otros formatos que una operación moderna realmente necesita. El motor en sí está diseñado para grandes volúmenes, capaz de generar decenas o cientos de miles de documentos por hora mediante el equilibrio de carga, por lo que migrar desde VIPP no implica sacrificar el rendimiento a cambio de flexibilidad.
Una vez que los documentos se procesan en DocPath en lugar de en VIPP, la misma plantilla puede llegar al cliente por correo electrónico, WhatsApp, monedero digital o en formato impreso, en lugar de estar limitada al canal para el que se diseñó la impresora. Esa flexibilidad se debe a la separación de la lógica del documento de cualquier dispositivo de salida concreto, algo que la arquitectura de VIPP, basada en la impresora, nunca permitió. Un extracto que antes solo existía como página impresa ahora puede personalizarse, generarse y enviarse a través del canal que el destinatario utilice realmente.
La distribución también puede tener validez legal cuando sea necesario. DocPath admite el envío certificado por correo electrónico con acuse de recibo, lo cual es importante para extractos, notificaciones y cualquier documento cuya entrega una empresa necesite demostrar. Cada documento generado de esta forma se archiva con un registro completo y trazable, de modo que se puede localizar y reproducir posteriormente una versión concreta enviada a un destinatario concreto en una fecha concreta, algo que un flujo de trabajo VIPP exclusivamente impreso nunca estuvo diseñado para rastrear en primer lugar.
Al dejar de limitarse a la impresión, los documentos quedan sujetos a normas de accesibilidad y firma electrónica que un flujo de trabajo VIPP exclusivamente impreso nunca tuvo que cumplir. Dos de ellas se aplican directamente a cualquier empresa que distribuya documentos a sus clientes de forma digital en la UE.
La Ley de Accesibilidad Europea (Directiva (UE) 2019/882) se aplica a los nuevos productos y servicios desde el 28 de junio de 2025, mientras que las ofertas existentes tienen de plazo hasta el 28 de junio de 2030 para cumplir plenamente con ella. Exige que los contenidos digitales, incluidos los archivos PDF como facturas, extractos y contratos, sean accesibles para las personas con discapacidad. El cumplimiento se demuestra, por lo general, mediante la norma EN 301 549, la norma europea sobre accesibilidad de las tecnologías de la información y la comunicación (TIC), que se ajusta a los criterios de las Pautas de Accesibilidad al Contenido Web (WCAG) y, en el caso específico de los documentos PDF, al etiquetado PDF/Accesibilidad Universal (PDF/UA). Un documento que solo se ha concebido para ser impreso nunca se ha creado con un árbol de etiquetas, un orden de lectura definido ni texto alternativo para las imágenes. Un documento generado para su distribución multicanal necesita estos tres elementos.
El segundo es el Reglamento eIDAS (Reglamento (UE) n.º 910/2014) sobre identificación electrónica y servicios de confianza, que otorga a la firma electrónica cualificada el mismo valor legal que a la firma manuscrita en toda la UE. Una vez que una empresa empieza a enviar contratos, autorizaciones o acuses de recibo de forma digital, en lugar de imprimirlos para que se firmen a mano, el método de firma utilizado debe cumplir esa norma para tener validez legal. La plataforma de DocPath genera archivos PDF diseñados para cumplir con las directrices de accesibilidad WCAG y admite firmas electrónicas cualificadas según eIDAS como parte del mismo proceso de generación de documentos, por lo que el cumplimiento normativo no se convierte en un proyecto independiente que se suma a la migración.
Las migraciones VIPP tienen éxito cuando la fase de inventario se lleva a cabo antes de que comience cualquier conversión, y se estancan cuando los equipos empiezan a convertir formularios antes de saber cuántos existen o qué lógica conlleva cada uno. Todos los formularios, plantillas y elementos de lógica empresarial integrada que se ejecutan en un entorno VIPP deben catalogarse primero: cuáles siguen realmente en uso, de qué datos depende cada uno y qué hay que validar una vez que se traslada a una nueva plataforma. Saltarse ese paso es la razón más común por la que el plazo de una migración se duplica a mitad del proceso.
Reliable Parts, una empresa de distribución de recambios que opera en Estados Unidos y Canadá, es un ejemplo útil de esta disciplina en la práctica, aunque su migración se llevó a cabo con JetForm en lugar de con VIPP. Su entorno de generación de documentos estaba estrechamente vinculado a un AS/400, la plataforma de servidores de gama media heredada de IBM, en la que se ejecutaba un sistema de planificación de recursos empresariales (ERP) que generaba pedidos, facturas, etiquetas de envío e informes a través de unas 500 impresoras. DocPath migró ese entorno a una configuración alojada en la nube en Amazon Web Services (AWS) procesando los mismos archivos de cola de impresión de tipo «Field Nominated File» (FNF) que el sistema AS/400 ya generaba, sin necesidad de realizar ni un solo cambio en las aplicaciones empresariales que los producían. La plataforma de origen era diferente, pero la disciplina de planificación —primero el inventario y luego la conversión— se aplica de la misma manera a un entorno VIPP.
¿Requiere la migración a Xerox VIPP reescribir nuestras aplicaciones empresariales? No. DocPath procesa los mismos formatos de datos que ya genera un entorno VIPP, incluidos los archivos Job Descriptor Ticket (JDT), los archivos de formularios y los archivos de cola de impresión del mainframe, por lo que no es necesario modificar las aplicaciones que generan esos datos.
¿Qué tipos de archivos VIPP lee DocPath de forma nativa? Los motores de DocPath procesan archivos Job Descriptor Ticket (JDT), archivos de formularios (FRM), gráficos Encapsulated PostScript (EPS), registros de longitud fija y archivos de spool de mainframe formateados para salida Line Conditioned Data Stream (LCDS) o VIPP.
¿Perdemos nuestra salida de impresión tras la migración? No. DocPath genera salidas en formato PDF, PostScript y Printer Command Language (PCL), además de los canales más recientes, por lo que la impresión sigue siendo una opción de distribución más entre otras, en lugar de la única.
¿Qué volumen puede gestionar una migración de DocPath? Las herramientas de migración de DocPath han trasladado hasta 6.000 formularios para una única aseguradora global, QBE, sin reescribir la aplicación subyacente, lo que da una idea de la escala a la que puede operar una migración VIPP.
Planificar el abandono de Xerox VIPP implica mucho más que la simple decisión de hacerlo. Es necesario realizar un inventario de los formularios, preservar la lógica de negocio de cada uno de ellos y garantizar que la transición se produzca sin interrumpir ningún proceso que dependa actualmente de esa salida de datos.
La lista de comprobación para la migración de JetForm recorre ese proceso en tres fases —antes, durante y después— y la disciplina de planificación que abarca se aplica a cualquier migración de plataformas heredadas, incluida la salida de VIPP. Se trata de un marco práctico de una sola página diseñado para que los equipos de TI lo utilicen directamente.
Descarga la lista de comprobación para la migración de JetForm