Windows 11 ARM64 with Delphi in enterprises: options, risks and a robust migration path

Windows devices with ARM64 CPUs (ARM64 is a 64‑bit processor architecture known from mobile SoCs and increasingly also from business notebooks) are no longer just “exotics” in many companies. They appear in standardized notebook fleets, provide longer battery life, introduce new hardware security features and reflect a strategic diversification of the supply chain. At the latest when business units procure new devices or OEMs offer certain models only as Windows on ARM, IT managers face the practical question: How does our Delphi-based business software behave under Windows 11 ARM64 — and how do we ensure operation, support and ongoing development?

The core point is: Windows 11 ARM64 with Delphi in enterprises is less a pure development question and more one of dependencies, deployment strategies, drivers, interfaces and real-world behavior in the field. In practice there are three approaches: continued operation via emulation, native ARM64 builds, or a transitional model that reduces risks in a controlled way. This article classifies the typical pitfalls and shows a reliable path that works in IT planning, rollout and operations — without the reflex to “rewire everything”.

Why Windows 11 ARM64 is becoming relevant now

Windows on ARM is not new, but the conditions have changed: the devices are available in business environments, Windows 11 provides a significantly more mature x64 emulation, and software vendors increasingly supply ARM64 variants. For companies this means: ARM64 is not appearing as a one-off pilot, but as a platform that enters procurement and lifecycle planning.

For process-near software solutions the CPU itself is less the issue than the reality of peripherals and integrations: printers, signature cards, scanners, Office add-ins, COM components (COM is Microsoft’s component model for integrating applications and libraries), shell extensions, VPN clients or security agents. If any of these are not ARM64-capable, support effort increases — and often “the application” is blamed.

Context: What does ARM64 technically mean for Delphi applications?

Delphi applications in enterprise environments are often classic Windows desktop clients (frequently VCL, i.e. the Visual Component Library for Windows GUIs) with database access (e.g. via BDE replacement with native connection, Delphi’s data access layer) and a mix of local and remote integrations. Under Windows 11 ARM64 there are three execution modes:

1) Native ARM64 execution

The application and all native libraries (DLLs) are provided as ARM64. This is in the long run the cleanest option because it makes performance and stability predictable and avoids emulation edge cases. However, it is only realistic if all native dependencies follow: database drivers, print/preview, PDF engine, crypto libraries, OCR/scan SDKs, hardware dongle drivers, etc.

2) x64 emulation under Windows 11 ARM64

Windows 11 can emulate x64 applications. For many pure desktop clients that works surprisingly well. In practice, however, emulation is not a ‚free pass‘: as soon as drivers, shell integrations or in-process components (DLLs loaded into the process) are involved, architecture matters. An x64 process cannot load an ARM64 DLL and vice versa. This boundary often determines ‚works‘ or ‚doesn\’t work‘.

3) Hybrid: ARM64 client, decouple x64 components

One migration path is to pull critical x64 components out of the process: e.g. as an external service, as a REST backend (REST is an HTTP-based interface model) or as a separate helper application. This is less elegant than ‚everything native‘, but often the most economical route to secure operation and to modernize dependencies step by step.

Windows 11 ARM64 with Delphi in enterprises: the typical dependencies that determine success

In projects it becomes clear quickly: the bottleneck is not the GUI but the ecosystem. A structured dependency analysis saves weeks of trial and error.

Native DLLs and SDKs: the invisible risk

Many Delphi applications incorporate third-party DLLs: PDF generation, barcode/QR, image processing, encryption, proprietary communication libraries. Under ARM64 it is strict: A DLL must match the process architecture. Emulation only helps if the entire process remains x64. Once you want to go native, these libraries must be available as ARM64 or be replaced.

Practical tip for IT: Ask the software owner for a list of which DLLs reside in the installation directory and which are loaded via system paths. That is the basis for assessing vendor support and alternatives.

COM, Office automation and shell extensions

COM is often used in everyday enterprise operations without being named as such: Outlook integration, Excel export via automation, DMS clients, preview handlers in Explorer, context menu extensions. The problem under ARM64 is less COM itself and more the bitness coupling: In-process COM servers (DLL-based COM components) must match the architecture. Out-of-process COM (EXE-based servers) is more flexible because it can run in a separate process.

If your Delphi application, for example, uses an old 32-bit or 64-bit COM DLL, that is a blocker for native ARM64 execution. Emulated as x64 it can work — as long as all COM dependencies are also x64 and no ARM64-only parts intervene.

Printing, PDF and the driver landscape

Printing issues are a classic with platform transitions. Under Windows 11 ARM64 it is decisive whether the printer vendor provides ARM64 drivers or whether Universal Print/IPP class drivers (IPP is a standardized printing protocol) can be used. PDF printers, batch printing, label printing and specialist devices (e.g. thermal printers) can also depend on drivers that exist only for x64.

