ARM64 in the Enterprise: A Mixed Estate, Not a Takeover

The enterprise endpoint landscape is no longer architecturally uniform. For decades, the x86/x64 instruction set was the undisputed standard for desktops, laptops and servers. Today, ARM-based processors have moved out of mobile devices and into mainstream business hardware, driven above all by Apple’s M-series silicon and the Qualcomm Snapdragon X family.

It is tempting to frame this as “ARM taking over”. Shipment data does not support that claim, and for IT operations it is not the interesting question anyway. ARM-based clients accounted for roughly 14 percent of PC shipments in the first quarter of 2026, and that figure already includes Chromebooks and Macs. It is also a share of newly shipped devices, not of the installed base: the x64 fleet already deployed in a large organisation will not disappear within one or two procurement cycles.

The realistic scenario — and the one with real consequences for application packaging — is this: enterprises will run mixed x86/ARM estates for years. Every hardware refresh adds ARM64 devices to an environment that still contains thousands of x64 endpoints. Both populations have to be supplied from the same application catalogue, to the same quality standard, at the same time. That is exactly what turns packaging for ARM from a niche exercise into a permanent operational discipline.

ARM vs. x86: Why Architecture Matters for Packaging

Software compiled for x86 cannot run directly on an ARM processor, and vice versa. That binary incompatibility is the whole technical basis of the problem: an application estate does not migrate simply because the hardware underneath it changes. To bridge the gap, both platform vendors ship translation layers.

• Rosetta 2 (macOS): translates x86_64 code to ARM64 so that most Intel-era Mac applications keep running on Apple Silicon. Translation takes place during installation or at first launch, and just-in-time at runtime for dynamically generated code.
• Prism (Windows on ARM): Microsoft’s emulation layer, introduced with Windows 11, version 24H2. It runs existing x64 and x86 applications on ARM64 hardware. The Prism update released in late 2025 extended translation to the AVX, AVX2, BMI, FMA and F16C instruction sets, which noticeably widens the range of applications that behave acceptably under emulation. Those extensions are exposed to 64-bit x86 applications only: 32-bit applications, and x64 applications that rely on a 32-bit helper process for CPU feature detection, do not see them. Windows 10 on ARM, by contrast, supports x86 emulation only.

Emulation is effective, but it is not free. It costs performance and battery life, and applications with hardware dependencies or deep system integration can still misbehave. For business-critical software, native ARM64 packaging remains the most reliable route to predictable performance and stability.

Arm64EC: Native and x64 Code in One Binary

For repackaging existing Windows applications, Arm64EC (“Emulation Compatible”) is the single most relevant concept — and the one most often missing from ARM migration discussions. Arm64EC is an application binary interface that allows native ARM64 code and emulated x64 code to run together inside the same process.

In practice this means an application does not have to be “fully ARM64 or nothing”. The main executable can run natively while an x64 add-in, plug-in or third-party component that has no ARM64 build continues to run under emulation in the same process. Applications can therefore be moved to ARM incrementally, module by module, instead of waiting for every dependency to be rebuilt. For packaging teams it also adds a question to the assessment of every vendor build: is this binary pure ARM64, Arm64EC, or still x64?

Technical Challenges of Packaging for ARM

Migrating an application portfolio to a new architecture is considerably more complex than recompiling code. The core difficulty is the move from a homogeneous x64 environment to a heterogeneous one, in which every package has to reach the correct architecture without disrupting the user experience.

Key challenges include:

• Dependency Identification: many applications rely on a web of external runtimes, libraries and middleware. The main application may well be ARM-compatible, while a single legacy x86 dependency makes the whole package fail.
• Installer Management: deciding whether to build separate ARM64 and x64 installers or a single universal package containing code for both architectures. Each approach has consequences for package size, deployment logic and maintenance effort.
• Comprehensive Testing: ARM does not add testing effort, it multiplies it. In principle, every application now requires three validation passes instead of one: native ARM64 on ARM hardware, the same application under emulation on ARM, and the unchanged x64 build on legacy hardware. That is a threefold increase in QA volume for every application and every version — and it is the point at which packaging capacity, not packaging knowledge, becomes the bottleneck.

Dependency and Middleware Hurdles

