Windows 11 ARM64 para Delphi-aplicaciones: planificar desde el inicio

Windows 11 ARM64 ya no es en el día a día B2B solo un caso excepcional para entusiastas de la tecnología. Las nuevas generaciones de portátiles, mayores autonomías de batería, escenarios “Always-on” y el creciente deseo de puestos de trabajo ligeros y móviles hacen que las empresas compren clientes ARM64: a veces de forma deliberada, otras veces de forma incidental mediante modelos estándar en contratos marco. Para equipos con software empresarial heredado es un mensaje claro: ARM64 debe incorporarse temprano en la planificación técnica, de lo contrario más adelante será un costoso proyecto de adaptación.

En aplicaciones Delphi la pregunta central rara vez es “¿puede Delphi compilarlo?”. En la práctica, los despliegues ARM64 casi siempre fracasan por la periferia: DLLs nativas, componentes de impresión/escaneo, controladores de base de datos, motores de informes, integraciones COM, rutinas de instalación, firma de código o pipelines de build que implícitamente solo conocen x64. Precisamente por eso merece la pena tratar Windows 11 ARM64 como un requisito de arquitectura y operación —no como una mera característica de plataforma.

Este artículo muestra qué obstáculos técnicos aparecen típicamente en Delphi, cómo identificar sistemáticamente los riesgos y qué caminos de migración pragmáticos han demostrado su eficacia —desde preparar progresivamente módulos individuales hasta definir una arquitectura objetivo clara con servicios y REST-servidores.

Por qué Windows 11 ARM64 es ahora un tema de arquitectura

En muchas empresas “Windows” durante mucho tiempo equivalió a x86/x64. Esa suposición está incrustada en scripts, instaladores, componentes de terceros y a veces incluso en el modelo de datos (por ejemplo rutas, claves de registro, interfaces de drivers). En cuanto aparecen clientes ARM64, se hace visible cuánto conocimiento implícito hay en el sistema. Y ese es el núcleo económico: las adaptaciones tardías no son solo “unos flags del compilador”, sino limpiar suposiciones que se han solidificado durante años.

En la práctica ARM64 se vuelve relevante especialmente en tres situaciones:

• Software cliente con larga vida útil: aplicaciones sectoriales que se usan durante 8–15 años y se amplían de forma iterativa. Es más probable una nueva plataforma cliente en medio del ciclo de vida que una reconstrucción completa.
• Flotas mixtas: fuerzas de campo/servicio, portátiles de dirección, escenarios próximos a BYOD o filiales que adquieren hardware distinto.
• Presión de seguridad y cumplimiento: firma de código moderna, endurecimiento, principio de menor privilegio, actualizadores controlados —estos cambios tocan de todos modos procesos de instalación y actualización. Justo entonces es conveniente integrar ARM64 como requisito secundario.

La buena noticia: quien ya trabaja en Delphi Modernisierung, migración a 64 bits, desacoplar accesos a datos o en una arquitectura objetivo orientada a servicios, puede arrastrar consigo Windows 11 ARM64 —siempre que esté temprano en el backlog y no espere hasta la primera máquina ARM en soporte.

Delphi en ARM64: ¿qué es “fácil” y qué es “difícil”?

Los proyectos Delphi varían mucho: desde clientes de escritorio VCL puros hasta sistemas multicapa con REST-Server, servicios, workers de reporte, componentes de integración y jobs en segundo plano. Para Windows 11 ARM64 es decisivo qué partes deben ejecutarse nativamente en el cliente y qué partes pueden razonablemente trasladarse a servicios.

El compilador rara vez es el principal problema

Si su código propio está limpio (sin ensamblador inline, sin supuestos antiguos de 32 bits, sin casts de punteros frágiles, sin llamadas a APIs obsoletas), compilar para una nueva plataforma objetivo suele ser factible. Los problemas surgen por:

• Componentes de terceros con partes nativas (DLLs, BPLs, puentes C/C++)
• Drivers y conexión de dispositivos (impresión, escaneo, pads de firma, dongles)
• Acceso a bases de datos vía ODBC/OLE DB/librerías cliente que no son ARM64
• Reporting e integración con Office (automatización COM, filtros de exportación antiguos)
• Instaladores/actualizadores que solo prueban x64 o usan rutas codificadas

Así, Windows 11 ARM64 es sobre todo una “prueba de ecosistema”: ¿qué tan desacoplado está su paquete de software de supuestos de plataforma antiguos?

