Windows 11 ARM64 con Delphi en empresas: opciones, riesgos y una hoja de ruta de migración sólida

Los dispositivos Windows con CPU ARM64 (ARM64 es una arquitectura de procesador de 64 bits, conocida por los SoC móviles y cada vez más presente en los portátiles empresariales) ya no son en muchas empresas meros “exóticos”. Aparecen a través de flotas de portátiles estandarizadas, mayores autonomías de batería, nuevas funciones de seguridad en el hardware y una diversificación estratégica de la cadena de suministro. A más tardar cuando las áreas de negocio adquieren nuevos equipos o los OEM ofrecen determinados modelos solo como Windows on ARM, los responsables de TI se plantean la pregunta práctica: ¿Cómo se comporta nuestro software empresarial basado en Delphi bajo Windows 11 ARM64 – y cómo garantizamos operación, soporte y evolución?

El punto central es: Windows 11 ARM64 con Delphi en empresas es menos una cuestión puramente de desarrollo y más una cuestión de dependencias, estrategias de despliegue, controladores, interfaces y del comportamiento real en campo. En la práctica existen tres caminos: continuidad mediante emulación, compilaciones nativas ARM64 o un modelo de transición que reduzca riesgos de forma controlada. Esta entrada clasifica los tropiezos típicos y muestra una senda sólida que funciona en planificación de TI, despliegue y operación – sin el reflejo de “rehacerlo todo”.

Por qué Windows 11 ARM64 se vuelve relevante ahora

Windows on ARM no es nuevo, pero las condiciones marco han cambiado: los dispositivos están disponibles en el entorno empresarial, Windows 11 aporta una emulación x64 claramente más madura, y los fabricantes de software entregan cada vez con más frecuencia variantes ARM64. Para las empresas esto significa: ARM64 no aparece como un proyecto piloto aislado, sino como una plataforma que entra en las planificaciones de adquisición y de ciclo de vida.

Para soluciones de software cercanas al proceso, el problema no es tanto la CPU en sí, sino la realidad de la periferia e integración: impresoras, tarjetas de firma, escáneres, complementos de Office, componentes COM (COM es el modelo de componentes de Microsoft para la integración de aplicaciones y bibliotecas), extensiones del shell, clientes VPN o agentes de seguridad. Si alguno de estos elementos no es compatible con ARM64, surge carga de soporte —y con frecuencia se responsabiliza a “la aplicación”.

Contexto: ¿Qué significa ARM64 técnicamente para las aplicaciones Delphi?

Las aplicaciones Delphi en el entorno empresarial suelen ser clientes de escritorio clásicos de Windows (a menudo VCL, es decir, la Visual Component Library para GUIs de Windows) con acceso a bases de datos (p. ej. mediante la BDE-Ablösung con enlace nativo, la capa de acceso a datos de Delphi) y una mezcla de integraciones locales y remotas. Bajo Windows 11 ARM64 se distinguen tres modos de ejecución:

1) Ejecución nativa ARM64

La aplicación y todas las bibliotecas nativas (DLL) están en ARM64. A largo plazo es la opción más limpia, porque hace predecible el rendimiento y la estabilidad y evita las condiciones límite de la emulación. Sin embargo, solo es realista si todas las dependencias nativas acompañan: controladores de base de datos, impresión/preview, motor PDF, bibliotecas criptográficas, SDKs de OCR/escaneo, controladores de dongles de hardware, etc.

2) Emulación x64 bajo Windows 11 ARM64

Windows 11 puede emular aplicaciones x64. Para muchos clientes de escritorio puros eso funciona sorprendentemente bien. En la práctica, sin embargo, la emulación no es una „tarjeta gratis“: en cuanto intervienen controladores, integraciones con el shell o componentes in-process (DLL que se cargan en el proceso), entra en juego la arquitectura. Un proceso x64 no puede cargar una DLL ARM64 y viceversa. Precisamente este límite decide con frecuencia entre „funciona“ o „no funciona“.

3) Híbrido: cliente ARM64, desacoplar componentes x64

