Windows 11 ARM64 is no longer just a special case for tech enthusiasts in everyday B2B. New notebook generations, longer battery life, “always-on” scenarios and the growing demand for light, mobile workplaces mean that companies are buying ARM64 clients – sometimes deliberately, sometimes incidentally via standard models under framework contracts. For teams with established custom software this is a clear message: ARM64 must be included early in technical planning, otherwise it will become an expensive retrofit project later.
With 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 only know x64. That is precisely why it pays to treat Windows 11 ARM64 as an architectural and operational requirement – not just a platform feature.
This article shows which technical stumbling blocks typically occur with Delphi, how to systematically identify the risks and which pragmatic migration paths have proven successful – from stepwise adaptation of individual modules to a clear target architecture with services and REST servers.
Why Windows 11 ARM64 is now an architecture topic
For a long time in many companies “Windows” was 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, how much implicit knowledge is in the system becomes visible. And that is the economic core: late adaptations are not just “a few compiler flags”, but a cleanup of assumptions that have solidified over years.
ARM64 becomes practically relevant in three situations in particular:
- Client software with a long life span: Domain applications that are used and extended iteratively for 8–15 years. A new client platform in the middle of the lifecycle is more likely than a complete rebuild.
- Mixed fleets: field/service staff, management notebooks, BYOD-adjacent scenarios or subsidiaries that procure different hardware.
- Security and compliance pressure: modern code signing, hardening, least privilege, controlled updaters – installation and update processes are touched anyway. That is exactly when ARM64 is cheap to integrate as an additional requirement.
The good news: If you are already working on Delphi modernization, a 64-bit migration, decoupling data access or a service-oriented target architecture, you can often “bring along” Windows 11 ARM64 – provided it is early on the backlog and not only noticed when the first ARM machine reaches support.
Delphi on ARM64: what is “easy”, what is “hard”?
Delphi projects vary widely: from pure VCL desktop clients to multilayered systems with REST servers, Windows services, report workers, integration components and background jobs. For Windows 11 ARM64 it is crucial which parts really need 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 outdated 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 only test x64 or use hard-wired paths
Thus Windows 11 ARM64 is 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 that have grown over years. That is not per se a problem – but the UI is often where dependencies concentrate: PDF printers, barcode generators, image libraries, browser controls, COM objects. For ARM64: the more UI-related 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 domain 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 perform an “ARM64 readiness” check. It is crucial not only to look at the Delphi code but at 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, special parsers. On x64 it is often silently assumed that “there is a 64-bit DLL”. For ARM64 it is different: you explicitly need ARM64 binaries or an architecture that removes this dependency from the client.
Practical approach:
- Create a list of all loaded native modules (also indirectly via components).
- Classify: “ARM64 available”, “x64-only”, “32-bit-only”, “unclear”.
- Assess whether the module really needs to be local or can be moved to a service.
A common finding: a single x64-only module blocks the entire ARM64 client. That is the moment when a clean layering or a Layer-3 architecture becomes economically viable: keep the UI/client light, move integrations into controlled server/service layers.
2) COM, Office automation and shell integrations
In many companies Word/Excel export, Outlook integration, Explorer context menus or DMS integrations have grown historically via COM. COM is not automatically “ARM64-ready”, especially when third-party COM servers or add-ins are only shipped as x64. Running 32-bit/64-bit mixes (out-of-proc vs. in-proc) also becomes complex quickly.
Early clarification:
- Which COM objects are used (ProgIDs/CLSID list)?
- In-proc or out-of-proc? Are there ARM64 registrations?
- Can exports be done 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 to reproducible export services (e.g. PDF/Excel via a library) that can be used on Windows x64 as well as ARM64 or even Linux servers.
3) Database access: ODBC, client libraries, legacy BDE
Data access is a common ARM64 interface because driver landscapes and client libraries come into play. Old ODBC setups, proprietary database clients or local databases with historic access layers are particularly critical.
For Delphi stacks this is a classic: if Borland BDE, old Paradox structures or hard-to-maintain driver chains are still in use, ARM64 becomes a catalyst. A BDE replacement and switching to a BDE replacement with native access and a clear DB driver strategy reduces platform risks 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 located (per user, per machine, in the installer)?
- Are there dependencies on 32-bit ODBC drivers or old providers?
Especially with SQL Server/ODBC an ARM64 client can work – but only if the driver chain and 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 depend on reporting components or specific printer/scanner 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 libraries
A robust approach is to standardize output workflows: generate PDF/Office formats via libraries, print through standardized interfaces, and encapsulate special hardware access as much as possible. Where that is not possible, an early device/driver matrix for ARM64 is needed.
5) Installer, updater, code signing and operations
Many ARM64 projects don’t fail because of the program, but because of delivery: the setup detects the architecture incorrectly, doesn’t install drivers, doesn’t register COM, sets wrong paths or fails due to code signing policies. Automatic updates (delta updates, self-updaters) are also often highly architecture-dependent.
Important operational questions:
- How is installation performed (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 done: real ARM64 hardware or just assumptions?
For companies this is a governance issue: when Windows 11 ARM64 appears in the client fleet, deployment must be reproducible – including rollback, supportability and clear versioning.
Strategy: treat Windows 1 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. This means: not only addressing it in the sprint “when it burns”, but defining it as a guideline for architecture and the 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, versioning, 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, what alternatives exist and what investment is realistic.
Decision matrix: native on ARM64 or decouple?
For each problematic dependency a clear decision is needed:
- ARM64-native replacement possible: upgrade, change vendor, switch to another library.
- Dependency can be outsourced: e.g. into a 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 needed.
For integrations outsourcing is often the cleanest approach: the client stays UI + dialogs, while complex integration logic runs in controlled services. This also supports ARM64-related aspects such as central updates, permission concepts and improved testability.
Architecture patterns that make ARM64 projects stable
If Windows 11 ARM64 is planned early, several architectural decisions can be made so that they don’t have to be expensively reversed later.
1) Clear layers: UI, domain logic, integration, data access
Grown 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 server) become relevant, the value of clear layering increases.
Pragmatic target picture:
- UI layer: minimal, testable, no direct driver/SDK dependencies.
- Domain logic: as platform-neutral as possible, well 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 “academia” but saves real costs later: if only the integration layer is ARM64-problematic, you don’t have to rebuild the entire client.
2) Services and REST servers as stabilizing anchors
Many B2B systems gain 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. When these functions run server-side, client complexity is greatly reduced – and so is the ARM64 attack surface.
Typical splits that have proven successful:
- Client: dialogs, display, offline logic (if needed), minimal local integrations.
- REST server: domain operations, validation, tenancy, central logging.
- Worker/service: scheduled jobs, interface polling, report generation, batch exports.
This also fits modern operational models: a function running server-side 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 the standard: every release-candidate version builds reproducibly for x64 (and, if planned, ARM64), including signing and installer packaging.
Less important than the tooling is the consistency:
- Name artifacts clearly (architecture in package name/folder structure).
- Separate configuration values per target (paths, prerequisites, driver packages).
- Define smoke tests per architecture (start, login, DB connection, print/PDF).
This makes ARM64 not a “big bang” but a controlled additional target.
Delphi modernization: ARM64 as an opportunity to pay down technical debt
Many companies use new platform requirements as an excuse for “everything new”. That is risky and often unnecessary. Much more economical is to use Windows 11 ARM64 as a guideline for stepwise modernization: reduce technical debt where it blocks ARM64 or endangers deliverability.
64-bit and Unicode: don’t postpone old problem areas
If the codebase still contains 32-bit assumptions or legacy from early Delphi versions, they will resurface when switching platforms. Even if ARM64 does not automatically mean “Unicode”: many projects that seriously tackle ARM64 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 reproducing the same class of errors each time.
BDE replacement and consolidated data access as an ARM64 enabler
Where historical access layers remain (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 in part the data model. That is why it should be planned – not used as an emergency measure when ARM64 clients suddenly appear in the field.
Testing and quality assurance: ARM64 is only plannable if it becomes measurable
Planning for ARM64 early also means: it must be tested – not by fully 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 individual cases, but it 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 every release candidate version:
- Program start, login, basic UI functions
- DB connection (including authentication, certificates, DNS/proxy if relevant)
- An end-to-end core process (e.g. create an order, save, print/export)
- Updater/installer: fresh installation and update across a version
- Logging/error dialogs: are diagnostics usable on ARM64?
This makes typical ARM64 blockers visible early: missing DLLs, wrong drivers, setup problems, unexpected permission requirements.
Diagnostic capability: crash dumps, logs, version transparency
When ARM64 is in the fleet, support cases will come – simply because of new driver constellations. That is why it pays to standardize diagnostics: clear build IDs, meaningful logs, reproducible installation and update paths. This is not specific to ARM64, but ARM64 makes deficiencies here expensive very 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 manage this state consciously.
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 (check logic, prerequisites, driver paths, signing, repair installation). For controlled enterprise rollouts clarity is often the more robust approach.
Update strategy: no special paths for ARM64
ARM64 should not be a special case in the update process. The goal is: same release frequency, same functional version number, but separate artifacts. If ARM64 is only updated “manually”, divergences 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 version levels and architecture notes is useful for B2B systems anyway – and makes ARM64 decisions transparent.
What companies should do now (without overreaction)
Planning for Windows 11 ARM64 early does not mean immediately rebuilding everything. It means asking the right questions early and eliminating blockers while the effort is still manageable. 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 are replaced?
- 3) Proof of feasibility: a working ARM64 build with installer and an end-to-end use case.
- 4) Stepwise hardening: remaining functions, tests, update chain, diagnostic capability.
This way you don’t create an isolated “ARM64 project” that runs for months, but a controlled extension of delivery capability.
Conclusion: Windows 11 ARM64 is not a hype but an early indicator of technical maturity
Windows 11 ARM64 will simply become reality for many companies – through hardware procurement, mobility requirements or standardization. For Delphi applications the real challenge is not the source code alone, but the whole system of dependencies, installation and update processes, integrations and drivers. Those who plan ARM64 early can address these points in a structured way instead of “patching” them later under time pressure.
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 a reliable assessment of Windows 11 ARM64 in your Delphi roadmap and a clear technical path to implement it.