VCL, FMX y dependencias de UI

Muchas aplicaciones B2B verticales se basan en VCL y usan componentes de UI acumulados a lo largo de los años. Eso no es en sí un problema, pero la UI suele ser donde se concentran dependencias: impresoras PDF, generadores de códigos de barras, librerías de imágenes, controles de navegador, objetos COM. Para ARM64 vale: cuantos más componentes especializados cerca de la UI use, más importante será una lista de compatibilidad temprana.

En estrategias multiplataforma (p. ej. Windows + macOS) a menudo entra FMX en juego. Independientemente del framework, una estrategia robusta es separar la lógica de negocio y las integraciones de la UI. Eso beneficia tanto a Delphi Multiplattform como a Windows 11 ARM64.

Obstáculos técnicos típicos (y cómo detectarlos temprano)

En la práctica, la mayoría de los problemas ARM64 se detectan si se hace una inventaría estructurada y un “ARM64 Readiness”-Check. Es crucial no mirar solo el código Delphi, sino todo lo que pertenece al producto: instalador, drivers, configuración, plugins, herramientas de terceros, cadena de actualización, scripts de soporte.

1) DLLs nativas, BPLs y paisajes de procesos mixtos

Muchas aplicaciones Delphi cargan DLLs adicionales: criptografía, visores CAD, OCR, firmadores, SDKs de hardware, parseadores especializados. En x64 a menudo se asume tácitamente que “ya existe una DLL de 64 bits”. Para ARM64 eso es distinto: necesita binarios ARM64 explícitos o una arquitectura que elimine esa dependencia del cliente.

Enfoque práctico:

• Haga una lista de todos los módulos nativos cargados (también indirectamente vía componentes).
• Clasifíquelos: “ARM64 disponible”, “solo x64”, “solo 32 bits”, “incierto”.
• Evalúe si el módulo realmente debe ser local o puede trasladarse a un servicio.

Un hallazgo frecuente: un único módulo solo x64 bloquea todo el cliente ARM64. Ese es el momento en que una capa limpia o una Layer-3 Architektur se vuelve económicamente justificable: la UI/cliente se mantiene ligera y las integraciones se mueven a capas de servidor/servicio controladas.

2) COM, automatización Office e integraciones con el Shell

En muchas empresas las exportaciones Word/Excel, la conexión con Outlook, menús contextuales del Explorer o integraciones DMS se han desarrollado históricamente mediante COM. COM no es automáticamente “ARM64-ready”, especialmente si servidores COM o add-ins de terceros solo se distribuyen en x64. También el operar mezclas 32-bit/64-bit (Out-of-Proc vs. In-Proc) se complica rápidamente.

Aclaraciones tempranas:

• ¿Qué objetos COM se usan (lista de ProgIDs/CLSIDs)?
• ¿In-Proc o Out-of-Proc? ¿Existen registros ARM64?
• ¿Se puede resolver la exportación mediante bibliotecas del lado servidor (p. ej. formatos basados en documentos) en lugar de automatización Office?

Con frecuencia es una palanca de modernización: alejarse de la automatización acoplada a la UI hacia servicios de exportación reproducibles (p. ej. PDF/Excel vía librería) que sirvan tanto para Windows x64 como para ARM64 o incluso para Linux-servidores.

3) Acceso a base de datos: ODBC, librerías cliente, legado BDE

El acceso a datos es una interfaz típica para ARM64 porque aquí intervienen ecosistemas de drivers y librerías cliente. Especialmente críticos son setups antiguos de ODBC, clientes propietarios de bases de datos o bases locales con capas de acceso históricas.

En stacks Delphi esto es clásico: si aún están Borland BDE, estructuras Paradox antiguas o cadenas de drivers difíciles de mantener, ARM64 se convierte en catalizador. Una BDE-Ablösung y la migración a una BDE-Ablösung mit nativer Anbindung con una estrategia clara de controladores DB reduce significativamente los riesgos de plataforma.

Puntos concretos de verificación:

• ¿Qué bases de datos se usan (SQL Server, PostgreSQL, MariaDB, Firebird, motores locales)?
• ¿Qué drivers se usan (ODBC, cliente nativo, BDE-Ablosung mit nativer Anbindung-drivers, OLE DB)?
• ¿Dónde están los connection-strings y DSNs (por usuario, por máquina, en el instalador)?
• ¿Hay dependencias de drivers ODBC de 32 bits o proveedores antiguos?

