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 notebooks empresariales) ya no son en muchas empresas meros «exóticos». Llegan a través de flotas de portátiles estandarizadas, mayor duración 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 OEMs ofrecen ciertos modelos únicamente como Windows en ARM, se plantea para los responsables de TI la pregunta práctica: ¿cómo se comporta nuestro software empresarial basado en Delphi bajo Windows 11 ARM64 – y cómo aseguramos la operación, el soporte y la evolución?

El punto central es: Windows 11 ARM64 con Delphi en las 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 el campo. En la práctica existen tres vías: continuidad mediante emulación, builds nativos ARM64 o un modelo de transición que reduzca los riesgos de forma controlada. Esta entrada clasifica los errores típicos y muestra un camino fiable que funciona en la planificación de TI, el despliegue y la operación – sin el reflejo de „rehacerlo todo“.

Por qué Windows 11 ARM64 se vuelve relevante ahora

Windows en ARM no es nuevo, pero las condiciones marco han cambiado: los dispositivos están disponibles en el entorno empresarial, Windows 11 ARM64 11 aporta una emulación x64 claramente más madura, y los fabricantes de software suministran con más frecuencia variantes ARM64. Para las empresas esto significa que 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 a procesos el problema no es tanto la CPU en sí, sino la realidad de periféricos e integraciones: 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 algo de eso no es compatible con ARM64, surge trabajo de soporte —y con frecuencia se culpa entonces a “la aplicación”.

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

Las aplicaciones Delphi en entornos empresariales suelen ser clientes de escritorio clásicos Windows (a menudo VCL, es decir, la Visual Component Library para interfaces Windows) con acceso a base de datos (p. ej. mediante una sustitución de BDE con enlace nativo, la capa de acceso a datos de Delphi) y una mezcla de integraciones locales y remotas. Bajo Windows 11 ARM64 surgen tres modalidades 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 permite planificar rendimiento y estabilidad y evita las condiciones límite de la emulación. Sin embargo, solo es realista si todas las dependencias nativas se adaptan: 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 del shell o componentes in-process (DLLs cargadas en el proceso), la arquitectura importa. Un proceso x64 no puede cargar una DLL ARM64 y viceversa. Precisamente ese límite decide con frecuencia entre “funciona” o “no funciona”.

3) Hybrid: ARM64-Client, x64-Komponenten entkoppeln

Un camino de transición es extraer componentes x64 críticos fuera del proceso: p. ej. como 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 económica para asegurar la operación y modernizar dependencias de forma gradual.

Windows 11 ARM64 mit Delphi in Unternehmen: Die typischen Abhängigkeiten, die über Erfolg entscheiden

En los proyectos se hace evidente 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.

Native DLLs und SDKs: Das unsichtbare Risiko

Muchas aplicaciones Delphi integran DLLs de terceros: generación de PDF, códigos de barras/QR, procesamiento de imágenes, cifrado, bibliotecas de comunicación propietarias. Bajo ARM64 rige de forma estricta: 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, esas bibliotecas deben existir como ARM64 o deben ser sustituidas.

Consejo práctico para TI: pida a los responsables del software un listado de qué DLLs residen en el directorio de instalación y cuáles se cargan desde rutas del sistema. Esa es la base para evaluar la capacidad del proveedor y las alternativas.

COM, Office-Automation und Shell-Erweiterungen

COM se utiliza a diario en la empresa a menudo sin que se nombre explícitamente: integración con Outlook, exportación a Excel mediante Automation, clientes DMS, handlers de vista previa en el Explorer, extensiones del menú contextual. El problema bajo ARM64 no es tanto COM en sí, sino el acoplamiento de bitness: los servidores COM in-process (componentes COM basados en DLL) deben tener la misma arquitectura. 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, por ejemplo, una antigua DLL COM de 32 bits o de 64 bits, eso es un bloqueo para ejecución nativa en ARM64. Emulada como x64 puede funcionar, siempre que todas las dependencias COM también sean x64 y no intervengan componentes exclusivos para ARM64.

Druck, PDF und Treiberlandschaft

Los problemas de impresión son un clásico en los cambios de plataforma. Con Windows 11 ARM64 es decisivo si el fabricante de la impresora proporciona controladores ARM64 o si se pueden usar controladores de clase Universal Print/IPP (IPP es un protocolo de impresión estandarizado). También impresoras PDF, impresión por lotes, impresión de etiquetas y dispositivos especializados (p. ej. impresoras térmicas) pueden depender de controladores que solo existen 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 controlador» o «la canalización de impresión es distinta».