Una vía de transición es extraer las componentes x64 críticas fuera del proceso: p. ej. como un servicio externo, como backend REST ( REST es un modelo de interfaz basado en HTTP) o como una utilidad auxiliar separada. Esto es menos elegante que „todo nativo“, pero a menudo la ruta más rentable para asegurar la operación y modernizar las dependencias de forma gradual.

Windows 11 ARM64 con Delphi en empresas: las dependencias típicas que deciden el éxito

En los proyectos se ve rápidamente: el cuello de botella no es la GUI, sino el ecosistema. Un análisis estructurado de dependencias ahorra semanas de ensayo y error.

DLL nativas y SDKs: el riesgo invisible

Muchas aplicaciones Delphi incorporan DLL de terceros: generación de PDF, códigos de barras/QR, procesamiento de imágenes, cifrado, bibliotecas de comunicación propietarias. En ARM64 se aplica estrictamente: una DLL debe coincidir con la arquitectura del proceso. La emulación solo ayuda si todo el proceso permanece x64. En cuanto se quiere ejecutar de forma nativa, estas bibliotecas deben estar disponibles como ARM64 o ser sustituidas.

Consejo práctico para TI: pida al responsable de software una lista de qué DLL están en el directorio de instalación y cuáles se cargan desde rutas del sistema. Esa es la base para evaluar la capacidad del fabricante y las alternativas.

COM, automatización de Office y extensiones del shell

COM se utiliza a menudo en el entorno empresarial sin que se nombre así: integración con Outlook, exportación a Excel mediante Automation, clientes DMS, handlers de vista previa en el Explorer, extensiones de menú contextual. El problema en ARM64 no es tanto COM en sí, sino el acoplamiento por la arquitectura de bits: los servidores COM in-process (componentes COM basados en DLL) deben tener la misma arquitectura. El COM out-of-process (servidores basados en EXE) es más flexible porque puede ejecutarse en un proceso separado.

Si su aplicación Delphi utiliza p. ej. una antigua DLL COM de 32 bits o de 64 bits, eso constituye un bloqueo en una ejecución nativa ARM64. Emulado como x64 puede funcionar, siempre que todas las dependencias COM también sean x64 y no intervengan componentes exclusivos ARM64.

Impresión, PDF y el panorama de drivers

Los problemas de impresión son un clásico al cambiar de plataforma. En Windows 11 ARM64 es decisivo si el fabricante de impresoras proporciona drivers ARM64 o si se pueden usar drivers universales Universal Print/IPP (IPP es un protocolo de impresión estandarizado). También impresoras PDF, impresión en cola, impresión de etiquetas y dispositivos especiales (p. ej. impresoras térmicas) pueden depender de drivers que existen solo para x64.

Para la dirección de TI y la administración la consecuencia importante es: los despliegues ARM64 deben alinearse con la estrategia de impresión. „La aplicación no imprime“ suele significar „no existe el driver“ o „la canalización de impresión es diferente“.

Acceso a datos: FireDAC, ODBC/OLE DB y clientes de bases de datos

A nivel de datos conviene una separación limpia entre protocolo y biblioteca cliente. BDE-Ablosung mit nativer Anbindung puede trabajar, según la base de datos, con clientlibs nativas o con controladores. Si, p. ej., se necesita un cliente de Oracle, un cliente antiguo de PostgreSQL o un controlador ODBC específico, éste debe existir para ARM64 — o bien se opta por una arquitectura que encapsule el acceso a datos en el servidor (p. ej. a través de servicios REST o un Windows-/Windows- y Linux-Services).

Para un funcionamiento estable eso es una palanca central: cuanto menos esté el cliente de escritorio ligado directamente a controladores de base de datos y a pilas locales de base de datos, más fácil será la transición a ARM64. Esto también aplica en términos de seguridad: credenciales de acceso a bases de datos, certificados y reglas de red pueden gestionarse de forma más coherente en el servidor.

Criptografía, tarjetas inteligentes, firmas, VPN, EDR