Especialmente con SQL Server/ODBC un cliente ARM64 puede funcionar —pero solo si la cadena de drivers y la rutina de instalación están limpias. No es algo que quiera depurar “en campo”.

4) Reporting, impresión, escaneo, PDF y flujos de salida

La salida es a menudo crítica en aplicaciones sectoriales: albaranes, etiquetas, facturas, protocolos, lecturas de contadores, certificados, etiquetas de envío. Muchos de esos flujos dependen de componentes de reporting o de drivers/específicos de impresión/escaneo.

En Windows 11 ARM64 los obstáculos típicos son:

• Drivers de impresoras de etiquetas/especiales disponibles solo en x64
• Software/SDKs de escáner sin soporte ARM64
• Motores de informe antiguos con módulos nativos de previsualización/exportación
• Generación de PDF mediante “impresoras virtuales” en lugar de librerías

Un enfoque sólido es estandarizar los workflows de salida: generar PDF/formatos Office mediante librerías, imprimir mediante interfaces estandarizadas, encapsular accesos a hardware especial lo máximo posible. Donde eso no sea posible, se necesita pronto una matriz de dispositivos/drivers para ARM64.

5) Instalador, actualizador, firma de código y operación

Muchos proyectos ARM64 no fracasan por el programa, sino por la entrega: el setup detecta mal la arquitectura, no instala drivers, no registra COM, pone rutas incorrectas o falla por políticas de firma de código. También las actualizaciones automáticas (delta-updates, self-updater) suelen depender fuertemente de la arquitectura.

Preguntas importantes para la operación:

• ¿Cómo se instala (MSI, Inno Setup, actualizador propio)?
• ¿Cómo se instalan las dependencias (VC++ Runtimes, drivers, certificados)?
• ¿Cómo se firma (EXE, DLL, instalador, paquetes de drivers)?
• ¿Cómo se prueba: hardware ARM64 real o solo suposiciones?

Para las empresas esto es un tema de gobernanza: si Windows 11 ARM64 aparece en la flota cliente, el despliegue debe ser reproducible —incluyendo rollback, capacidad de soporte y versionado claro.

Estrategia: Windows 11 ARM64 como “requisito no funcional” temprano

El enfoque económicamente razonable es tratar ARM64 como un requisito no funcional (NFA) —similar a rendimiento, seguridad u offline. Eso significa: no esperarlo hasta el sprint “cuando haya fuego”, sino definirlo como guía para la arquitectura y la cadena de suministro.

ARM64-Readiness-Check: inventario en lugar de intuición

Un check fiable incluye típicamente:

• Inventario de dependencias: todos los componentes de terceros, DLLs, drivers, SDKs, controles de navegador, módulos criptográficos, reporting.
• Análisis de build/pipeline: targets de build, empaquetado, firma, almacenamiento de artefactos, numeración de versiones, reproducibilidad.
• Cadena de instalador/actualización: lógica del setup, prerequisitos, rutas de registro/sistema de archivos, políticas, permisos.
• Modelo de operación: soporte, logging, crash-dumps, telemetría (si existe), plan de despliegue.

El resultado no debe ser “ARM64: sí/no”, sino una lista priorizada: qué bloqueadores existen, qué módulos están afectados, qué alternativas hay y qué inversión es realista.

Matriz de decisión: nativo en ARM64 o desacoplar?

Para cada dependencia problemática conviene una decisión clara:

• Sustituto nativo ARM64 posible: actualización, cambio de proveedor, cambio a otra librería.
• La dependencia puede externalizarse: p. ej. a un servicio, a un worker en segundo plano o a un servidor REST.
• La dependencia debe permanecer local: p. ej. porque el hardware está conectado directamente al cliente. Entonces hacen falta aprobaciones de hardware/drivers para ARM64.

Para integraciones la externalización suele ser el camino más limpio: el cliente queda como UI + diálogos sectoriales mientras que la lógica compleja de integración corre en servicios controlados. Esto apoya además temas como actualizaciones centrales, conceptos de permisos y mejor testabilidad.

Patrones de arquitectura que estabilizan proyectos ARM64

Si Windows 11 ARM64 se planifica temprano, se pueden tomar decisiones arquitectónicas que no requieran costosas revisiones posteriores.

1) Capas claras: UI, lógica de negocio, integración, acceso a datos

Los clientes Delphi heredados suelen tener “todo en un proceso”: UI, reglas de negocio, acceso a datos, integración DMS, impresión y exportación. Eso es mantenible mientras la plataforma sea estable. Cuando aparecen variantes de plataforma (ARM64, potencialmente macOS, tal vez terminal server) aumenta el valor de una clara estratificación.

