Plan Windows 11 ARM64 early for Delphi applications

Windows 11 ARM64 is no longer a niche case for tech enthusiasts in everyday B2B operations. New notebook generations, longer battery runtimes, “always-on” scenarios and the growing demand for lightweight, mobile workplaces lead companies to purchase ARM64 clients – sometimes deliberately, sometimes incidentally via standard models in framework agreements. For teams with mature, custom software this is a clear signal: ARM64 must be considered early in technical planning, otherwise it becomes an expensive retrofit project later on.

For Delphi applications the central question is rarely “can Delphi compile this?”. In practice ARM64 rollouts almost always fail at the periphery: native DLLs, print/scan components, database drivers, report engines, COM integrations, setup routines, code signing or build pipelines that silently know only x64. That is why it makes sense to treat Windows 11 ARM64 as an architectural and operational requirement – not merely a platform feature.

This article shows which technical stumbling blocks typically occur with Delphi, how you can systematically identify the risks and which pragmatic migration paths have proven successful – from incrementally preparing individual modules to a clear target architecture with services and REST servers.

Why Windows 11 ARM64 is now an architectural topic

In many companies “Windows” has long been synonymous with x86/x64. That assumption is embedded in scripts, installers, third‑party components and sometimes even in the data model (e.g. paths, registry keys, driver interfaces). As soon as ARM64 clients appear, it becomes visible how much implicit knowledge is embedded in the system. And that is the economic core: late adjustments are not just “a few compiler flags”, they are a cleanup of assumptions that have solidified over years.

ARM64 becomes practically relevant in three situations in particular:

• Long-lived client software: line-of-business applications that are used and extended iteratively for 8–15 years. A new client platform during the lifecycle is more likely than a complete rewrite.
• Mixed fleets: field/service devices, management notebooks, BYOD-like scenarios or subsidiaries procuring different hardware.
• Security and compliance pressure: modern code signing, hardening, least-privilege, controlled updaters – installation and update processes are touched anyway. That is an efficient moment to integrate ARM64 as a side requirement.

The good news: if you are already working on Delphi modernization, 64-bit migration, decoupling data access or a service-oriented target architecture, you can often “carry along” Windows 11 ARM64 – provided it is early in the backlog and not first encountered on an ARM machine in support.

Delphi on ARM64: what is “easy”, what is “hard”?

Delphi projects vary widely: from pure VCL desktop clients to multi-layered systems with REST servers, Windows services, report workers, integration components and background jobs. For Windows 11 ARM64 it is decisive which parts really have to run natively on the client and which parts can reasonably be moved to services.

The compiler is rarely the main problem

If your own code is clean (no inline assembler, no old 32‑bit assumptions, no fragile pointer casts, no obsolete API calls), compiling for a new target platform is often feasible. Problems arise from:

• Third‑party components with native parts (DLLs, BPLs, C/C++ bridges)
• Drivers and device connectivity (printing, scanning, signature pads, dongles)
• Database access via ODBC/OLE DB/client libraries that are not ARM64-capable
• Reporting and office integration (COM automation, old export filters)
• Installer/updater that test only x64 or use hard‑coded paths

This makes Windows 11 ARM64 primarily an “ecosystem test”: how well is your software package decoupled from old platform assumptions?

VCL, FMX and UI dependencies

Many B2B domain applications are VCL-based and use UI components accumulated over years. That is not a problem per se – but the UI is often where dependencies concentrate: PDF printers, barcode generators, image libraries, browser controls, COM objects. For ARM64 the rule is: the more UI-proximate special components you use, the more important an early compatibility list becomes.

In multi-platform strategies (e.g. Windows + macOS) FMX often comes into play. Regardless of the framework, a robust strategy is to separate business logic and integrations from the UI. That pays off both for Delphi multi-platform and for Windows 11 ARM64.

Typical technical stumbling blocks (and how to detect them early)

In practice most ARM64 problems can be detected early if you inventory systematically and run an “ARM64 Readiness” check. It is essential to look not only at the Delphi code but everything that belongs to the product: installer, drivers, configuration, plugins, third‑party tools, update chain, support scripts.

1) Native DLLs, BPLs and mixed process landscapes