The most common point of failure in an ARM migration is not the main executable but its dependencies. Legacy components buried inside an installer are what bring the process to a halt.

• Runtime Incompatibility: older versions of frameworks such as .NET, the Java Virtual Machine (JVM) and the Microsoft Visual C++ Redistributables may have no ARM64-native equivalent. The packaging process has to identify these components and upgrade them to ARM-compatible versions.
• Legacy 32-bit (x86) Components: while Windows on ARM can still emulate 32-bit x86 code, Apple removed 32-bit application support entirely with macOS Catalina. Any package for Apple Silicon that contains 32-bit binaries will fail to run, and the affected component must be updated or replaced.
• Third-Party Libraries: applications routinely embed open-source or commercial libraries. The packaging team has to verify that an ARM64 version exists for every one of them and adjust the build process accordingly.

Installer Format Considerations: MSIX, Win32 (.intunewin) and PKG

The choice of installer format determines how cleanly an application can be delivered in a multi-architecture environment.

• MSIX for Windows on ARM: MSIX is Microsoft’s modern packaging format for Windows applications, ARM included. A bundle can contain packages for several architectures (x86, x64, ARM64); the system installs only the package the target device actually needs, which keeps deployment logic simple.
• Packaging for macOS: for Apple Silicon, IT teams work with two main formats. Simple drag-and-drop applications ship as .app bundles, while software with scripts and defined installation paths uses .pkg installers. A Universal binary containing both the Intel and the Apple Silicon build inside one package remains the preferred route for seamless deployment.

Note on terminology: .intunewin is a file extension, not a deployment type. The corresponding Intune deployment type is the Win32 app, which is why this guide uses Win32 (.intunewin) throughout. Whichever format is used, one principle applies to all of them: the deployment has to ensure that each device receives the package built for its own architecture. How that is enforced depends on the management platform and should be verified against its current behaviour rather than assumed.

Repackaging for ARM Is a Recurring Cycle, Not a One-Off Project

The most under-estimated aspect of ARM migration is that it does not end. The initial conversion of an application is a single event; keeping it working is a permanent one. Every vendor update to an ARM64 application triggers the same work again — acquire the new source, rebuild or reconfigure the package, validate it against all relevant targets, redeploy. Multiply that by the size of the catalogue and by the number of releases per year, and the recurring cycle, not the first migration, is where the effort really sits.

This is precisely why a packaging factory model exists, and why ARM makes it more relevant rather than less:

• Continuous Update Management: as vendors release new versions and security patches, ARM packages have to be rebuilt and re-validated on the same cadence as their x64 counterparts, so the portfolio stays secure and compatible.
• Proactive Compatibility Monitoring: platform changes in Windows and macOS — new emulation behaviour, changed signing or installer requirements — can invalidate packages that worked yesterday. Tracking those changes and adapting packages before users notice is ongoing work.
• Integrated Patch Management: for third-party applications, ARM packages should feed into the same patch process as everything else, so that architecture never becomes the reason an endpoint falls behind.

Strategic Framework for ARM Application Migration

A workable approach to ARM does not need a new methodology; it needs the existing one to become architecture-aware. Inventory has to record the architecture and dependencies of each application, not just its name and version. Prioritisation should follow the hardware rollout — the applications used by the groups actually receiving ARM devices come first, not the largest applications in the catalogue. Packaging has to be standardised so that ARM64 and x64 builds of the same title stay in sync. And validation has to cover all relevant targets, because “it installed” is not the same statement on ARM as it is on x64.

Discovery and Assessment of the App Estate

You cannot manage what you cannot see. The first step is a detailed inventory of every application in use — not a list of names, but an analysis of each application’s underlying architecture and dependencies.

• Automated Scanning: manual assessment is unrealistic for a large estate. Automated inspection of installers and binaries is what surfaces architectural dependencies, legacy 32-bit components and likely compatibility risks.
• Application Categorisation: every application should end up in one of four categories:
  • Native ARM64: the vendor already ships an ARM-native build.
  • Emulation-Compatible: the application is x64 but runs reliably under Rosetta 2 or Prism.
  • Requires Repackaging: the application is business-critical and needs a native ARM64 package.
  • Needs Replacement: the application is incompatible and has to be replaced by an ARM-native or SaaS alternative.