Imagen objetivo pragmática:

• Capa UI: mínima, testeable, sin dependencias directas a drivers/SDKs.
• Lógica de negocio: lo más neutral posible respecto a la plataforma, modelada de forma limpia.
• Capa de integración: encapsula COM, formatos de archivo, conectores DMS/ERP, SDKs de dispositivos.
• Acceso a datos: consolidado (p. ej. FireDAC), límites transaccionales claros, sin SQL disperso.

Esto no es “académico”, sino que ahorra costes reales: si solo la capa de integración es problemática para ARM64, no hace falta reconstruir todo el cliente.

2) Servicios y REST-servidores como ancla de estabilidad

Muchos sistemas B2B se benefician de ejecutar funciones centrales como REST-Server o como servicios/Linux en el servidor: verificación de permisos, workflows documentales, validación de datos, exportación, importación, integraciones ERP/DMS/CRM. Si estas funciones corren server-side, la complejidad cliente disminuye significativamente —y con ella la superficie de ataque de ARM64.

Distribuciones típicas que han funcionado:

• Cliente: diálogos, visualización, lógica offline (si procede), integraciones locales mínimas.
• REST-Server: operaciones de negocio, validación, multi-tenant, registro centralizado.
• Worker/Service: jobs programados, polling de interfaces, generación de informes, exportaciones por lotes.

Esto encaja también con modelos de operación modernos: una función que corre en el servidor se actualiza una vez —en lugar de actualizarla en cada cliente ARM64.

3) Un sistema de build, múltiples targets (x64 + ARM64) desde el inicio

Si ARM64 es un objetivo, la pipeline de build debe reflejarlo. No como “hacer más tarde un build especial”, sino como estándar: cada release-candidate se construye de forma reproducible para x64 (y, si procede, ARM64), incluyendo firma y empaquetado del instalador.

Lo importante no es tanto la herramienta como la consistencia:

• Nombrar artefactos claramente (arquitectura en nombre de paquete/estructura de carpetas).
• Separar valores de configuración por target (rutas, prerequisitos, paquetes de drivers).
• Definir smoke-tests por arquitectura (arranque, login, conexión DB, impresión/PDF).

Así ARM64 deja de ser un “Big Bang” y pasa a ser un target adicional controlado.

Modernización Delphi: ARM64 como oportunidad para reducir deuda técnica

Muchas empresas usan nuevos requisitos de plataforma como excusa para “rehacerlo todo”. Eso es arriesgado y a menudo innecesario. Es más eficiente usar Windows 11 ARM64 como guía para una modernización incremental: reducir deuda técnica donde bloquea ARM64 o pone en riesgo la capacidad de entrega.

64-bit y Unicode: no postergar temas antiguos

Si la base de código aún contiene supuestos de 32 bits o lastres de versiones tempranas de Delphi, aflorarán con el cambio de plataforma. Aunque ARM64 no implica automáticamente “Unicode”, muchos proyectos que abordan ARM64 aprovechan para garantizar Unicode, establecer rutas de 64 bits y limpiar problemas de memoria/punteros.

El objetivo no es la perfección, sino un estándar fiable: código que pueda construirse para nuevos targets sin reproducir siempre las mismas clases de errores.

BDE-Ablösung y acceso a datos consolidado como habilitador ARM64

Donde existan capas de acceso históricas (BDE, datos locales Paradox, accesos mixtos), consolidar es una palanca con efectos múltiples: código más mantenible, despliegues más estables, estrategia de drivers más clara. Con FireDAC el acceso puede unificarse en muchos escenarios, incluyendo gestión central de parámetros, estrategias de pooling y un manejo de errores ordenado.

Importante: una BDE-Ablösung no es solo “intercambiar componentes”. Afecta la lógica transaccional, tipos de datos, ordenamientos, semántica de filtros y parte del modelo de datos. Por eso debe planificarse —no dejarse como medida de emergencia cuando clientes ARM64 aparecen repentinamente en campo.

Pruebas y aseguramiento de calidad: ARM64 es planificable solo si se hace medible

Planificar ARM64 pronto significa también: hay que probarlo —no con pruebas completas de cada función, sino con tests de riesgo dirigidos a la cadena crítica. El paso más importante es disponer de un entorno de pruebas ARM64 real. La emulación puede ayudar puntualmente, pero no sustituye la práctica con hardware real, drivers reales y políticas de seguridad reales.