Many Delphi applications load additional DLLs: cryptography, CAD viewers, OCR, signatures, hardware SDKs, specialized parsers. On x64 it is often assumed silently that “there is a 64‑bit DLL”. For ARM64 this is different: you explicitly need ARM64 binaries or an architecture that moves the dependency out of the client.

Practical approach:

• Create a list of all loaded native modules (including those loaded indirectly via components).
• Classify them: “ARM64 available”, “x64-only”, “32-bit-only”, “unclear”.
• Assess whether the module really needs to be local or can be offloaded as a service.

A common finding: a single x64-only module blocks the entire ARM64 client. That is the moment when a clean layered or Layer-3 architecture becomes economically justified: keep UI/client lightweight and shift integrations into controlled server/service layers.

2) COM, Office automation and shell integrations

Word/Excel export, Outlook integration, Explorer context menus or DMS integrations often grew historically via COM. COM is not automatically “ARM64-ready”, especially when third‑party COM servers or add‑ins are only supplied as x64. Operating 32‑bit/64‑bit mixes (out‑of‑proc vs. in‑proc) quickly becomes complex.

Early clarifications:

• Which COM objects are used (ProgIDs/CLSID list)?
• In‑proc or out‑of‑proc? Are there ARM64 registrations?
• Can export be solved via server‑side libraries (e.g. document-based formats) instead of Office automation?

Often this is a modernization lever: move away from UI-coupled automation toward reproducible export services (e.g. PDF/Excel via a library) that can be used for Windows x64 as well as for ARM64 or even Linux servers.

3) Database access: ODBC, client libraries, legacy BDE

Data access is a frequent ARM64 interface because driver landscapes and client libraries play a role here. Old ODBC setups, proprietary database clients or local databases with historic access layers are particularly critical.

This is a classic for Delphi stacks: if there are still Borland BDE, old Paradox structures or hard‑to‑maintain driver chains involved, ARM64 becomes a catalyst. A BDE replacement and migration to BDE replacement with native connectivity and a clear DB driver strategy reduces platform risk significantly.

Concrete checkpoints:

• Which DBs are in use (SQL Server, PostgreSQL, MariaDB, Firebird, local engines)?
• Which drivers are used (ODBC, native client, BDE-Ablosung mit nativer Anbindung drivers, OLE DB)?
• Where are connection strings and DSNs stored (per user, per machine, in the installer)?
• Are there dependencies on 32‑bit ODBC drivers or old providers?

With SQL Server/ODBC an ARM64 client can work – but only if the driver chain and the installation routine are clean. This is not something you want to debug “in the field”.

4) Reporting, printing, scanning, PDF and output workflows

Output is often business‑critical in domain applications: delivery notes, labels, invoices, reports, meter readings, certificates, shipping labels. Many of these workflows rely on reporting components or specific printer/scan drivers.

On Windows 11 ARM64 the typical stumbling blocks are:

• Label printer/special drivers available only as x64
• Scanner software/SDKs without ARM64 support
• Old report engines with native preview/export modules
• PDF generation via “virtual printers” instead of a library

A robust approach is to standardize output workflows: generate PDF/Office formats via libraries, print via standardized interfaces, encapsulate special hardware access as much as possible. Where that is not possible, an early device/driver matrix for ARM64 is required.

5) Installer, updater, code signing and operations

Many ARM64 projects fail not because of the program, but because of delivery: setup detects the wrong architecture, does not install drivers, fails to register COM, sets incorrect paths or stumbles over code signing policies. Automatic updates (delta updates, self‑updaters) are also often highly architecture dependent.

Key operational questions:

• How is it installed (MSI, Inno Setup, custom updater)?
• How are dependencies installed (VC++ runtimes, drivers, certificates)?
• How is signing done (EXE, DLL, installer, driver packages)?
• How is testing performed: real ARM64 hardware or only assumptions?

For companies this is a governance topic: when Windows 11 ARM64 appears in the client fleet, deployment must be reproducible – including rollback, supportability and clear versioning.

Strategy: treat Windows 11 ARM64 as an early non‑functional requirement