For IT management and administration the important consequence is: ARM64 rollouts must be aligned with the printing strategy. ‚The application does not print‘ is often ‚the driver does not exist‘ or ‚the printing pipeline is different‘.

Data access: FireDAC, ODBC/OLE DB and database clients

At the data level, a clear separation between protocol and client library is worthwhile. BDE-Ablosung mit nativer Anbindung can, depending on the database, work with native client libs or with drivers. If, for example, an Oracle client, an older PostgreSQL client or a specific ODBC driver is required, there must be an ARM64 version – or you rely on an architecture that encapsulates data access server-side (e.g. via REST-services or a Windows-/Windows- and Linux-services).

For stable operation this is a central lever: the less the desktop client is directly tied to database drivers and local database „stacks“, the easier ARM64 becomes. This also applies from a security perspective: database credentials, certificates and network rules can be managed more consistently server-side.

Crypto, Smartcards, Signatures, VPN, EDR

Many business processes today depend on cryptographic components: S/MIME, client certificates, smartcard middleware, signature cards, TLS inspection in proxies. In addition there are endpoint security solutions (EDR is Endpoint Detection and Response) and VPN clients. These components must be ARM64-capable, otherwise a „device is present but not allowed on the network“ problem arises.

For the Delphi application this means: if, for example, you use certificates from the Windows certificate store or perform TLS via system components, that is usually less critical than when a specific third-party crypto DLL is loaded into the process.

Decision matrix: emulation or native ARM64 porting?

Companies need a decision that reflects support and lifecycle reality. A simple yes/no question („Do we port?“) is rarely helpful. Better is a matrix that weighs dependencies and risks:

• Pure client using standard Windows APIs (file, network, printing via standard drivers): Emulation can be sufficient short-term; native ARM64 is the cleaner mid-term solution.
• Client with many native third-party DLLs (PDF, OCR, hardware): first check availability, then decide. A hybrid path is often sensible.
• Client with COM DLLs / shell extensions: expect architectural conflicts; evaluate out-of-process decoupling.
• Client with a direct DB-driver zoo: either consolidate drivers or shift data access into services.
• High regulation / signing / smartcard: verify ARM64 capability of the security and middleware chain early.

Important: Emulation is not a „second class“ solution, but it is an operational risk if you expect ARM64 devices in the fleet long-term. By the time of major updates, driver changes or security agent replacements you do not want to be stuck on a chain of special cases.

A robust migration path: From today to ARM64 without a big bang

For IT and project owners, a path is good when it is deployable in waves, has clear acceptance criteria and does not overload support. In Delphi landscapes, a five-step approach has proven effective.

Step 1: Inventory with an „operational lens“

Capture not only modules, but above all operational points:

• Which device classes: notebooks, Rugged Devices, terminals?
• Which peripherals: printers, scanners, card readers, labelers?
• Which integrations: Office, DMS, ERP, local services, browser components?
• Which installation form: MSI, Setup-EXE, ClickOnce, manual placement?
• Which permissions: admin required, local services, firewall rules?

This view quickly reveals whether “just one client” actually means five system dependencies.

Step 2: Compatibility check with a representative ARM64 pilot

The pilot should not be “the nicest device”, but a typical candidate from the target fleet. Consciously test the critical paths: printing in all variants, export/import, signing, offline/online, updates, tenant switching, proxy/VPN scenarios. Document deviations as operational incidents, not as developer bugs. This keeps prioritization clean.

Step 3: Reduce dependencies — start with those that have high support leverage

Typical measures that deliver a lot in day-to-day operations:

• Standardize the PDF/print path: move away from proprietary printer DLLs toward stable, tested pipelines.
• Decouple Office integration: instead of in-process add-ins, prefer export formats and server-side document generation.
• Consolidate DB access: a defined driver path instead of “ODBC depending on the workstation”.
• Encapsulate hardware attachment: where possible via external processes/services that can be updated independently.

Step 4: Modernize deployment and updatability

ARM64 is a good opportunity to clean up installation and updates. For enterprises what matters here are not features but rollback capability, reproducibility and policy compliance. Check:

• Packaging: MSI vs. MSIX (MSIX is Microsoft’s modern app package format providing clean install/uninstall and signing).
• Signing: Code signing (digital signature of EXE/DLL) reduces SmartScreen and EDR friction and is relevant for controlled rollouts.
• Configuration management: separation of program files and configuration, clear paths, no “hidden” registry dependencies.
• Update channels: pilot, Ring 1, Ring 2 — with telemetry/logging at application and operational levels.

Step 5: Native ARM64 where it truly pays off

Native ARM64 builds make sense when you (a) have dependencies under control and (b) plan to continue developing the application long-term. Typically this pays off for core clients used daily by many users and that you are modernizing anyway. For rarely used tools, x64 emulation can be an acceptable transition as long as support and security are adequate.