Smoke-test mínimo ARM64: qué cubrir desde temprano

Un conjunto de smoke-tests pragmático pero eficaz para cada release-candidate:

• Arranque del programa, login, funciones UI básicas
• Conexión a BD (incl. autenticación, certificados, DNS/Proxy si procede)
• Un proceso central “end-to-end” (p. ej. crear pedido, guardar, imprimir/exportar)
• Actualizador/Instalador: instalación nueva y actualización entre versiones
• Logging/mensajes de error: ¿son las diagnósticos aprovechables también en ARM64?

Con esto los bloqueadores típicos ARM64 se hacen visibles pronto: DLLs faltantes, drivers erróneos, problemas de setup, requisitos de permisos inesperados.

Capacidad de diagnóstico: crash-dumps, logs, transparencia de versiones

Si ARM64 está en la flota, aparecerán casos de soporte —solo por las nuevas combinaciones de drivers. Por eso vale la pena estandarizar diagnósticos: IDs de build claras, logs informativos, rutas reproducibles de instalación y actualización. No es específico de ARM64, pero ARM64 hace que las carencias aquí sean costosas con rapidez.

Despliegue y operación: flotas mixtas sin caos

La mayoría de las empresas operará a medio plazo flotas cliente mixtas: parte x64, parte ARM64. La clave es diseñar conscientemente ese estado.

Empaquetado: instaladores separados, detección clara, vías de descarga inequívocas

En la práctica funciona mejor cuando los instaladores/paquetes son inequívocos: el paquete x64 es x64, el paquete ARM64 es ARM64. “Un instalador para todo” suena cómodo pero se complica pronto (lógica de verificación, prerequisitos, rutas de drivers, firma, reparación). Para despliegues empresariales controlados la claridad suele ser más robusta.

Estrategia de actualizaciones: sin caminos especiales para ARM64

ARM64 no debería ser un caso especial en el proceso de actualización. El objetivo: misma cadencia de releases, misma numeración de versión funcional, pero artefactos separados. Si ARM64 se actualiza solo “manualmente”, surgen desviaciones en la flota que disparan costes de soporte.

Documentar integraciones con detalle

Muchos problemas ARM64 no están en su propio código sino en integraciones: conector ERP, cliente DMS, servicio de firma, software de escaneo, impresora de etiquetas. Una lista de integraciones mantenida con versiones y notas de arquitectura es sensata para sistemas B2B —y hace transparentes las decisiones ARM64.

Qué deberían hacer las empresas ahora (sin activismo innecesario)

Planificar Windows 11 ARM64 temprano no significa rehacerlo todo de inmediato. Significa responder las preguntas correctas pronto y eliminar bloqueadores mientras el esfuerzo es predecible. Un enfoque probado es:

• 1) Inventario (2–10 días según tamaño del sistema): dependencias, instalador, drivers, acceso a datos, COM, reporting.
• 2) Imagen objetivo y ruta: ¿qué debe ser nativo en el cliente? ¿Qué pasa a servicio/REST? ¿Qué componentes se reemplazan?
• 3) Proof of Feasibility: un build ARM64 funcional con instalador y un caso de uso end-to-end.
• 4) Endurecimiento gradual: funciones restantes, pruebas, cadena de actualización, capacidad de diagnóstico.

Así no surge un “proyecto ARM64” aislado y largo, sino una ampliación controlada de la capacidad de entrega.

Conclusión: Windows 11 ARM64 no es una moda, sino un indicador temprano de madurez técnica

Windows 11 ARM64 se convertirá para muchas empresas en realidad—por compras de hardware, exigencias de movilidad o estandarización. Para aplicaciones Delphi el reto real no es solo el código fuente, sino el sistema completo de dependencias, procesos de instalación/actualización, integraciones y drivers. Quien planifique ARM64 temprano puede aclarar estos puntos de forma estructurada en vez de parchearlos luego bajo presión.

Al final, ARM64 es una prueba útil: ¿qué tan desacoplada, testeable y entregable es su aplicación? Si responde a esa pregunta ahora, gana no solo opciones de plataforma sino también una base más estable para modernización, servicios, arquitecturas REST y mantenibilidad a largo plazo.

Póngase en contacto con Net-Base Software GmbH, si desea evaluar de forma fiable Windows 11 ARM64 en su hoja de ruta Delphi y llevarlo a cabo con una ruta técnica clara.