Windows 11 ARM64 mit Delphi in Unternehmen: Optionen, Risiken und ein belastbarer Migrationspfad

Windows-Geräte mit ARM64-CPU (ARM64 ist eine 64‑Bit-Prozessorarchitektur, bekannt aus mobilen SoCs und zunehmend auch aus Business-Notebooks) sind in vielen Unternehmen nicht mehr nur „Exoten“. Sie kommen über standardisierte Notebook-Flotten, längere Akkulaufzeiten, neue Sicherheitsfunktionen in der Hardware und eine strategische Diversifizierung der Lieferkette. Spätestens wenn Fachbereiche neue Geräte beschaffen oder OEMs bestimmte Modelle nur noch als Windows on ARM anbieten, stellt sich für IT-Verantwortliche die praktische Frage: Wie verhält sich unsere Delphi-basierte Business-Software unter Windows 11 ARM64 – und wie sichern wir Betrieb, Support und Weiterentwicklung?

Der Kernpunkt ist: Windows 11 ARM64 mit Delphi in Unternehmen ist weniger eine reine Entwicklungsfrage als eine Frage von Abhängigkeiten, Deployment-Strategien, Treibern, Schnittstellen und dem realen Verhalten im Feld. In der Praxis gibt es drei Wege: Weiterbetrieb über Emulation, native ARM64-Builds oder ein Übergangsmodell, das Risiken kontrolliert reduziert. Dieser Beitrag ordnet die typischen Stolpersteine ein und zeigt einen belastbaren Pfad, der in IT-Planung, Rollout und Betrieb funktioniert – ohne „Alles neu“-Reflex.

Warum Windows 11 ARM64 jetzt relevant wird

Windows on ARM ist nicht neu, aber die Rahmenbedingungen haben sich geändert: Die Geräte sind im Business-Umfeld verfügbar, Windows 11 bringt eine deutlich ausgereiftere x64-Emulation, und Softwarehersteller liefern immer häufiger ARM64-Varianten. Für Unternehmen heißt das: ARM64 taucht nicht als einmaliges Pilotprojekt auf, sondern als Plattform, die in Beschaffungs- und Lebenszyklusplanungen eingeht.

Für prozessnahe Softwarelösungen ist dabei weniger die CPU selbst das Problem, sondern die Peripherie- und Integrationsrealität: Druck, Signaturkarten, Scanner, Office-Add-ins, COM-Komponenten (COM ist Microsofts Komponentenmodell zur Integration von Anwendungen und Bibliotheken), Shell-Erweiterungen, VPN-Clients oder Security-Agenten. Wenn davon etwas nicht ARM64-tauglich ist, entsteht Supportaufwand – und häufig wird dann „die Anwendung“ verantwortlich gemacht.

Einordnung: Was bedeutet ARM64 technisch für Delphi-Anwendungen?

Delphi-Anwendungen im Unternehmensumfeld sind oft klassische Windows-Desktop-Clients (häufig VCL, also die Visual Component Library für Windows-GUIs) mit Datenbankzugriff (z. B. über BDE-Ablösung mit nativer Anbindung, Delphis Datenzugriffsschicht) und einer Mischung aus lokalen und entfernten Integrationen. Unter Windows 11 ARM64 ergeben sich dabei drei Ausführungsarten:

1) Native ARM64-Ausführung

Die Anwendung und alle nativen Bibliotheken (DLLs) liegen als ARM64 vor. Das ist langfristig die sauberste Option, weil sie Performance und Stabilität planbar macht und Emulationsrandbedingungen vermeidet. Sie ist aber nur dann realistisch, wenn alle nativen Abhängigkeiten mitziehen: Datenbanktreiber, Druck/Preview, PDF-Engine, Kryptobibliotheken, OCR/Scan-SDKs, Hardware-Dongle-Treiber etc.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 kann x64-Anwendungen emulieren. Für viele reine Desktop-Clients funktioniert das überraschend gut. In der Praxis ist Emulation aber keine „Freikarte“: Sobald Treiber, Shell-Integrationen oder In-Process-Komponenten (DLLs, die in den Prozess geladen werden) beteiligt sind, kommt es auf die Architektur an. Ein x64-Prozess kann keine ARM64-DLL laden und umgekehrt. Genau diese Grenze entscheidet häufig über „läuft“ oder „läuft nicht“.

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

