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

Windows devices with an ARM64 CPU (ARM64 is a 64‑bit processor architecture, known from mobile SoCs and increasingly from business notebooks) are no longer just „oddities“ in many companies. They arrive via standardized notebook fleets, longer battery runtimes, new hardware security features and 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 continued development?

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

Why Windows 11 ARM64 is becoming relevant now

Windows on ARM is not new, but the conditions have changed: devices are available in the business environment, Windows 11 brings a significantly more mature x64 emulation, and software vendors increasingly ship 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-oriented software solutions the CPU itself is less the issue than the peripheral and integration reality: 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 arises — and often „the application“ is held responsible.

Context: What does ARM64 technically mean for Delphi applications?

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

1) Native ARM64 execution

The application and all native libraries (DLLs) are available as ARM64. This is the cleanest long-term option because it makes performance and stability predictable and avoids emulation edge cases. It is, however, 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 whether something „runs“ or „does not run“.

3) Hybrid: ARM64 client, decouple x64 components

A 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 utility. That is less elegant than „everything native“, but often the most economical route to secure operations and modernize dependencies step by step.

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

Projects quickly show: 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 link third-party DLLs: PDF generation, barcode/QR, image processing, encryption, proprietary communications libraries. Under ARM64 it is strict: A DLL must match the process architecture. Emulation only helps if the entire process remains x64. As soon as you want to run natively, these libraries must be available as ARM64 or be replaced.

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

COM, Office automation and shell extensions

COM is often used in enterprise day-to-day operations without being named as such: Outlook integration, Excel export via automation, DMS clients, preview handlers in Explorer, context menu extensions. The problem on ARM64 is less COM itself than the bitness coupling: in-process COM servers (DLL-based COM components) must share the same 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 in platform migrations. On Windows 11 ARM64 it’s 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 specialty 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 doesn’t print“ is often „the driver doesn’t exist“ or „the printing pipeline is different“.

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

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

For stable operation this is a central lever: the less the desktop client is tied directly 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 if a specific third-party crypto DLL is loaded in the process.

Decision matrix: emulation or native ARM64 porting?

Companies need a decision that reflects support and lifecycle reality. A simple yes/no question („Are we porting?“) 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 suffice in the short term; native ARM64 is the clean mid-term solution.
• Client with many native third-party DLLs (PDF, OCR, hardware): first check availability, then decide. Often a hybrid path makes sense.
• Client with COM DLLs / shell extensions: expect architectural conflicts; consider out-of-process decoupling.
• Client with a direct DB-driver zoo: either consolidate drivers or shift data access into services.
• High regulation/signature/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 your fleet in the long term. By the time of major updates, driver changes or security-agent swaps, you do not want to be left with 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 can be rolled out in waves, has clear acceptance criteria and does not overwhelm support. In Delphi landscapes, a five-step approach has proven effective.

Step 1: inventory with an „operations perspective“

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 copy?
• Which permissions: Is 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 the highest support leverage

Typical measures that bring substantial benefit in day-to-day operations:

• Standardize the PDF/printing 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 per workstation“.
• Encapsulate hardware integration: Where possible via external processes/services that can be updated independently.

Step 4: Modernize deployment and update capability

ARM64 is a good occasion to clean up installation and updates. For companies 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 with 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 makes sense

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

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

Many Delphi landscapes have historically grown as „thick clients.“ 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.

Greater stability through server-side responsibilities

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

• consistent driver and library versions,
• better controlled 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 genuine operational advantage: problems become reproducible server-side faster, instead of being stuck on „a specific notebook“.

REST-API as a decoupling layer

An 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 allowed, 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 must carry less „world knowledge“ about databases, drivers and network details.

Even if you do not migrate everything immediately: a small, well-bounded API component (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 for ARM64

Many teams test desktop software primarily for functionality. With ARM64 you should emphasize operational testing more, 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: upgrades across multiple versions, rollback scenario, signature verification.
• Logging: centralized logs, clear error codes for DLL load issues, 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 due to missing ARM64 drivers, that is not a „bugfix in Delphi“, but a procurement or standardization decision.

Operations and support: How to integrate ARM64 into daily operations

In day-to-day operations what counts is how quickly support cases are resolved. For ARM64 it is worthwhile 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“ statement without this constraint leads to heterogeneous environments and thus to hard-to-reproduce incidents.

Diagnostic capability in the application

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

Licensing and dongles

When hardware dongles or older license drivers are involved, ARM64 quickly becomes critical. In many environments it makes sense to move licensing to network-capable or server-side mechanisms. This reduces dependence on drivers on 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 special drivers, fewer in-process components, clearer interfaces, better deployment.

If you are already on a modernization path today (e.g. BDE replacement, 64‑bit transition, 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 special 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 companies, 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 in a targeted way 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, controlled way, talk to us about a structured inventory and a realistic migration path:

In the technical context, Delphi ARM64 Windows and X64-Emulation Windows 11 also play an important role when integrations, data flows and ongoing development need to interoperate cleanly.

Discuss a project or modernization initiative with Net-Base.