ARM64 im Unternehmen: Gemischte Gerätelandschaften statt vollständiger Ablösung

Die Endpoint-Landschaft in Unternehmen ist architektonisch nicht mehr einheitlich. Jahrzehntelang war der x86/x64-Befehlssatz der unangefochtene Standard für Desktop-PCs, Laptops und Server. Heute haben ARM-basierte Prozessoren den Bereich mobiler Geräte verlassen und sind in gängiger Business-Hardware angekommen – vor allem durch Apples Chips der M-Serie und die Qualcomm-Snapdragon-X-Familie.

Es liegt nahe, dies als „Übernahme durch ARM“ darzustellen. Die Auslieferungszahlen stützen diese Aussage jedoch nicht, und für den IT-Betrieb ist sie ohnehin nicht die entscheidende Frage. ARM-basierte Clients machten im ersten Quartal 2026 rund 14 Prozent der PC-Auslieferungen aus; darin sind Chromebooks und Macs bereits enthalten. Zudem bezieht sich dieser Anteil auf neu ausgelieferte Geräte und nicht auf den installierten Bestand: Die bereits in großen Unternehmen eingesetzte x64-Flotte wird nicht innerhalb von ein oder zwei Beschaffungszyklen verschwinden.

Das realistische Szenario – und dasjenige mit konkreten Folgen für die Anwendungspaketierung – sieht so aus: Unternehmen werden über Jahre hinweg gemischte x86-/ARM-Umgebungen betreiben. Mit jeder Hardwareerneuerung kommen ARM64-Geräte zu einer Umgebung hinzu, die weiterhin Tausende x64-Endpoints umfasst. Beide Geräteklassen müssen gleichzeitig aus demselben Anwendungskatalog und nach denselben Qualitätsstandards versorgt werden. Genau dadurch wird die Paketierung für ARM von einer Nischenaufgabe zu einer dauerhaften operativen Disziplin.

ARM vs. x86: Warum die Architektur für die Paketierung entscheidend ist

Für x86 kompilierte Software kann nicht direkt auf einem ARM-Prozessor ausgeführt werden – und umgekehrt. Diese binäre Inkompatibilität ist die technische Grundlage des gesamten Problems: Eine Anwendungslandschaft migriert nicht automatisch, nur weil sich die darunterliegende Hardware ändert. Um diese Lücke zu schließen, stellen beide Plattformanbieter Übersetzungsschichten bereit.

• Rosetta 2 (macOS): Übersetzt x86_64-Code in ARM64-Code, damit die meisten Mac-Anwendungen aus der Intel-Ära weiterhin auf Apple Silicon ausgeführt werden können. Die Übersetzung erfolgt bei der Installation oder beim ersten Start; dynamisch erzeugter Code wird zur Laufzeit Just-in-Time übersetzt.
• Prism (Windows on ARM): Microsofts Emulationsschicht, die mit Windows 11, Version 24H2, eingeführt wurde. Sie führt vorhandene x64- und x86-Anwendungen auf ARM64-Hardware aus. Das Ende 2025 veröffentlichte Prism-Update erweiterte die Übersetzung um die Befehlssätze AVX, AVX2, BMI, FMA und F16C. Dadurch vergrößert sich die Zahl der Anwendungen deutlich, die unter Emulation akzeptabel funktionieren. Diese Erweiterungen stehen nur 64-Bit-x86-Anwendungen zur Verfügung: 32-Bit-Anwendungen sowie x64-Anwendungen, die zur Erkennung von CPU-Funktionen einen 32-Bit-Hilfsprozess verwenden, können sie nicht nutzen. Windows 10 on ARM unterstützt dagegen nur die x86-Emulation.

Emulation ist wirkungsvoll, aber nicht kostenlos. Sie geht zulasten von Leistung und Akkulaufzeit, und Anwendungen mit Hardwareabhängigkeiten oder tiefer Systemintegration können weiterhin fehlerhaft funktionieren. Für geschäftskritische Software bleibt die native ARM64-Paketierung der zuverlässigste Weg zu vorhersehbarer Leistung und Stabilität.

Arm64EC: Nativer ARM64- und x64-Code in einer Binärdatei