Hoy muchos procesos de negocio dependen de componentes criptográficos: S/MIME, certificados de cliente, middleware de tarjetas inteligentes, tarjetas de firma, inspección TLS en proxies. A ello se suman soluciones de seguridad para endpoints (EDR es Endpoint Detection and Response) y clientes VPN. Estos componentes deben ser compatibles con ARM64; de lo contrario aparece el problema de “el dispositivo existe, pero no puede conectarse a la red”.

Para la aplicación Delphi esto significa: si, p. ej., usa certificados desde el almacén de certificados Windows o realiza TLS mediante componentes del sistema, suele ser menos crítico que si una DLL criptográfica de un tercero queda ligada al proceso.

Matriz de decisiones: ¿Emulación o portado nativo a ARM64?

Las empresas necesitan una decisión que refleje la realidad del soporte y del ciclo de vida. Una simple pregunta sí/no («¿Portamos?») rara vez es útil. Mejor una matriz que pese dependencias y riesgos:

• Cliente puro con APIs estándar Windows (archivo, red, impresión mediante controladores estándar): la emulación puede ser suficiente a corto plazo; ARM64 nativo es la solución limpia a medio plazo.
• Cliente con muchas DLLs nativas de terceros (PDF, OCR, hardware): primero verificar disponibilidad, luego decidir. A menudo tiene sentido una vía híbrida.
• Cliente con COM-DLLs / extensiones del shell: esperar conflictos de arquitectura; evaluar el desacoplamiento fuera de proceso.
• Cliente con un zoo directo de controladores de BD: o bien consolidar controladores u trasladar el acceso a datos a servicios.
• Alta regulación/firmas/tarjetas inteligentes: verificar desde temprano la capacidad ARM64 de la cadena de seguridad y middleware.

Importante: la emulación no es una „segunda clase“, pero sí constituye un riesgo operativo si planea tener dispositivos ARM64 a largo plazo en la flota. A más tardar con actualizaciones mayores, cambios de controladores o reemplazos de agentes de seguridad no querrá quedar atascado en una cadena de casos excepcionales.

Un camino de migración fiable: de hoy a ARM64 sin Big Bang

Para responsables de TI y de proyecto un camino es bueno cuando puede desplegarse en oleadas, tiene criterios de aceptación claros y no sobrecarga el soporte. En entornos Delphi se ha mostrado eficaz un enfoque en cinco pasos.

Paso 1: Inventario con „perspectiva operativa“

No registre solo módulos, sino sobre todo puntos operativos:

• ¿Qué clases de dispositivos: portátiles, dispositivos Rugged, terminales?
• ¿Qué periféricos: impresoras, escáneres, lectores de tarjetas, etiquetadoras?
• ¿Qué integraciones: Office, DMS, ERP, servicios locales, componentes del navegador?
• ¿Qué forma de instalación: MSI, EXE de instalación, ClickOnce, despliegue manual?
• Qué permisos: ¿se necesita admin, servicios locales, reglas de firewall?

Esta perspectiva permite ver rápidamente si «solo un cliente» en realidad significa cinco dependencias del sistema.

Paso 2: Verificación de compatibilidad con un piloto ARM64 representativo

El piloto no debe ser «el mejor dispositivo», sino un candidato típico de la flota objetivo. Pruebe deliberadamente las rutas críticas: impresión en todas las variantes, exportación/importación, firma, modo desconectado/conectado, actualizaciones, conmutación de mandantes, escenarios con proxy/VPN. Documente las desviaciones como incidentes operativos, no como fallos de desarrollo. Así se mantiene limpia la priorización.

Paso 3: Reducir dependencias — primero las que tienen mayor palanca de soporte

Medidas típicas que aportan mucho en el día a día:

• Estandarizar la ruta de PDF/impresión: alejarse de DLLs de impresora propietarias hacia canalizaciones estables y probadas.
• Desacoplar la integración con Office: en lugar de complementos en proceso, prefiera formatos de exportación y la generación de documentos en servidor.
• Consolidar el acceso a la BD: una vía de controlador definida en lugar de «ODBC según el puesto».
• Encapsular la conexión de hardware: cuando sea posible a través de procesos/servicios externos que puedan actualizarse por separado.