Datenzugriff: FireDAC, ODBC/OLE DB und Datenbank-Clients

En el nivel de datos conviene una separación clara 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 PostgreSQL antiguo o un controlador ODBC específico, debe existir para ARM64; de lo contrario, conviene adoptar una arquitectura que encapsule el acceso a datos del lado del servidor (p. ej. a través de servicios REST o de servicios Windows-/Windows- y Linux-servicios).

Para un funcionamiento estable esto es una palanca central: cuanto menos esté el cliente de escritorio vinculado directamente a controladores de base de datos y a «stacks» locales de base de datos, más fácil será la transición a ARM64. Lo mismo aplica desde el punto de vista de la 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, smartcards, firmas, VPN, EDR

Hoy muchos procesos de negocio dependen de componentes criptográficos: S/MIME, certificados de cliente, middleware de smartcard, tarjetas de firma, inspección TLS en proxies. A esto se suman soluciones de seguridad en endpoints (EDR es Endpoint Detection and Response) y clientes VPN. Estos componentes deben ser compatibles con ARM64; de lo contrario surge un problema del tipo «el dispositivo está ahí, pero no puede conectarse a la red».

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

Matriz de decisión: ¿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 pregunta simple de sí/no («¿portamos?») rara vez es útil. Mejor una matriz que pondera dependencias y riesgos:

• Cliente puro con APIs estándar Windows (archivo, red, impresión mediante controladores estándar): la emulación puede bastar a corto plazo; un ARM64 nativo es ordenado a medio plazo.
• Cliente con muchas DLLs nativas de terceros (PDF, OCR, hardware): primero verificar disponibilidad y luego decidir. A menudo tiene sentido una vía híbrida.
• Cliente con COM-DLLs / extensiones de shell: se esperan conflictos de arquitectura; considerar desacoplamiento fuera de proceso.
• Cliente con un zoológico de controladores de BD: o bien consolidar controladores o bien trasladar el acceso a datos a servicios.
• Alta regulación/firmas/smartcard: verificar pronto la compatibilidad ARM64 de la cadena de seguridad y middleware.

Importante: la emulación no es una «segunda clase», pero sí representa un riesgo operativo si prevé ver equipos ARM64 en la flota a largo plazo. A más tardar con actualizaciones mayores, cambios de controladores o cambios de agentes de seguridad, no querrá quedar atascado en una cadena de casos especiales.

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

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

Paso 1: Inventario con enfoque operativo

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

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

Esta vista hace visible rápidamente si «solo un cliente» en realidad significa cinco dependencias del sistema.

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

El piloto no debería ser «el dispositivo más bonito», sino un candidato típico de la flota objetivo. Pruebe deliberadamente las rutas críticas: impresión en todas sus variantes, exportación/importación, firma, offline/online, actualizaciones, conmutación de inquilinos, escenarios Proxy/VPN. Documente las desviaciones como incidentes operativos, no como errores de desarrollo. Así se mantiene la priorización clara.

Paso 3: Reducir dependencias — primero las que tienen mayor impacto en el soporte

Medidas típicas que aportan mucho en la operativa diaria:

• Estandarizar la ruta PDF/impresión: alejarse de DLLs de impresora propietarias, hacia pipelines estables y probados.
• Desacoplar la integración con Office: en lugar de complementos en proceso, prefiera formatos de exportación y generación de documentos en el servidor.
• Consolidar el acceso a la base de datos: un camino de controlador definido en lugar de «ODBC según el puesto de trabajo».
• Encapsular la conexión de hardware: si es posible, mediante procesos/servicios externos que puedan actualizarse por separado.

Paso 4: Modernizar despliegue y capacidad de actualización

ARM64 es una buena ocasión para depurar la instalación y las actualizaciones. Para las empresas no cuentan las funcionalidades, sino la capacidad de reversión, la reproducibilidad y la conformidad con las políticas. Compruebe:

• Empaquetado: MSI vs. MSIX (MSIX es el formato de paquete de aplicaciones moderno de Microsoft con instalación/desinstalación limpia y firma).
• Firmado: firma de código (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, sin dependencias «ocultas» del Registro.
• Canales de actualización: piloto, anillo 1, anillo 2 – con telemetría/registro a nivel de aplicación y operativo.

Paso 5: ARM64 nativo donde realmente valga la pena

Las compilaciones nativas ARM64 tienen sentido cuando (a) tiene controladas las dependencias y (b) la aplicación se va a evolucionar a largo plazo. Suele compensar en clientes centrales que emplean a muchos usuarios a diario y que de todos modos va a modernizar. En herramientas de uso infrecuente, la emulación x64 puede ser una transición aceptable, siempre que el soporte y la seguridad lo permitan.

Impulsos de arquitectura: ARM64 como motivo para reforzar interfaces y servicios

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

Más estabilidad mediante responsabilidades del lado del servidor

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

• versiones uniformes de controladores y bibliotecas,
• mejor control de la seguridad (certificados, secretos, red),
• menor complejidad en el cliente (ARM64, x64, en el futuro 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 son reproducibles más rápidamente en el servidor, en lugar de quedar colgados en «un portátil concreto».

REST-API como capa de desacoplamiento

Una REST-API no es automáticamente «moderna», pero constituye un desacoplamiento robusto entre los clientes y el backend. Define con claridad qué datos y acciones están permitidos, y puede asegurarse de forma ordenada (p. ej. mediante Tokens, certificados o SAML 2.0 como estándar de identidad en entornos empresariales). Para ARM64 esto significa: el cliente necesita llevar menos «conocimiento del mundo» sobre bases de datos, controladores y detalles de red.

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

Pruebas y calidad: qué debe verificar de forma distinta en ARM64

Muchos equipos prueban el software de escritorio principalmente desde el punto de vista funcional. En ARM64 debería probarse más desde la perspectiva operativa, porque los patrones de error son distintos: no «cálculo erróneo», sino «componente no carga», «falta el controlador», «la 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, escenario de reversión, verificación de firmas.
• Registro: registros centralizados, códigos de error claros en problemas de carga de DLL, rutas de impresión rastreables.
• 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 especial, flujos de trabajo de escáner, funciones de tarjeta inteligente.
• Seguridad: interacción EDR/AV, proxy/TLS, almacén de certificados, operación con privilegios mínimos.

La documentación es importante: si un problema se debe a la ausencia de controladores ARM64, eso no es una «corrección de errores en Delphi», sino una decisión de adquisición o estandarización.

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

En el día a día lo que cuenta es la rapidez con la que se resuelven los casos de soporte. Para ARM64 vale la pena aumentar proactivamente la capacidad de soporte:

Perfiles de dispositivos estandarizados y aprobaciones claras

Defina los modelos ARM64 soportados o al menos perfiles mínimos (estrategia de controladores, estrategia de impresión, versiones de agentes de seguridad). Un «funciona en ARM64» sin ese marco conduce a entornos heterogéneos y, por tanto, a incidencias de difícil reproducción.

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 núcleo y configuración de impresión, reduce notablemente los tiempos de soporte. Esto no es un «nice to have», sino higiene operativa.

Licenciamiento y dongles

Si están en juego dongles de hardware o controladores de licencia antiguos, ARM64 se vuelve rápidamente crítico. En muchos entornos conviene migrar el licenciamiento a mecanismos habilitados para red o basados en servidor. Así disminuye la dependencia de controladores en los dispositivos finales y la flota resulta más intercambiable.

¿Qué significa esto para su Delphi-estrategia?

Delphi suele ser en el contexto empresarial un componente estable para clientes de escritorio y servicios. Windows 11 ARM64 no es un argumento „en contra de Delphi“, pero sí 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 locales especiales, menos componentes en proceso, 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, mayor integración 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 una ocasión sensata para hacer estos riesgos transparentes y reducirlos de forma planificada.

Conclusión: ARM64 es menos un proyecto de portado que un proyecto de arquitectura y operaciones

Para las empresas, Windows 11 ARM64 es ante todo una cuestión de plataforma en compra, 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 fiable es: primero hacer visibles las dependencias y las rutas operativas, luego probar con dispositivos piloto, a continuación desacoplar de forma selectiva y profesionalizar el despliegue — y entregar compilaciones nativas ARM64 allí donde aporten beneficio y estabilidad a largo plazo.

Si desea introducir Windows 11 ARM64 en su flota y, al hacerlo, asegurar 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 las integraciones, los flujos de datos y el desarrollo continuado deben encajar de forma ordenada.

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