Für die Neu-Paketierung bestehender Windows-Anwendungen ist Arm64EC („Emulation Compatible“) das wichtigste Konzept – und zugleich dasjenige, das in Diskussionen über ARM-Migrationen am häufigsten fehlt. Arm64EC ist eine binäre Anwendungsschnittstelle (Application Binary Interface, ABI), über die nativer ARM64-Code und emulierter x64-Code gemeinsam innerhalb desselben Prozesses ausgeführt werden können.

In der Praxis bedeutet das, dass eine Anwendung nicht „vollständig ARM64 oder gar nicht“ sein muss. Die Hauptanwendung kann nativ ausgeführt werden, während ein x64-Add-in, Plug-in oder eine Drittanbieterkomponente ohne ARM64-Build im selben Prozess weiterhin unter Emulation läuft. Anwendungen lassen sich dadurch schrittweise und Modul für Modul auf ARM umstellen, anstatt zu warten, bis jede Abhängigkeit neu erstellt wurde. Für Paketierungsteams kommt bei der Bewertung jedes Hersteller-Builds außerdem eine weitere Frage hinzu: Handelt es sich um eine reine ARM64-Binärdatei, um Arm64EC oder weiterhin um x64?

Technische Herausforderungen bei der Paketierung für ARM

Die Migration eines Anwendungsportfolios auf eine neue Architektur ist erheblich komplexer als die bloße Neukompilierung von Code. Die zentrale Schwierigkeit besteht im Wechsel von einer homogenen x64-Umgebung zu einer heterogenen Umgebung, in der jedes Paket die richtige Architektur erreichen muss, ohne die Benutzererfahrung zu beeinträchtigen.

Zu den wichtigsten Herausforderungen gehören:

• Ermittlung von Abhängigkeiten: Viele Anwendungen sind auf ein Geflecht aus externen Laufzeitumgebungen, Bibliotheken und Middleware angewiesen. Die Hauptanwendung kann durchaus ARM-kompatibel sein, während bereits eine einzige veraltete x86-Abhängigkeit das gesamte Paket zum Scheitern bringt.
• Installer-Management: Es muss entschieden werden, ob separate ARM64- und x64-Installer oder ein einziges universelles Paket mit Code für beide Architekturen erstellt werden. Jeder Ansatz wirkt sich auf Paketgröße, Bereitstellungslogik und Wartungsaufwand aus.
• Umfassende Tests: ARM erhöht den Testaufwand nicht nur – es vervielfacht ihn. Grundsätzlich benötigt nun jede Anwendung drei Validierungsdurchläufe statt eines einzigen: nativ unter ARM64 auf ARM-Hardware, dieselbe Anwendung unter Emulation auf ARM sowie der unveränderte x64-Build auf älterer Hardware. Das verdreifacht das QA-Volumen für jede Anwendung und jede Version – und genau hier wird die Paketierungskapazität, nicht das Paketierungswissen, zum Engpass.

Hürden bei Abhängigkeiten und Middleware

Der häufigste Fehlerpunkt bei einer ARM-Migration ist nicht die ausführbare Hauptdatei, sondern ihre Abhängigkeiten. Veraltete Komponenten, die tief in einem Installer verborgen sind, bringen den Prozess zum Stillstand.

• Inkompatible Laufzeitumgebungen: Für ältere Versionen von Frameworks wie .NET, der Java Virtual Machine (JVM) und den Microsoft Visual C++ Redistributables gibt es möglicherweise kein natives ARM64-Pendant. Im Paketierungsprozess müssen diese Komponenten identifiziert und auf ARM-kompatible Versionen aktualisiert werden.
• Veraltete 32-Bit-Komponenten (x86): Windows on ARM kann 32-Bit-x86-Code weiterhin emulieren, Apple hat die Unterstützung für 32-Bit-Anwendungen jedoch mit macOS Catalina vollständig eingestellt. Jedes Paket für Apple Silicon, das 32-Bit-Binärdateien enthält, kann nicht ausgeführt werden; die betroffene Komponente muss aktualisiert oder ersetzt werden.
• Drittanbieterbibliotheken: Anwendungen binden regelmäßig Open-Source- oder kommerzielle Bibliotheken ein. Das Paketierungsteam muss prüfen, ob für jede davon eine ARM64-Version verfügbar ist, und den Build-Prozess entsprechend anpassen.

Hinweise zu Installer-Formaten: MSIX, Win32 (.intunewin) und PKG

Die Wahl des Installer-Formats bestimmt, wie reibungslos eine Anwendung in einer Umgebung mit mehreren Architekturen bereitgestellt werden kann.