Ein Übergangspfad ist, kritische x64-Komponenten aus dem Prozess herauszuziehen: z. B. als externen Service, als REST-Backend (REST ist ein HTTP-basiertes Schnittstellenmodell) oder als separates Hilfsprogramm. Das ist weniger elegant als „alles nativ“, aber oft die wirtschaftlichste Route, um Betrieb zu sichern und Abhängigkeiten schrittweise zu modernisieren.

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

In Projekten zeigt sich schnell: Nicht das GUI ist der Engpass, sondern das Ökosystem. Eine strukturierte Abhängigkeitsanalyse spart hier Wochen an Trial-and-Error.

Native DLLs und SDKs: Das unsichtbare Risiko

Viele Delphi-Anwendungen binden Drittanbieter-DLLs ein: PDF-Erzeugung, Barcode/QR, Bildverarbeitung, Verschlüsselung, proprietäre Kommunikationsbibliotheken. Unter ARM64 gilt hart: Eine DLL muss zur Prozessarchitektur passen. Emulation hilft nur, wenn der gesamte Prozess x64 bleibt. Sobald man nativ gehen will, müssen diese Bibliotheken als ARM64 vorliegen oder ersetzt werden.

Praxis-Tipp für IT: Lassen Sie sich von der Softwareverantwortung eine Liste geben, welche DLLs im Installationsverzeichnis liegen und welche über Systempfade geladen werden. Das ist die Grundlage, um Herstellerfähigkeit und Alternativen zu bewerten.

COM, Office-Automation und Shell-Erweiterungen

COM wird im Unternehmensalltag oft genutzt, ohne dass es so benannt wird: Outlook-Integration, Excel-Export über Automation, DMS-Clients, Vorschau-Handler im Explorer, Kontextmenü-Erweiterungen. Das Problem unter ARM64 ist weniger COM selbst, sondern die Bitness-Kopplung: In-Process-COM-Server (DLL-basierte COM-Komponenten) müssen architekturgleich sein. Out-of-Process-COM (EXE-basierte Server) ist flexibler, weil er in einem separaten Prozess laufen kann.

Wenn Ihre Delphi-Anwendung z. B. eine alte 32‑Bit- oder 64‑Bit-COM-DLL nutzt, ist das bei nativer ARM64-Ausführung ein Blocker. Emuliert als x64 kann es funktionieren – solange alle COM-Abhängigkeiten ebenfalls x64 sind und keine ARM64-only-Teile hineingreifen.

Druck, PDF und Treiberlandschaft

Druckprobleme sind bei Plattformwechseln der Klassiker. Unter Windows 11 ARM64 ist entscheidend, ob der Druckerhersteller ARM64-Treiber bereitstellt oder ob Universal Print/IPP-Klassen-Treiber (IPP ist ein standardisiertes Druckprotokoll) genutzt werden können. Auch PDF-Drucker, Stapeldruck, Etikettendruck und Spezialgeräte (z. B. Thermodrucker) können an Treibern hängen, die es nur für x64 gibt.

Für IT-Leitung und Administration ist die wichtige Konsequenz: ARM64-Rollouts müssen mit der Druckstrategie abgestimmt werden. „Die Anwendung druckt nicht“ ist oft „der Treiber existiert nicht“ oder „die Druckpipeline ist anders“.

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

Auf der Datenebene lohnt eine saubere Trennung zwischen Protokoll und Clientbibliothek. BDE-Ablösung mit nativer Anbindung kann je nach Datenbank mit nativen Clientlibs oder mit Treibern arbeiten. Wenn z. B. ein Oracle-Client, ein älterer PostgreSQL-Client oder ein spezifischer ODBC-Treiber benötigt wird, muss es diesen als ARM64 geben – oder Sie setzen auf eine Architektur, die den Datenzugriff serverseitig kapselt (z. B. über REST-Services oder einen Windows-/Windows- und Linux-Services).

Für stabilen Betrieb ist das ein zentraler Hebel: Je weniger der Desktop-Client direkt an Datenbanktreiber und lokale Datenbank-„Stacks“ gebunden ist, desto leichter wird ARM64. Das gilt auch im Sinne von Security: Datenbankzugangsdaten, Zertifikate und Netzwerkregeln lassen sich serverseitig konsistenter verwalten.

Krypto, Smartcards, Signaturen, VPN, EDR

