Una aplicación escrita hace décadas en Visual Basic 6, FoxPro, Delphi o COBOL sigue funcionando, y por eso nadie la toca. El riesgo no es el lenguaje: es que las reglas de su negocio viven dentro, que quizá nadie las tenga por escrito y que el equipo que la hizo ya no está.
Una aplicación escrita hace décadas en Visual Basic 6, FoxPro, Delphi o COBOL sigue funcionando, y por eso nadie la toca. El riesgo no es el lenguaje: es que las reglas de su negocio viven dentro, que quizá nadie las tenga por escrito y que el equipo que la hizo ya no está. Esta página explica cómo se aborda, sea cual sea el lenguaje.
Para empezar basta con describir qué hace la aplicación. No envíe credenciales ni bases de datos.
Solicite su diagnóstico Proportione Legacy
Cada lenguaje tiene su sección, con sus propias preguntas:
Una aplicación de este tipo mezcla cuatro cosas: los datos, las pantallas con las que se trabaja, los informes y las reglas que deciden qué ocurre en cada caso (cómo se calcula, qué se valida, quién puede hacer qué). El lenguaje es solo el envoltorio de las cuatro. Cambiarlo sin saber qué reglas contiene es la forma más habitual de que algo deje de funcionar sin que nadie lo note hasta tarde.
Por eso la primera pregunta no es «¿a qué lenguaje lo paso?», sino «¿qué hace realmente?». Empezamos por un diagnóstico de sus datos y procesos antes de elegir destino. Entrega un inventario de procesos y datos, las opciones (construir, comprar o conectar) y una propuesta de alcance por fases.
Las fechas de fin de soporte son las que publica cada fabricante, no las nuestras:
Qué significa para usted: una aplicación sin soporte del fabricante no deja de funcionar de un día para otro, pero cada cambio en el sistema que la rodea la deja más aislada. Siguiente paso: elegir la sección de abajo que se parece a su caso.
Una aplicación en Visual Basic 6 suele ser una aplicación de escritorio para Windows: formularios, informes, una base de datos detrás y componentes de terceros instalados en cada equipo. Migrarla es decidir qué hacer con cada pieza, no traducir línea a línea.
1. Una aplicación web. Se usa desde el navegador, sin instalar nada en cada equipo. 2. Una aplicación de escritorio actual. Cuando el trabajo exige estar en el equipo, por ejemplo por un dispositivo conectado. 3. Conectarla. La aplicación se queda como está y se abre con APIs y conectores para que el resto de sus sistemas la use.
El diagnóstico compara las tres con los datos de su caso. No hay un destino mejor en abstracto.
Se empieza por ver qué hay: ejecutable, datos, documentación, personas que la usan. Hasta que se mira, no se sabe qué se puede recuperar y qué no. La extracción solo se hace con la autorización del titular del sistema, y lo que no pueda recuperarse se dice por escrito antes de seguir.
No. Se entrega por fases, con criterios de aceptación y plan de vuelta atrás, para que cada paso se pueda comprobar y, si hace falta, deshacer. Cómo se organiza el cambio de cada fase se define en la propuesta.
Se inventarían. De cada uno se decide, por separado, si se conserva, se sustituye o se retira, y queda por escrito en la propuesta de alcance.
FoxPro y Delphi suelen aparecer en aplicaciones de gestión hechas a medida hace muchos años: una base de datos propia, formularios para introducir y consultar, informes. La pregunta que se hace casi todo el mundo es la misma: ¿lo rehago o lo dejo como está?
La respuesta no depende del lenguaje, sino de lo que la aplicación hace hoy por usted y de lo que necesita que haga mañana. Describimos el método, que es el mismo para cualquier lenguaje.
Abrirla con APIs y conectores permite que otros sistemas lean y escriban en ella sin rehacerla.
En ese caso se reescribe por fases: primero las piezas que más pesan, con criterios de aceptación fijados de antemano.
Qué significa para usted: reescribir y conectar no se excluyen: puede conectar hoy lo que funciona y reescribir mañana lo que no. Siguiente paso: pedir el diagnóstico, que compara las opciones con sus datos.
Los datos se inventarían antes de decidir nada: qué tablas hay, cuáles se usan y en qué estado están. Se decide qué se lleva al destino, qué se archiva y qué se retira, y se comprueba después.
Depende de la versión que tenga instalada y de la política de su fabricante. No damos una fecha: lo que sí hacemos en el diagnóstico es anotar con qué versión y con qué componentes está construida su aplicación.
Depende de cómo esté hecha. A veces se puede abrir por la base de datos o por ficheros de intercambio; otras hay que añadir una capa nueva. El diagnóstico lo aclara antes de comprometer ningún trabajo.
Un sistema en COBOL suele ser un sistema de gestión que lleva décadas haciendo lo mismo: procesos por lotes, ficheros maestros, cálculos que nadie ha vuelto a revisar y que sostienen una parte de la operación. Lo que más pesa en estos sistemas no es el lenguaje, sino saber qué hay dentro.
La pregunta útil es qué se conserva. Qué se conserva y qué no se decide pieza a pieza:
La extracción de reglas y datos se hace siempre con la autorización del titular del sistema. Si no hay documentación, el inventario es el primer entregable del diagnóstico.
Qué significa para usted: sabe qué reglas y qué datos tiene, y qué se conserva de cada uno, antes de comprometer un cambio. Siguiente paso: describirnos el caso en el formulario.
Las dos son opciones. Si el sistema hace bien su trabajo, conectarlo con APIs y conectores suele ser la primera a valorar. Si cada cambio es una operación de riesgo, se sustituye por piezas. El diagnóstico compara ambas con su caso.
Los criterios de aceptación se fijan de antemano, a partir de las reglas inventariadas: se comparan resultados de la aplicación nueva con los de la antigua sobre los mismos casos. Lo que se decide cambiar queda por escrito.
Sea cual sea el lenguaje, el método es el mismo. Los detalles generales están en cómo trabajamos.
1. Diagnóstico: inventario de procesos y datos, reglas de negocio, opciones (construir, comprar o conectar) y propuesta de alcance por fases. 2. Piloto acotado, con criterios de aceptación fijados de antemano, antes de seguir, cuando el caso lo pide. 3. Entrega por fases, con criterios de aceptación y plan de vuelta atrás. 4. Traspaso: documentación, exportación y custodia comprobables. El código es suyo, y así queda en el contrato.
Qué significa para usted: en cada momento sabe qué se ha entregado, qué falta y cómo se vuelve atrás. Siguiente paso: pedir el diagnóstico.
El orden es siempre el mismo: primero se digitaliza y se entiende el proceso; después se abre el software antiguo con APIs y conectores para unirlo con el resto, y solo entonces se plantea la IA encima. Planteamos la IA después, cuando el proceso está entendido y los datos ordenados.
La IA puede ejecutarse en su propio servidor y, si hace falta, sin conexión a Internet. Es la misma opción que describimos en migración de sistemas legacy y en inteligencia artificial en la empresa.
Si lo que busca es una aplicación nueva a medida y no la migración de una existente, vea desarrollo de software a medida. Si su aplicación es solo una de varias piezas antiguas, vea el conjunto en consultoría de gestión de negocio y nuestros servicios.
Si lo que tiene son macros de Excel o una aplicación Access, tienen su propia página de migración de aplicaciones Access. Si es una aplicación web en PHP o sobre un framework sin soporte, su caso está en migrar PHP 5 a PHP 8 o salir de un framework sin soporte.
Qué significa para usted: sus datos no tienen por qué salir de sus instalaciones. Siguiente paso: pedir el diagnóstico.
Por un diagnóstico de sus datos y procesos, antes de elegir destino. Entrega un inventario de procesos y datos, las opciones (construir, comprar o conectar) y una propuesta de alcance por fases.
No necesariamente. Una de las tres opciones del diagnóstico es conectar: abrir la aplicación que ya tiene con APIs y conectores y unirla con el resto, sin sustituirla. Qué se reescribe y qué se conserva se decide pieza a pieza.
Depende del alcance: cuántas pantallas, informes, reglas y datos hay, y qué tiene que hacer después. Por eso no damos una cifra ni un plazo sin conocer su caso. La propuesta de alcance por fases, con la que termina el diagnóstico, es el punto donde se concreta.
Qué se conserva, qué se cambia y qué se retira se decide pieza a pieza y queda por escrito. Cada fase se entrega con criterios de aceptación fijados de antemano y con un plan de vuelta atrás, para poder comprobarla y, si hace falta, deshacerla.
Sí. La extracción, la migración y la IA que se use después pueden ejecutarse en sus servidores o en hardware dedicado, incluso en una red sin conexión a Internet.
El código es del cliente, y así queda en el contrato. La documentación, la exportación y la custodia son comprobables y forman parte del diseño.
Cuéntenos en qué lenguaje está su aplicación y qué papel juega hoy. Le respondemos en un máximo de dos días laborables. [Formulario corto: ver especificación en notas] Si prefiere escribirnos directamente: contacto.
Solicite su diagnóstico Proportione LegacyNo envíe credenciales ni bases de datos. Usaremos sus datos solo para responderle; más información en la política de privacidad.
