¿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).
Nuestros DBF son un caos (codepages, indicador "Deleted", memos)...
Es lo habitual. Nuestro proceso incluye una auditoría de datos en profundidad. Sabemos migrar campos `Memo`, tratar correctamente las `codepages` (juegos de caracteres como Windows-1252) y preservar la semántica del comando `SET DELETED`. Limpiamos estructuras heredadas y las llevamos a un esquema SQL relacional limpio, con manejo correcto de `NULL` en lugar de cadenas vacías. Eso también resuelve problemas históricos de `codepage` y habilita un soporte real de `UTF-8`, por ejemplo para alemán o chino. Del mismo modo, conocemos los problemas típicos de las integraciones `ODBC`, como los relacionados con `varchar(max)`, y los resolvemos durante la refactorización del modelo de datos.
¿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 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.
Nuestra aplicación usa un framework VFP (Acodey, Visual Extend). ¿Supone un problema?
Al contrario: es una ventaja. Conocemos bien esas arquitecturas. Nuestra experiencia cubre explícitamente migraciones de aplicaciones basadas en frameworks VFP consolidados como Visual Extend (VFX) o bibliotecas de componentes como Acodey (de ProLib). Entendemos cómo funcionan, incluidas sus partes "mágicas", y podemos trasladar esa lógica específica a estructuras modernas e independientes del framework.
¿Qué pasa con particularidades de VFP como `SET ANSI`/`EXACT`?
Estos comandos cambian de forma fundamental la manera en que VFP compara datos, por ejemplo `SET EXACT` en comparaciones de cadenas. Conocemos esa semántica en detalle. Durante la auditoría, identificamos esos comandos `SET` y preservamos su comportamiento mediante pruebas `Golden Master`, es decir, casos automatizados que validan el comportamiento legacy 1:1 para que el nuevo sistema siga siendo funcionalmente idéntico.
Nuestra aplicación usa el "buffering optimista" de VFP. ¿Cómo se resuelve en web?
Es una pregunta excelente y uno de los desafíos centrales en las migraciones web. La gestión de conflictos de `TABLEUPDATE()` en VFP, cuando otro usuario ya ha modificado un registro, debe modelarse explícitamente en el nuevo sistema. En la web, esto suele resolverse con control de concurrencia: al cargar, el registro recibe un token invisible (ETag). Al guardar, el servidor comprueba si el token sigue coincidiendo. Si no coincide, porque otro usuario guardó antes, se bloquea la operación y se informa al usuario. Así se crea un proceso seguro y transparente para evitar conflictos de datos.
¿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.
Usamos herramientas como `xCase`, `Stonefield Query` o `FoxBarcode`. ¿Les resultan familiares?
Sí, por completo. Conocemos a fondo el ecosistema VFP. Los modelos de base de datos de `xCase` son una fuente muy valiosa para la ingeniería inversa. Estamos familiarizados con herramientas de reporting como `Stonefield Query`, generadores de códigos de barras como `FoxBarcode` y estrategias para DBF cifrados con `Cryptor`. También conocemos los controles ActiveX habituales de proveedores como `DBITech` o `Codejock`, así como sus alternativas web actuales.
¿Y nuestra automatización de Office (Word/Excel)?
Es un tema muy habitual. La automatización de Office desde VFP es lenta y exige que Office esté instalado. Migramos esa lógica a soluciones de alto rendimiento en el servidor, por ejemplo bibliotecas .NET, que generan archivos Word o Excel *sin* requerir Office en el servidor ni en el cliente. Para análisis y reporting, a menudo conectamos herramientas de autoservicio como PowerBI directamente a la nueva base de datos.
¿Qué ocurre con la protección de datos (RGPD) y la responsabilidad?
Lo tratamos con toda seriedad. La soberanía de los datos sigue estando por completo en sus manos. Usted decide si la nueva solución se ejecuta on-premise o en la nube, incluida la región que prefiera, por ejemplo Fráncfort. Asesoramos de forma conforme al RGPD, anonimizamos datos de prueba y, si se requiere, apoyamos la implantación de exigencias de cumplimiento como audit logs, KYC o AML. Y estamos cubiertos: con Hiscox SA mantenemos un seguro de responsabilidad civil profesional (errors & omissions) junto con un seguro de responsabilidad civil de explotación. La cobertura de responsabilidad profesional responde justamente al tipo de riesgo que implica una migración de datos.
¿Cómo garantizan el rendimiento en web? VFP es muy rápido en local.
Es una preocupación totalmente legítima. La diferencia entre DBF locales y la latencia web es real. Abordamos el rendimiento mediante (1) una arquitectura API limpia en lugar de acceso directo a base de datos, (2) un uso inteligente de caché para datos maestros y (3) la optimización de consultas e índices. Junto con usted definimos objetivos de rendimiento (KPI) para las pantallas y procesos más críticos.