Paso 4: Modernizar el despliegue y la capacidad de actualización

ARM64 es una buena ocasión para limpiar la instalación y las actualizaciones. Para las empresas aquí no importan las funcionalidades, sino la capacidad de rollback, la reproducibilidad y la conformidad con las políticas. Revise:

• Paquetización: MSI vs. MSIX (MSIX es el moderno formato de paquete de aplicaciones de Microsoft con instalación/desinstalación limpia y firma).
• Firmado: Code Signing (firma digital de EXE/DLL) reduce la fricción con SmartScreen y EDR y es relevante para despliegues controlados.
• Gestión de configuración: separación de archivos de programa y configuración, rutas claras, no depender de entradas «ocultas» del Registro.
• Canales de actualización: piloto, Ring 1, Ring 2 — con telemetría/logging a nivel de aplicación y operativo.

Paso 5: ARM64 nativo donde realmente tenga sentido

Los builds nativos ARM64 son apropiados cuando (a) las dependencias están bajo control y (b) la aplicación se va a seguir desarrollando a largo plazo. Normalmente compensa en clientes centrales que usan muchos usuarios a diario y que de todos modos se van a modernizar. En herramientas de uso poco frecuente, la emulación x64 puede ser una transición aceptable, siempre que soporte y seguridad lo permitan.

Impulsos arquitectónicos: ARM64 como motivo para reforzar interfaces y servicios

Muchos Delphi-entornos han crecido históricamente como «cliente pesado». Eso funciona, pero ata la operación y las actualizaciones más fuertemente a configuraciones individuales de puesto de trabajo. ARM64 hace visible dónde ese acoplamiento resulta costoso. Un paso pragmático de modernización suele ser por tanto no tanto «UI nueva», sino rediseñar las interfaces.

Más estabilidad mediante responsabilidades en el servidor

Si la lógica crítica, el acceso a datos o los procesos de documentos se trasladan a un servicio central (Windows- und Linux-Services o Windows- und Linux-Services, es decir, un servicio en segundo plano sin interfaz interactiva), se obtiene:

• versiones unificadas de controladores y bibliotecas,
• mejor control de la seguridad (certificados, secretos, red),
• menor complejidad en el cliente (ARM64, x64, próximamente también otras plataformas),
• puntos de monitorización y registro más claros.

Para los responsables de TI, esto supone una ventaja operativa real: los problemas se pueden reproducir más rápido en el servidor, en lugar de quedar pendientes en ‚un portátil específico‘.

REST-API como capa de desacoplamiento

Una REST-API no es automáticamente ‚moderna‘, pero sí constituye un desacoplamiento robusto entre clientes y backend. Define con claridad qué datos y acciones están permitidos y puede asegurarse de forma consistente (p. ej., mediante tokens, certificados o SAML 2.0 como estándar de identidad en entornos empresariales). Para ARM64 eso significa: el cliente necesita portar menos ‚conocimientos del mundo‘ sobre bases de datos, controladores y detalles de red.

Aunque no vaya a migrarlo todo de inmediato: incluso un pequeño componente de API bien acotado (p. ej., generación de documentos, verificación de licencias, sincronización de datos maestros) puede eliminar dependencias del cliente y así reducir los riesgos en ARM64.

Pruebas y calidad: Qué debe comprobar de forma diferente en ARM64

Muchos equipos prueban software de escritorio principalmente desde el punto de vista funcional. En ARM64 debería centrarse más en pruebas operativas, porque los patrones de fallo son distintos: no ‚cálculos erróneos‘, sino ‚componente no carga‘, ‚falta el controlador‘, ‚actualización falla‘, ‚la integración con Office se rompe‘.

Lista de verificación para la aceptación en entornos ARM64