Architectural impulses: ARM64 as an opportunity to strengthen interfaces and services

Many Delphi landscapes historically grew as a “thick client”. That works, but it ties operations and updates more tightly to individual workstation configurations. ARM64 makes visible where this coupling becomes costly. A pragmatic modernization step is therefore often not “new UI”, but new interfaces.

More stability through server-side responsibilities

If critical logic, data access or document processes move into a central service (Windows- and Linux-services or Linux service, i.e. a background service without an interactive UI), you gain:

• consistent driver and library versions,
• more controllable security (certificates, secrets, network),
• reduced complexity on the client (ARM64, x64, and in future other platforms),
• clearer monitoring and logging points.

For IT decision-makers this is a real operational advantage: issues become reproducible on the server side more quickly, instead of being stuck on “a particular notebook”.

REST-API as a decoupling layer

A REST-API is not automatically “modern”, but it is a robust decoupling between clients and the backend. It clearly defines which data and actions are permitted, and can be secured cleanly (e.g. via tokens, certificates or SAML 2.0 as an identity standard in enterprise environments). For ARM64 this means: the client has to carry less “world knowledge” about databases, drivers and network details.

Even if you don’t migrate everything immediately: a small, well-scoped API module (e.g. document generation, license validation, master-data reconciliation) can remove dependencies from the client and thus reduce ARM64 risks.

Testing and quality: what you should check differently under ARM64

Many teams test desktop software primarily on functionality. For ARM64 you should test more from an operational perspective, because the failure patterns are different: not “incorrect calculation” but “component fails to load”, “driver missing”, “update fails”, “Office integration breaks”.

Checklist for ARM64-focused acceptance

• Install/Uninstall: clean, without leftovers, without admin workarounds.
• Update path: upgrade across multiple versions, rollback scenarios, signature verification.
• Logging: centralized logs, clear error codes for DLL load problems, traceable print paths.
• Performance: startup time, data operations, large lists/reports – measure separately under emulation and natively.
• Peripherals: printer profiles, special printing, scanner workflows, smartcard functions.
• Security: EDR/AV interaction, proxy/TLS, certificate store, least-privilege operation.

Documentation is important: if a problem arises because of missing ARM64 drivers, that is not “a bugfix in Delphi” but a procurement or standardization decision.

Operations and support: how to integrate ARM64 into everyday operations

In day-to-day operation what counts is how quickly support cases are resolved. For ARM64 it pays to proactively increase supportability:

Standardized device profiles and clear approvals

Define supported ARM64 models or at least minimum profiles (driver strategy, printing strategy, security-agent versions). A “runs on ARM64” claim without this qualifier leads to heterogeneous environments and therefore to incidents that are hard to reproduce.

Diagnostic capability within the application

Even without a developer focus, it makes sense to require this from the software: a system-info page that reports the architecture (x64 emulated vs. ARM64 native), important paths, versions of core components and printing configuration significantly reduces support times. This is not a “nice to have” but operational hygiene.

Licensing and dongles

If hardware dongles or older license drivers are involved, ARM64 quickly becomes critical. In many environments it makes sense to migrate licensing to network-capable or server-side mechanisms. This reduces dependency on drivers at endpoints and makes the fleet more interchangeable.

What does this mean for your Delphi strategy?

Delphi is often a stable building block for desktop clients and services in an enterprise context. Windows 11 ARM64 is not an argument „against Delphi“, but an argument for a cleaner encapsulation of dependencies and for an operations-oriented modernization: fewer local specialized drivers, fewer in-process components, clearer interfaces, better deployment.

If you are already on a modernization path today (e.g. BDE replacement, 64-bit migration, stronger REST integration, consolidated data access with FireDAC), then ARM64 is often „only“ an additional target that sharpens priorities. If your application, however, depends heavily on old drivers, proprietary DLLs and workstation-specific custom configurations, ARM64 is a sensible occasion to make these risks transparent and reduce them in a planned way.

Conclusion: ARM64 is less a porting project than an architecture and operations project

For enterprises, Windows 11 ARM64 is primarily a platform question in procurement, security and support. For Delphi-based business software, success is not decided by a compiler option but by the chain of drivers, DLLs, COM integrations, data access and update processes. A reliable approach is: first make dependencies and operational paths visible, then test with pilot devices, subsequently decouple selectively and professionalize deployment – and deliver native ARM64 builds where they provide long-term benefit and stability.

If you want to introduce Windows 11 ARM64 into your fleet and secure Delphi applications, peripherals and interfaces in a planned way, speak with us about a structured inventory and a realistic migration path:

In the technical domain, Delphi ARM64 Windows and X64 emulation Windows 11 also play an important role when integrations, data flows and ongoing development need to work together cleanly.

Discuss a project or modernization initiative with Net-Base.