• MSIX für Windows on ARM: MSIX ist Microsofts modernes Paketierungsformat für Windows-Anwendungen, einschließlich ARM. Ein Bundle kann Pakete für mehrere Architekturen (x86, x64, ARM64) enthalten; das System installiert nur das Paket, das das Zielgerät tatsächlich benötigt. Dadurch bleibt die Bereitstellungslogik einfach.
• Paketierung für macOS: Für Apple Silicon arbeiten IT-Teams hauptsächlich mit zwei Formaten. Einfache Drag-and-drop-Anwendungen werden als .app-Bundles ausgeliefert, während Software mit Skripten und definierten Installationspfaden .pkg-Installer verwendet. Eine Universal-Binärdatei, die sowohl den Intel- als auch den Apple-Silicon-Build in einem Paket enthält, bleibt die bevorzugte Lösung für eine nahtlose Bereitstellung.

Hinweis zur Terminologie: .intunewin ist eine Dateiendung und kein Bereitstellungstyp. Der entsprechende Intune-Bereitstellungstyp ist die Win32-App. Deshalb wird in diesem Leitfaden durchgehend die Bezeichnung Win32 (.intunewin) verwendet. Unabhängig vom Format gilt ein Grundsatz: Die Bereitstellung muss sicherstellen, dass jedes Gerät das für seine Architektur erstellte Paket erhält. Wie dies umgesetzt wird, hängt von der Managementplattform ab und sollte anhand ihres aktuellen Verhaltens überprüft und nicht einfach vorausgesetzt werden.

Die Neu-Paketierung für ARM ist ein wiederkehrender Zyklus und kein einmaliges Projekt

Der am meisten unterschätzte Aspekt einer ARM-Migration ist, dass sie nie wirklich endet. Die erstmalige Umstellung einer Anwendung ist ein einmaliges Ereignis; sie dauerhaft funktionsfähig zu halten, ist eine fortlaufende Aufgabe. Jedes Herstellerupdate für eine ARM64-Anwendung löst denselben Arbeitsablauf erneut aus: neue Quelldateien beschaffen, das Paket neu erstellen oder konfigurieren, es auf allen relevanten Zielsystemen validieren und erneut bereitstellen. Multipliziert man dies mit der Größe des Katalogs und der Anzahl der Releases pro Jahr, zeigt sich: Der eigentliche Aufwand liegt im wiederkehrenden Zyklus, nicht in der ersten Migration.

Genau deshalb gibt es das Packaging-Factory-Modell – und ARM macht es relevanter, nicht weniger relevant:

• Kontinuierliches Update-Management: Wenn Hersteller neue Versionen und Sicherheitspatches veröffentlichen, müssen ARM-Pakete im gleichen Rhythmus wie ihre x64-Pendants neu erstellt und erneut validiert werden, damit das Portfolio sicher und kompatibel bleibt.
• Proaktive Kompatibilitätsüberwachung: Plattformänderungen in Windows und macOS – etwa ein neues Emulationsverhalten oder geänderte Anforderungen an Signierung und Installer – können Pakete unbrauchbar machen, die gestern noch funktioniert haben. Diese Änderungen zu verfolgen und Pakete anzupassen, bevor Benutzer Probleme bemerken, ist eine fortlaufende Aufgabe.
• Integriertes Patch-Management: Bei Drittanbieteranwendungen sollten ARM-Pakete in denselben Patch-Prozess wie alle anderen Pakete einfließen, damit die Architektur niemals der Grund dafür ist, dass ein Endpoint bei Updates zurückbleibt.

Strategischer Rahmen für die Migration von Anwendungen auf ARM

Ein praktikabler ARM-Ansatz erfordert keine neue Methodik; die bestehende Methodik muss lediglich architekturbewusst werden. Im Inventar sollten nicht nur Name und Version jeder Anwendung, sondern auch ihre Architektur und Abhängigkeiten erfasst werden. Die Priorisierung sollte sich am Hardware-Rollout orientieren: Zuerst kommen die Anwendungen, die von den Gruppen genutzt werden, die tatsächlich ARM-Geräte erhalten – nicht die größten Anwendungen im Katalog. Die Paketierung muss standardisiert sein, damit ARM64- und x64-Builds derselben Anwendung synchron bleiben. Und die Validierung muss alle relevanten Zielsysteme abdecken, denn „es wurde installiert“ hat auf ARM nicht dieselbe Aussagekraft wie auf x64.