This four-way split is what makes the rest of the migration plannable: it converts an undifferentiated application list into a work queue with a known size.

The Packaging Workflow for ARM64

Once applications are assessed and prioritised, a standardised workflow keeps quality and effort predictable.

1. Source Acquisition: obtain the latest stable source media and check first whether the vendor already provides an ARM64 or Arm64EC build. Set up clean packaging environments for both ARM64 and x64 so that results are not contaminated by other software.
2. Configuration and Repackaging: where no universal installer exists, build a dedicated ARM64 package, using ARM-native dependencies and runtimes. For MSIX this means including the ARM64 binaries and updating the package manifest accordingly.
3. Automated Testing: run scripted smoke tests — installation, launch, core functions — before any user testing, so obvious failures surface early rather than in the field.
4. Targeted Deployment: deploy through the existing management platform, ensuring that ARM64 packages reach ARM64 devices and x64 packages continue to serve legacy hardware. The mechanism differs between platforms and versions; the requirement does not.

ARM Packaging with Apptimized

Building an in-house ARM packaging capability is expensive in exactly the resources most IT departments lack: specialist skills, test hardware and time. Apptimized addresses this with a managed software packaging for ARM service that takes over the workflow — from source analysis and repackaging to documented, deployment-ready output.

Instead of absorbing dependency conflicts and parallel build environments internally, organisations can use a packaging factory model to receive ARM64 packages on demand, which reduces manual effort and keeps migration programmes such as a Windows 11 rollout on schedule.

Outsourcing Complexity with a Dedicated Packaging Factory

• Access to Expert Engineers: packaging engineers who work with ARM migrations regularly — from resolving dependency conflicts to structuring Universal binaries for macOS and multi-architecture MSIX packages for Windows.
• Predictable Quality and SLAs: packages are delivered against defined quality standards and agreed service levels, which makes output plannable for the deployment pipeline.
• Standardised Outputs for Intune and SCCM: packages are prepared and documented for the endpoint management system in use, including the scripts and detection logic required for silent deployment.
• Capacity That Follows the Refresh Cycle: packaging demand is not constant. It peaks with hardware rollouts and vendor release waves, which is where an external factory absorbs load that an internal team would otherwise have to staff for permanently.

Frequently Asked Questions

Can ARM-based Windows devices run standard 64-bit (x64) software?

Yes. Windows 11 on ARM includes the Prism emulation layer, which runs most x64 and x86 applications. Windows 10 on ARM supports x86 emulation only. In both cases, performance and compatibility are better with applications packaged natively for ARM64.

What is the difference between native ARM64 packaging and emulation?

Native ARM64 packaging means the application code is compiled for the ARM instruction set and runs directly on the processor. Emulation inserts a translation layer (Prism or Rosetta 2) that converts x64 instructions to ARM64 at runtime, which costs performance and can cause compatibility issues with complex software.

Do I need different packages for Intel-based Macs and Apple Silicon Macs?

Ideally not. The best practice for macOS is a Universal package containing both the x86_64 binary for Intel Macs and the ARM64 binary for Apple Silicon; macOS then runs the correct one automatically. Where a Universal binary is not available, separate packages are required.

How does Microsoft Intune handle application deployment to ARM devices?

Intune deploys applications to ARM64 devices using the same formats as elsewhere — Win32 (.intunewin) and MSIX. The essential requirement is that each device receives the build matching its architecture. The exact targeting options available for ARM64 change between service releases, so the current behaviour should be verified in your own tenant rather than taken from documentation of an older state.

Is MSIX the right format for packaging Windows on ARM applications?

MSIX is Microsoft’s most modern and recommended format, and its multi-architecture bundles are genuinely useful: one bundle can carry x86, x64 and ARM64 packages, and only the relevant one is installed. In everyday enterprise practice, however, Win32 (.intunewin) is still the more common route for ARM deployments, so the choice should follow the existing estate rather than the newest format.

How can I automate the conversion of SCCM packages for ARM-based Intune devices?

In several steps. First, assess which SCCM packages are realistic ARM candidates. Then repackage the application from its original format (.exe or .msi) into an ARM64-compatible MSIX or Win32 (.intunewin) package. Finally, import the package into Intune and configure the deployment so that it reaches ARM64 devices only.

Author

Stefan Lang