Logística y servicio de campo
Rescate de una «caja negra»
Punto de partida: FoxPro DOS (intercambio de datos mediante memorias USB), back office en VFP 6 y código fuente parcialmente perdido. Mediante decompilación e ingeniería inversa, reconstruimos la lógica de negocio y la transformamos en una solución web (Angular) y móvil (iOS/Android) moderna para 5.000 clientes finales.
Preguntas que surgen justo en este tipo de proyecto
Los siguientes puntos suelen ser decisivos en este tipo de sistema heredado, y son la razón por la que una migración rara vez fracasa por el lenguaje de programación.
¿Qué ocurre con las llamadas `DECLARE DLL`, `VFPX` o `wwipstuff`?
Es una parte central de la "arqueología". Analizamos llamadas `DECLARE DLL` crípticas para entender su función y traducirlas a equivalentes modernos en .NET o APIs. Bibliotecas como `wwipstuff` de Rick Strahl (West Wind Internet Protocols), el framework `West Wind Web Connection (WWWC)` o las numerosas extensiones `VFPX` forman parte de nuestro terreno habitual. Por ejemplo, ya hemos integrado funcionalidad .NET en sistemas VFP heredados mediante `wwDotnetBridge` y sabemos cómo migrar esa lógica de forma nativa.
¿Qué ocurre con los batch nocturnos y el uso de Terminal Server?
Ejecutar VFP sobre Terminal Server es una solución típica para darle una apariencia "web". La nueva aplicación web hace innecesario ese rodeo. Analizamos los procesos batch nocturnos y los migramos a procesos modernos del lado del servidor, como funciones serverless, jobs de contenedor tipo Kubernetes CronJobs o flujos dirigidos por API.
¿Cómo funciona técnicamente la convivencia en paralelo?
Trabajamos con el "Strangler (Fig) Pattern", es decir, con una sustitución iterativa. Es una fase delicada. En vez de optar por un arriesgado "dual-write", donde los datos se escriben en dos sistemas al mismo tiempo, preferimos mecanismos más seguros como APIs intermedias o eventos síncronos. Así, mientras el sistema antiguo siga operativo, la nueva aplicación puede informar sus datos de vuelta a la base heredada mediante una interfaz controlada. El resultado es un riesgo mucho menor de divergencia de datos y una transición más segura en producción.
¿Qué ocurre con nuestros informes FRX y controles ActiveX/OCX?
Es un punto crítico. Migramos los informes (`FRX/LBX`), que a menudo se generan mediante herramientas como `XFRX`, `FoxyPreviewer` o controladores PDF como `Amyuni`, a plataformas de reporting modernas. Recomendamos y utilizamos plataformas comerciales consolidadas, como DevExpress o Telerik, para las que disponemos de licencias y soporte completo del fabricante. Si el cliente prefiere expresamente alternativas open source, también podemos implementarlas, explicando con total transparencia los posibles compromisos, como lagunas de soporte o funcionalidades ausentes. Los controles `ActiveX/OCX` obsoletos, por ejemplo en la capa de interfaz, se sustituyen por componentes web modernos, y aprovechamos ese paso para mejorar también la UI/UX y la accesibilidad (a11y).
¿Le suena parecido a su sistema?
Dediquémosle 45 minutos. Sin compromiso, sin coste y con una valoración honesta al final, incluso si esa valoración es: de momento, mantenerlo funcionando con seguridad.
Solicitar consulta estratégica