Viele Business-Prozesse hängen heute an kryptografischen Komponenten: S/MIME, Client-Zertifikate, Smartcard-Middleware, Signaturkarten, TLS-Inspection in Proxies. Dazu kommen Endpoint-Security-Lösungen (EDR ist Endpoint Detection and Response) und VPN-Clients. Diese Komponenten müssen ARM64-fähig sein, sonst entsteht ein „Gerät ist da, darf aber nicht ins Netz“-Problem.

Für die Delphi-Anwendung heißt das: Wenn Sie z. B. Zertifikate aus dem Windows-Zertifikatsspeicher nutzen oder TLS über Systemkomponenten machen, ist das meist unkritischer, als wenn eine spezifische Drittanbieter-KryptodLL im Prozess hängt.

Entscheidungsmatrix: Emulation oder native ARM64-Portierung?

Unternehmen brauchen eine Entscheidung, die Support- und Lebenszyklusrealität abbildet. Eine einfache Ja/Nein-Frage („Portieren wir?“) ist selten hilfreich. Besser ist eine Matrix, die Abhängigkeiten und Risiken gewichtet:

• Reiner Client mit Standard-Windows-APIs (Datei, Netzwerk, Druck über Standardtreiber): Emulation kann kurzfristig reichen; native ARM64 ist mittelfristig sauber.
• Client mit vielen nativen Drittanbieter-DLLs (PDF, OCR, Hardware): erst Verfügbarkeit prüfen, dann entscheiden. Häufig Hybridpfad sinnvoll.
• Client mit COM-DLLs / Shell-Erweiterungen: Architekturkonflikte erwarten; Out-of-Process-Entkopplung prüfen.
• Client mit direktem DB-Treiber-Zoo: entweder Treiber konsolidieren oder Datenzugriff in Services verlagern.
• Hohe Regulierung/Signatur/Smartcard: ARM64-Fähigkeit der Security- und Middleware-Kette früh verifizieren.

Wichtig: Emulation ist keine „zweite Klasse“, aber sie ist ein Betriebsrisiko, wenn Sie langfristig Gerätearm64 in der Flotte sehen. Spätestens bei größeren Updates, Treiberwechseln oder Security-Agent-Wechseln möchten Sie nicht auf einer Kette von Sonderfällen sitzen.

Ein belastbarer Migrationspfad: Von heute nach ARM64 ohne Big Bang

Für IT und Projektverantwortliche ist ein Pfad dann gut, wenn er in Wellen ausrollbar ist, klare Abnahmekriterien hat und den Support nicht überfordert. In Delphi-Landschaften hat sich ein Vorgehen in fünf Schritten bewährt.

Schritt 1: Bestandsaufnahme mit „Betriebsbrille“

Erfassen Sie nicht nur Module, sondern vor allem Betriebspunkte:

• Welche Geräteklassen: Notebooks, Rugged Devices, Terminals?
• Welche Peripherie: Drucker, Scanner, Kartenleser, Labeler?
• Welche Integrationen: Office, DMS, ERP, lokale Dienste, Browser-Komponenten?
• Welche Installationsform: MSI, Setup-EXE, ClickOnce, manuelle Ablage?
• Welche Rechte: Admin nötig, lokale Dienste, Firewall-Regeln?

Diese Sicht macht schnell sichtbar, ob „nur ein Client“ in Wahrheit fünf Systemabhängigkeiten bedeutet.

Schritt 2: Kompatibilitätscheck mit repräsentativem ARM64-Pilot

Der Pilot sollte nicht „das schönste Gerät“ sein, sondern ein typischer Kandidat aus der Ziel-Flotte. Testen Sie dabei bewusst die kritischen Pfade: Druck in allen Varianten, Export/Import, Signatur, Offline/Online, Updates, Mandantenumschaltung, Proxy/VPN-Szenarien. Dokumentieren Sie Abweichungen als Betriebsvorfälle, nicht als Entwickler-Bugs. So bleibt die Priorisierung sauber.

Schritt 3: Abhängigkeiten reduzieren – zuerst die mit hohem Supporthebel

Typische Maßnahmen, die im Alltag viel bringen:

• PDF-/Druckpfad standardisieren: Weg von proprietären Drucker-DLLs, hin zu stabilen, getesteten Pipelines.
• Office-Integration entkoppeln: statt In-Process-Add-ins lieber Exportformate und serverseitige Dokumentgenerierung prüfen.
• DB-Zugriff konsolidieren: ein definierter Treiberweg statt „ODBC je nach Arbeitsplatz“.
• Hardware-Anbindung kapseln: wenn möglich über externe Prozesse/Services, die separat aktualisiert werden können.