The economically sensible approach is to treat ARM64 like a non‑functional requirement (NFR) – similar to performance, security or offline capability. That means: not only during a sprint “when it burns”, but as a defined constraint for architecture and supply chain.

ARM64 readiness check: inventory instead of gut feeling

A reliable check typically includes:

• Dependency inventory: all third‑party components, DLLs, drivers, SDKs, browser controls, crypto modules, reporting.
• Build/pipeline analysis: build targets, packaging, signing, artifact storage, version numbers, reproducibility.
• Installer/update chain: setup logic, prerequisites, registry/filesystem paths, policies, permissions.
• Operational model: support, logging, crash dumps, telemetry (if present), rollout plan.

The result should not be “ARM64: yes/no” but a prioritized list: which blockers exist, which modules are affected, which alternatives exist and what investment is realistic.

Decision matrix: native on ARM64 or decouple?

For every problematic dependency make a clear decision:

• ARM64-native replacement possible: upgrade, change vendor, switch to another library.
• Dependency can be offloaded: e.g. into an Windows service, a background worker or a central REST server.
• Dependency must remain local: e.g. because hardware is directly attached to the client. Then binding ARM64 hardware/driver approvals are required.

Offloading integrations is often the cleanest route: the client remains UI + business dialogues while complex integration logic runs in controlled services. That supports ARM64 as well as central updates, permission models and better testability.

Architecture patterns that stabilize ARM64 projects

If Windows 11 ARM64 is planned early, several architectural decisions can be made so they do not become costly to reverse later.

1) Clear layers: UI, business logic, integration, data access

Mature Delphi clients often have “everything in one process”: UI, business rules, data access, DMS integration, printing and export. That is maintainable as long as the platform remains stable. But once platform variants (ARM64, possibly macOS, possibly terminal servers) become relevant, the value of clear layering increases.

Pragmatic target picture:

• UI layer: minimal, testable, no direct driver/SDK dependencies.
• Business logic: as platform-neutral as possible, cleanly modeled.
• Integration layer: encapsulates COM, file formats, DMS/ERP connectors, device SDKs.
• Data access: consolidated (e.g. FireDAC), clear transaction boundaries, no scattered SQL fragments.

This is not academic – it saves real costs later: if only the integration layer is ARM64-problematic, the entire client does not need to be rebuilt.

2) Services and REST servers as stabilizing anchors

Many B2B systems benefit from running central functions as REST servers or as Windows-/Linux services: permission checks, document workflows, data validation, export, import, interfaces to ERP/DMS/CRM. If these functions run server‑side, client complexity is reduced significantly – and so is the ARM64 attack surface.

Typical partitions that have proven effective:

• Client: dialogs, display, offline logic (if needed), minimal local integrations.
• REST server: business operations, validation, multi‑tenant concerns, central logging.
• Worker/service: scheduled jobs, interface polling, report generation, batch exports.

That also fits modern operational models: a server‑side function is updated once – instead of on every ARM64 client individually.

3) One build system, multiple targets (x64 + ARM64) from the start

If ARM64 is a target, the build pipeline should reflect that. Not as “we’ll do a special build later”, but as standard: every release candidate builds reproducibly for x64 (and, if planned, ARM64), including signing and installer packaging.

Less important than the tooling is the discipline:

• Name artifacts clearly (architecture in package name/folder structure).
• Separate configuration values per target (paths, prerequisites, driver packages).
• Define smoke tests per architecture (startup, login, DB connection, print/PDF).

That makes ARM64 not a “big bang” but a controlled additional target.

Delphi modernization: ARM64 as an opportunity to reduce technical debt

Many companies use new platform requirements as an excuse for “everything new”. That is risky and often unnecessary. More economical is to use Windows 11 ARM64 as a constraint for incremental modernization: reduce technical debt where it blocks ARM64 or endangers delivery capability.

64‑bit and Unicode: don’t sweep old problems under the rug

If the codebase still contains 32‑bit assumptions or legacy from early Delphi versions, these resurface during platform changes. Although ARM64 does not automatically mean “Unicode”, many projects that take ARM64 seriously also ensure at the same time that Unicode is handled correctly, that 64‑bit paths are established and that memory/pointer issues are cleaned up.