• Instalación/Desinstalación: limpia, sin restos, sin soluciones alternativas de administrador.
• Ruta de actualización: actualización a través de varias versiones, escenarios de reversión, verificación de firmas.
• Registro: registros centrales, códigos de error claros en problemas de carga de DLL, rutas de impresión trazables.
• Rendimiento: tiempo de inicio, operaciones de datos, listas/informes grandes – medir por separado bajo emulación y de forma nativa.
• Periféricos: perfiles de impresora, impresión especializada, flujos de trabajo de escáner, funciones de tarjeta inteligente.
• Seguridad: interacción con EDR/AV, proxy/TLS, almacén de certificados, operación con principio de mínimo privilegio.

La documentación es importante: si un problema se debe a controladores ARM64 faltantes, eso no es un ‚bugfix en Delphi‘, sino una decisión de compra o de estandarización.

Operación y soporte: Cómo integrar ARM64 en el día a día

En el día a día importa la rapidez con la que se resuelven los casos de soporte. Para ARM64 merece la pena aumentar proactivamente la capacidad de soporte:

Perfiles de dispositivos estandarizados y aprobaciones claras

Defina los modelos ARM64 compatibles o, al menos, perfiles mínimos (estrategia de controladores, estrategia de impresión, versiones del agente de seguridad). Un ‚funciona en ARM64‘ sin ese marco conduce a entornos heterogéneos y, por tanto, a incidencias difíciles de reproducir.

Capacidad de diagnóstico en la aplicación

Incluso sin un enfoque de desarrollador, es razonable exigir esto al software: una página de información del sistema que muestre la arquitectura (x64 emulado vs. ARM64 nativo), rutas importantes, versiones de componentes centrales y configuración de impresión, reduce significativamente los tiempos de soporte. Esto no es un ’nice to have‘, sino higiene operativa.

Licenciamiento y dongles

Si intervienen dongles de hardware o controladores de licencias antiguos, ARM64 se vuelve rápidamente problemático. En muchos entornos conviene migrar el licenciamiento a mecanismos con capacidad de red o servidores. Así se reduce la dependencia de controladores en los dispositivos finales y la flota se vuelve más intercambiable.

¿Qué significa esto para su estrategia Delphi?

Delphi es en el contexto empresarial con frecuencia un componente estable para clientes de escritorio y servicios. Windows 11 ARM64 no es un argumento «contra Delphi», sino un argumento a favor de una encapsulación más limpia de las dependencias y de una modernización orientada a la operación: menos controladores especiales locales, menos componentes in-process, interfaces más claras, mejor despliegue.

Si hoy ya se encuentra en una senda de modernización (p. ej. BDE-sustitución, migración a 64 bits, una integración más intensa de REST, acceso a datos consolidado con FireDAC), entonces ARM64 suele ser «solo» un punto objetivo adicional que clarifica prioridades. Si, por el contrario, su aplicación depende en gran medida de controladores antiguos, DLLs propietarias y configuraciones especiales de puesto de trabajo, ARM64 es un motivo adecuado para hacer esos riesgos transparentes y reducirlos de forma planificada.

Conclusión: ARM64 es menos un proyecto de portado y más un proyecto de arquitectura y operaciones

Para las empresas, Windows 11 ARM64 es sobre todo una cuestión de plataforma en compras, seguridad y soporte. Para el software empresarial basado en Delphi el éxito no se decide por una opción del compilador, sino por la cadena de controladores, DLLs, integraciones COM, acceso a datos y procesos de actualización. Un camino sólido es: primero hacer visibles las dependencias y las rutas operativas, luego probar con dispositivos piloto, a continuación desacoplar de forma dirigida y profesionalizar el despliegue — y entregar builds nativos ARM64 allí donde aporten utilidad y estabilidad a largo plazo.

Si desea introducir Windows 11 ARM64 en su flota y garantizar de forma planificada las aplicaciones, la periferia y las interfaces basadas en Delphi, hable con nosotros sobre un inventario estructurado y una ruta de migración realista:

En el ámbito técnico también desempeñan un papel importante Delphi ARM64 Windows y la emulación X64 Windows 11 cuando integraciones, flujos de datos y la evolución deben interoperar de forma ordenada.

Discutir proyecto o iniciativa de modernización con Net-Base.