Schritt 4: Deployment und Updatefähigkeit modernisieren

ARM64 ist ein guter Anlass, Installation und Updates zu bereinigen. Für Unternehmen zählen hier nicht Features, sondern Rollback-Fähigkeit, Reproduzierbarkeit und Policy-Konformität. Prüfen Sie:

• Paketierung: MSI vs. MSIX (MSIX ist Microsofts modernes App-Paketformat mit sauberer Installation/Deinstallation und Signatur).
• Signierung: Code Signing (digitale Signatur von EXE/DLL) reduziert SmartScreen- und EDR-Reibung und ist für kontrollierte Rollouts relevant.
• Konfigurationsmanagement: Trennung von Programmdateien und Konfiguration, klare Pfade, keine „versteckten“ Registry-Abhängigkeiten.
• Updatekanäle: Pilot, Ring 1, Ring 2 – mit Telemetrie/Logging auf Anwendungs- und Betriebsebene.

Schritt 5: Native ARM64 dort, wo es sich wirklich lohnt

Native ARM64-Builds sind dann sinnvoll, wenn Sie (a) die Abhängigkeiten im Griff haben und (b) die Anwendung langfristig weiterentwickeln. Typisch lohnt sich das bei Kernclients, die viele Anwender täglich nutzen und die Sie ohnehin modernisieren. Bei selten genutzten Tools kann x64-Emulation ein akzeptabler Übergang sein, solange Support und Security mitspielen.

Architekturimpulse: ARM64 als Anlass, Schnittstellen und Services zu stärken

Viele Delphi-Landschaften sind historisch als „dicker Client“ gewachsen. Das funktioniert, aber es bindet Betrieb und Updates stärker an einzelne Arbeitsplatzkonfigurationen. ARM64 macht sichtbar, wo diese Kopplung teuer wird. Ein pragmatischer Modernisierungsschritt ist daher oft nicht „UI neu“, sondern Schnittstellen neu.

Mehr Stabilität durch serverseitige Verantwortlichkeiten

Wenn kritische Logik, Datenzugriff oder Dokumentprozesse in einen zentralen Dienst wandern (Windows- und Linux-Services oder Windows- und Linux-Services, also ein Hintergrunddienst ohne interaktives UI), gewinnen Sie:

• einheitliche Treiber- und Bibliotheksstände,
• besser kontrollierbare Security (Zertifikate, Secrets, Netzwerk),
• geringere Komplexität auf dem Client (ARM64, x64, künftig auch andere Plattformen),
• klarere Monitoring- und Logging-Punkte.

Für IT-Entscheider ist das ein echter Betriebsvorteil: Probleme werden serverseitig schneller reproduzierbar, statt auf „einem speziellen Notebook“ zu hängen.

REST-API als Entkopplungsschicht

Eine REST-API ist nicht automatisch „modern“, aber sie ist eine robuste Entkopplung zwischen Clients und Backend. Sie definiert klar, welche Daten und Aktionen erlaubt sind, und kann sauber abgesichert werden (z. B. über Tokens, Zertifikate oder SAML 2.0 als Identitätsstandard in Unternehmensumgebungen). Für ARM64 bedeutet das: Der Client muss weniger „Weltwissen“ über Datenbanken, Treiber und Netzwerkdetails tragen.

Auch wenn Sie nicht sofort alles umstellen: Schon ein kleiner, gut begrenzter API-Baustein (z. B. Dokumentgenerierung, Lizenzprüfung, Stammdatenabgleich) kann Abhängigkeiten aus dem Client entfernen und damit ARM64-Risiken reduzieren.

Test und Qualität: Was Sie unter ARM64 anders prüfen sollten

Viele Teams testen Desktop-Software primär funktional. Bei ARM64 sollten Sie stärker betrieblich testen, weil die Fehlerbilder anders sind: nicht „falsche Berechnung“, sondern „Komponente lädt nicht“, „Treiber fehlt“, „Update scheitert“, „Office-Integration bricht“.

Checkliste für ARM64-nahe Abnahme

• Install/Uninstall: sauber, ohne Reste, ohne Admin-Workarounds.
• Updatepfad: Upgrade über mehrere Versionen, Rollback-Szenario, Signaturprüfung.
• Logging: zentrale Logs, klare Fehlercodes bei DLL-Ladeproblemen, nachvollziehbare Druckpfade.
• Performance: Startzeit, Datenoperationen, große Listen/Reports – unter Emulation und nativ getrennt messen.
• Peripherie: Druckerprofile, Spezialdruck, Scanner-Workflows, Smartcard-Funktionen.
• Sicherheit: EDR/AV-Interaktion, Proxy/TLS, Zertifikatsspeicher, Least-Privilege-Betrieb.