The goal is not perfection but a reliable standard: code that can be built for new targets without repeatedly reproducing the same classes of errors.

BDE replacement and consolidated data access as an ARM64 enabler

Where historical access layers still exist (BDE, local Paradox data, mixed data access), consolidation is a lever with multiple effects: more maintainable code, more stable deployments, clearer driver strategy. With FireDAC access can be unified in many scenarios, including central parameter management, pooling strategies and robust error handling.

Important: a BDE replacement is not just “swap components”. It affects transaction logic, data types, sorting, filter semantics and partly the data model. That is why it should be planned – not executed as an emergency when ARM64 clients suddenly appear in the field.

Testing and QA: ARM64 is only plannable if it becomes measurable

Planning ARM64 early also means: it must be tested – not by exhaustively testing every feature, but by targeted risk testing of the critical chain. The most important step is to have a real ARM64 test environment. Emulation can help in specific cases but does not replace practice with real hardware, real drivers and real security policies.

Minimal ARM64 smoke test: what should be covered early

A pragmatic but effective smoke test set for each release candidate:

• Program start, login, basic UI functions
• DB connection (incl. authentication, certificates, DNS/proxy if relevant)
• An end‑to‑end core process (e.g. create an order, save, print/export)
• Updater/installer: fresh install and update across a version
• Logging/error dialogs: are diagnostics usable on ARM64?

That makes typical ARM64 blockers visible early: missing DLLs, wrong drivers, setup problems, unexpected permission requirements.

Diagnosability: crash dumps, logs, version transparency

When ARM64 is in the fleet, support cases will occur – simply because of new driver combinations. Therefore it pays to standardize diagnostics: clear build IDs, meaningful logs, reproducible installation and update paths. This is not specific to ARM64, but ARM64 makes deficits here expensive more quickly.

Rollout and operations: mixed fleets without chaos

Most companies will run mixed client fleets in the medium term: some x64, some ARM64. The key is to design that state deliberately.

Packaging: separate installers, clear detection, unambiguous download paths

In practice it works best when installers/packages are unambiguous: x64 package is x64, ARM64 package is ARM64. “One installer for everything” sounds convenient but quickly becomes complex (detection logic, prerequisites, driver paths, signing, repair installs). For controlled enterprise rollouts clarity is often the more robust route.

Update strategy: no special paths for ARM64

ARM64 should not be a special case in the update process. The goal is: same release cadence, same product version number, but separate artifacts. If ARM64 is only updated “manually”, deviations in the fleet arise that later drive up support costs.

Document integrations cleanly

Many ARM64 problems are not in your own code but in integrations: ERP connector, DMS client, signature service, scanner software, label printer. A maintained integration list with versions and architecture notes is sensible for B2B systems anyway – and makes ARM64 decisions transparent.

What companies should do now (without overreaction)

Planning Windows 11 ARM64 early does not mean rebuilding everything immediately. It means answering the right questions early and eliminating blockers while the effort is predictable. A proven approach is:

• 1) Inventory (2–10 days depending on system size): dependencies, installer, drivers, data access, COM, reporting.
• 2) Target picture and path: what must be native on the client? What becomes service/REST? Which components will be replaced?
• 3) Proof of feasibility: a runnable ARM64 build with installer and an end‑to‑end use case.
• 4) Incremental hardening: remaining features, tests, update chain, diagnosability.

This way you avoid an isolated “ARM64 project” that runs for months, and instead create a controlled extension of delivery capability.

Conclusion: Windows 11 ARM64 is not hype but an early indicator of technical maturity

Windows 11 ARM64 will become reality for many companies – through hardware procurement, mobility requirements or standardization. For Delphi applications the real challenge is not source code alone but the whole system: dependencies, installation and update processes, integrations and drivers. Those who plan for ARM64 early can resolve these points structurally instead of “patching” under time pressure later.

In the end ARM64 is a useful litmus test: how well is your application decoupled, testable and deliverable? If you answer this question now, you gain not only platform options but also a more stable foundation for modernization, services, REST architectures and long‑term maintainability.

Contact Net-Base Software GmbH, if you want to reliably assess Windows 11 ARM64 in your Delphi roadmap and implement it with a clear technical path.