Erfassung und Bewertung der Anwendungslandschaft

Was nicht sichtbar ist, kann auch nicht verwaltet werden. Der erste Schritt ist eine detaillierte Bestandsaufnahme aller eingesetzten Anwendungen – nicht nur eine Namensliste, sondern eine Analyse der zugrunde liegenden Architektur und Abhängigkeiten jeder Anwendung.

• Automatisiertes Scanning: Eine manuelle Bewertung ist für eine große Anwendungslandschaft unrealistisch. Durch die automatisierte Analyse von Installern und Binärdateien werden architektonische Abhängigkeiten, veraltete 32-Bit-Komponenten und wahrscheinliche Kompatibilitätsrisiken sichtbar.
• Anwendungskategorisierung: Jede Anwendung sollte einer von vier Kategorien zugeordnet werden:
  • Natives ARM64: Der Hersteller stellt bereits einen nativen ARM-Build bereit.
  • Emulationskompatibel: Die Anwendung ist für x64 ausgelegt, läuft aber zuverlässig unter Rosetta 2 oder Prism.
  • Neu-Paketierung erforderlich: Die Anwendung ist geschäftskritisch und benötigt ein natives ARM64-Paket.
  • Ersetzung erforderlich: Die Anwendung ist inkompatibel und muss durch eine ARM-native oder SaaS-Alternative ersetzt werden.

Diese Einteilung in vier Kategorien macht die weitere Migration planbar: Sie verwandelt eine undifferenzierte Anwendungsliste in einen Arbeitsvorrat mit bekanntem Umfang.

Der Paketierungsworkflow für ARM64

Nach der Bewertung und Priorisierung der Anwendungen sorgt ein standardisierter Workflow für planbare Qualität und einen vorhersehbaren Aufwand.

1. Beschaffung der Quelldateien: Beschaffen Sie die neuesten stabilen Installationsmedien und prüfen Sie zunächst, ob der Hersteller bereits einen ARM64- oder Arm64EC-Build anbietet. Richten Sie saubere Paketierungsumgebungen für ARM64 und x64 ein, damit die Ergebnisse nicht durch andere Software beeinflusst werden.
2. Konfiguration und Neu-Paketierung: Wenn kein universeller Installer verfügbar ist, erstellen Sie ein eigenes ARM64-Paket mit ARM-nativen Abhängigkeiten und Laufzeitumgebungen. Bei MSIX bedeutet dies, die ARM64-Binärdateien einzubinden und das Paketmanifest entsprechend zu aktualisieren.
3. Automatisierte Tests: Führen Sie vor allen Benutzertests skriptbasierte Smoke-Tests für Installation, Start und Kernfunktionen aus. So werden offensichtliche Fehler frühzeitig und nicht erst im produktiven Einsatz erkannt.
4. Gezielte Bereitstellung: Stellen Sie die Pakete über die vorhandene Managementplattform bereit und sorgen Sie dafür, dass ARM64-Pakete ARM64-Geräte erreichen, während x64-Pakete weiterhin ältere Hardware versorgen. Der Mechanismus unterscheidet sich je nach Plattform und Version; die Anforderung bleibt gleich.

ARM-Paketierung mit Apptimized

Der Aufbau eigener Kapazitäten für die ARM-Paketierung ist genau in den Ressourcen kostspielig, die den meisten IT-Abteilungen fehlen: Fachwissen, Testhardware und Zeit. Apptimized begegnet diesem Problem mit einem Managed Service für die ARM64-Softwarepaketierung, der den gesamten Workflow übernimmt – von der Quellenanalyse und Neu-Paketierung bis zur dokumentierten, bereitstellungsfertigen Ausgabe.

Statt Abhängigkeitskonflikte und parallele Build-Umgebungen intern aufzufangen, können Unternehmen über ein Packaging-Factory-Modell ARM64-Pakete bei Bedarf beziehen. Das reduziert den manuellen Aufwand und hält Migrationsprogramme wie einen Windows-11-Rollout im Zeitplan.

Komplexität an eine dedizierte Packaging Factory auslagern