Wichtig ist die Dokumentation: Wenn ein Problem durch fehlende ARM64-Treiber entsteht, ist das kein „Bugfix in Delphi“, sondern eine Beschaffungs- oder Standardisierungsentscheidung.

Betrieb und Support: Wie Sie ARM64 in den Alltag integrieren

Im Alltag zählt, wie schnell Supportfälle gelöst werden. Für ARM64 lohnt es sich, die Supportfähigkeit proaktiv zu erhöhen:

Standardisierte Geräteprofile und klare Freigaben

Definieren Sie unterstützte ARM64-Modelle oder zumindest Mindestprofile (Treiberstrategie, Druckstrategie, Security-Agent-Versionen). Ein „läuft auf ARM64“ ohne diese Klammer führt zu uneinheitlichen Umgebungen und damit zu schwer reproduzierbaren Störungen.

Diagnosefähigkeit in der Anwendung

Auch ohne Entwickler-Fokus ist hier ein klarer Wunsch an die Software sinnvoll: Eine Systeminfo-Seite, die Architektur (x64 emuliert vs. ARM64 nativ), wichtige Pfade, Versionen von Kernkomponenten und Druckkonfiguration ausweist, reduziert Supportzeiten deutlich. Das ist kein „nice to have“, sondern Betriebshygiene.

Lizenzierung und Dongles

Wenn Hardware-Dongles oder ältere Lizenztreiber im Spiel sind, wird ARM64 schnell kritisch. In vielen Umgebungen ist es sinnvoll, Lizenzierung auf netzwerkfähige oder serverseitige Mechanismen umzustellen. Damit sinkt die Abhängigkeit von Treibern auf Endgeräten und die Flotte wird austauschbarer.

Was bedeutet das für Ihre Delphi-Strategie?

Delphi ist im Unternehmenskontext häufig ein stabiler Baustein für Desktop-Clients und Services. Windows 11 ARM64 ist kein Argument „gegen Delphi“, aber ein Argument für eine sauberere Kapselung von Abhängigkeiten und für eine betriebsorientierte Modernisierung: weniger lokale Spezialtreiber, weniger In-Process-Komponenten, klarere Schnittstellen, besseres Deployment.

Wenn Sie heute bereits auf einem Modernisierungspfad sind (z. B. BDE-Ablösung, 64‑Bit-Umstieg, stärkere REST-Integration, konsolidierter Datenzugriff mit FireDAC), dann ist ARM64 häufig „nur“ ein zusätzlicher Zielpunkt, der Prioritäten schärft. Wenn Ihre Anwendung dagegen stark von alten Treibern, proprietären DLLs und Arbeitsplatz-Sonderkonfigurationen abhängt, ist ARM64 ein sinnvoller Anlass, diese Risiken transparent zu machen und planbar zu reduzieren.

Fazit: ARM64 ist weniger ein Portierungsprojekt als ein Architektur- und Betriebsprojekt

Für Unternehmen ist Windows 11 ARM64 vor allem eine Plattformfrage in Beschaffung, Security und Support. Für Delphi-basierte Business-Software entscheidet sich Erfolg nicht an einer Compiler-Option, sondern an der Kette aus Treibern, DLLs, COM-Integrationen, Datenzugriff und Updateprozessen. Ein belastbarer Weg ist: erst Abhängigkeiten und Betriebspfade sichtbar machen, dann mit Pilotgeräten testen, anschließend gezielt entkoppeln und Deployment professionalisieren – und native ARM64-Builds dort liefern, wo sie langfristig Nutzen und Stabilität bringen.

Wenn Sie Windows 11 ARM64 in Ihrer Flotte einführen möchten und dabei Delphi-Anwendungen, Peripherie und Schnittstellen planbar absichern wollen, sprechen Sie mit uns über eine strukturierte Bestandsaufnahme und einen realistischen Migrationspfad:

Im fachlichen Umfeld spielen auch Delphi ARM64 Windows und X64-Emulation Windows 11 eine wichtige Rolle, wenn Integrationen, Datenflüsse und Weiterentwicklung sauber zusammenspielen müssen.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.