• Zugang zu erfahrenen Paketierungsingenieuren: Experten, die regelmäßig an ARM-Migrationen arbeiten – von der Lösung von Abhängigkeitskonflikten bis zur Strukturierung von Universal-Binärdateien für macOS und Multi-Architektur-MSIX-Paketen für Windows.
• Planbare Qualität und SLAs: Pakete werden nach definierten Qualitätsstandards und vereinbarten Service Levels bereitgestellt. Dadurch lässt sich der Output für die Bereitstellungspipeline zuverlässig planen.
• Standardisierte Ergebnisse für Intune und SCCM: Die Pakete werden für das eingesetzte Endpoint-Management-System vorbereitet und dokumentiert, einschließlich der Skripte und Erkennungslogik, die für eine unbeaufsichtigte Bereitstellung erforderlich sind.
• Kapazität passend zum Refresh-Zyklus: Der Paketierungsbedarf ist nicht konstant. Er erreicht Spitzen bei Hardware-Rollouts und Release-Wellen der Hersteller. In diesen Phasen übernimmt eine externe Factory die zusätzliche Last, für die ein internes Team sonst dauerhaft Personal vorhalten müsste.

Häufig gestellte Fragen

Können ARM-basierte Windows-Geräte herkömmliche 64-Bit-Software (x64) ausführen?

Ja. Windows 11 on ARM enthält die Prism-Emulationsschicht, über die die meisten x64- und x86-Anwendungen ausgeführt werden können. Windows 10 on ARM unterstützt nur die x86-Emulation. In beiden Fällen bieten nativ für ARM64 paketierte Anwendungen eine bessere Leistung und Kompatibilität.

Worin unterscheidet sich die native ARM64-Paketierung von der Emulation?

Bei der nativen ARM64-Paketierung wird der Anwendungscode für den ARM-Befehlssatz kompiliert und direkt auf dem Prozessor ausgeführt. Bei der Emulation wandelt eine Übersetzungsschicht (Prism oder Rosetta 2) x64-Anweisungen zur Laufzeit in ARM64-Anweisungen um. Das kostet Leistung und kann bei komplexer Software zu Kompatibilitätsproblemen führen.

Benötige ich unterschiedliche Pakete für Intel-basierte Macs und Macs mit Apple Silicon?

Im Idealfall nicht. Für macOS gilt ein Universal-Paket als Best Practice. Es enthält sowohl die x86_64-Binärdatei für Intel-Macs als auch die ARM64-Binärdatei für Apple Silicon; macOS führt automatisch die passende Version aus. Ist keine Universal-Binärdatei verfügbar, sind separate Pakete erforderlich.

Wie stellt Microsoft Intune Anwendungen auf ARM-Geräten bereit?

Intune stellt Anwendungen auf ARM64-Geräten in denselben Formaten wie auf anderen Geräten bereit: Win32 (.intunewin) und MSIX. Entscheidend ist, dass jedes Gerät den zu seiner Architektur passenden Build erhält. Die verfügbaren Optionen für das ARM64-Targeting ändern sich zwischen Service-Releases. Deshalb sollte das aktuelle Verhalten im eigenen Tenant überprüft werden, statt sich auf Dokumentation zu einem älteren Stand zu verlassen.

Ist MSIX das richtige Format für die Paketierung von Windows-on-ARM-Anwendungen?

MSIX ist Microsofts modernstes und empfohlenes Format. Die Multi-Architektur-Bundles sind tatsächlich nützlich: Ein Bundle kann x86-, x64- und ARM64-Pakete enthalten, wobei nur das relevante Paket installiert wird. Im Unternehmensalltag ist Win32 (.intunewin) für ARM-Bereitstellungen jedoch weiterhin häufiger anzutreffen. Die Wahl sollte sich daher an der bestehenden Anwendungslandschaft und nicht am neuesten Format orientieren.

Wie kann ich die Konvertierung von SCCM-Paketen für ARM-basierte Intune-Geräte automatisieren?

In mehreren Schritten. Prüfen Sie zunächst, welche SCCM-Pakete realistische Kandidaten für ARM sind. Paketieren Sie die Anwendung anschließend aus ihrem ursprünglichen Format (.exe oder .msi) in ein ARM64-kompatibles MSIX- oder Win32-Paket (.intunewin) neu. Importieren Sie das Paket abschließend in Intune und konfigurieren Sie die Bereitstellung so, dass es ausschließlich ARM64-Geräte erreicht.

Author

Stefan Lang