You have a warehouse of x86 POS units on a Windows build with a hard expiration date. Your team is weighing whether "just put Android on it" is real engineering or a sales slide. It's real. But it’s not one or the other: there’s a Windows-to-Android flip on x86 that’s a reversible dual-boot. Here's the mechanism.

TL;DR

• A Windows-to-Android flip converts fielded x86 hardware you already own from Windows to Esper Foundation for Android. It's a scoped, assisted engagement, so you’re not running it alone.
• The Firebolt dual-boot path preserves the Windows partition and stays reversible. The active OS is selected with no field technician after the initial install.
• A bare-metal ISO install wipes the drive. No Windows partition survives, and there is no rollback path aside from re-installing Windows from scratch. 
• Esper Firebolt is the generality of the flip across three layers: the commitment, the delivery mechanism, and the package configuration. USB, bare-metal, PXE, and Windows RMM are delivery modifiers of Firebolt.
• For exact boot configuration, partition sizing, and restore command syntax, defer to the Esper Foundation documentation.

What does it mean to flip an x86 device from Windows to Android?

Flipping an x86 device means converting hardware that shipped with Windows so it runs Esper Foundation for Android instead. Foundation is a custom AOSP build with OS-layer control, and it becomes the operating system on machines you already own in the field. Esper Foundation for Android is the destination. The flip is the on-ramp.

One distinction is load-bearing, and blurring it is how migrations go wrong. A dual-boot flip preserves the Windows partition and is reversible. A bare-metal install wipes the drive and is not reversible outside of re-installing Windows from scratch. These are two different operations, not two settings of one operation.

Esper Firebolt is the assisted engagement that performs the flip. It spans three independent layers. There's the commitment (what you decide to do), the delivery mechanism (how the bootstrapping payload reaches the device), and the configuration (how the payload is prepared, set independently of delivery).

The commitment splits two ways. A clean install replaces Windows entirely and optimizes the use of the hardware resources, which suits fleet operators that have already decided to commit to Android. A dual-boot implementation keeps the Windows partition in place so Android can be proven in production before anything is destroyed.

How the reversible dual-boot path runs Windows and Android on x86

The dual-boot path runs both Windows and Android on the same x86 device by shrinking and then keeping the Windows partition alongside the new Foundation install. Nothing is wiped. The device carries both operating systems, and one is active at a time.

After the initial Firebolt-driven install at the device, no field technician has to return to switch a unit between Windows and Foundation. You have to choose the default boot OS and boot order as a configuration of Firebolt ahead of time.

A canonical rollout runs in order. A technician on site with Firebolt on USB or an IT Operator remotely via an RMM tool runs Firebolt configured for the dual-boot setup, and the device can still boot into Windows in production. Foundation is set up as the default OS. If the pilot holds, you advance more devices. If it doesn't, you can revert, because the Windows partition never left.

Dual-boot has two firm boundaries. It supports Android up to version 13, and it applies to x86 hardware only. For the exact boot configuration, partition sizing, and the command syntax used to revert a device to Windows, follow the Esper Foundation documentation.

How is a bare-metal install different from the dual-boot flip?

A bare-metal install writes Foundation directly to the drive and wipes what was there. No Windows partition survives the process. Unlike the dual-boot path, a bare-metal install is not reversible, and there is no partition to fall back to.

Bare-metal is the install type behind a clean-install commitment. It is also usable in the field when you have already decided Android is the endpoint for that hardware.

The choice between Firebolt dual-boot and bare-metal determines whether you have a rollback path at all. Dual-boot buys you a reversible pilot. Bare-metal commits the device. Both are legitimate, and they answer different questions about how sure you are.

How is Firebolt delivered across a fleet?

Firebolt reaches devices through four delivery mechanisms:

• USB media: a technician installs onsite. This is the common path for a dual-boot pilot in a test lab, it preserves Windows, and it stays reversible.
• Bare-metal ISO: wipes the drive and installs Foundation directly. No Windows partition survives, and it is not reversible without a fresh install of Windows.
• PXE: a network-boot transport, not an install type. It delivers an installer image at scale without per-unit media, and it's commonly how bare-metal is delivered at factory volume. 
• RMM push: delivery through your existing remote management tooling. This is the scale path, and Windows can stay present as a safety net during rollout, or it can be removed completely.

These map to an adoption ladder. You pilot in a lab and a few pilot stores, then advance if it holds or revert if it doesn't. From there you scale through your existing tooling, with Windows still present as a safety net. Once Android has proven itself, you wipe Windows. Customers graduate to a larger rollout, never to a different tool.

Pricing is scoped to the specific hardware and peripheral configuration, not billed flat per device. Full implementation across hardware variants and peripherals can carry significant engineering lift. That work may require meaningful non-recurring engineering before a true field trial build. For per-path setup steps, defer to the Esper Foundation documentation.

Why does the flip work differently on different devices?

The flip clears two eligibility gates, and both have to pass before any commitment. Esper confirms both in a scoped evaluation up front, so the answer is known before a device is touched.

The first gate is Android compatibility. Support is brought up per hardware configuration along with the required peripherals rather than assumed universal across all x86 hardware. A device qualifies once its hardware set is supported, and that is verified rather than presumed.

The second gate is whether your application has an Android build. Windows-only software cannot be converted in place, and this gate cuts across every hardware brand. If the application runs only on Windows, the hardware underneath it is irrelevant to eligibility unless you’re willing to switch ISVs to get an Android version. Preserving application data and state across the conversion is not a shipping capability, so plan the migration without assuming it.

These are the real reasons a flip works on one hardware model and not another. The determining factors are the device’s hardware designand the application, not the badge on the chassis.

Dual-boot isn't compromise engineering, it's a different, fully specified install

Some engineering teams read dual-boot as half a job — pick an OS and commit, or you haven't really migrated anything. That instinct treats dual-boot as an unfinished bare-metal install, when it's actually the opposite. It's a complete, separately specified install with its own contract: a bootloader that owns the handoff, with a protected partition that survives the switch. None of that is missing from a "real" install. It's the whole point of this one.

The tradeoff is real and worth stating plainly. Dual-boot buys you a live rollback path and costs you a ceiling — it supports Android up to version 13, and pushing past that ceiling means giving up the Windows partition. Bare-metal buys you Foundation's full use of the hard drive as many of these systems have limited storage capacity that can’t accommodate room for both Foundation and Windows — and costs you the rollback. Neither is the lesser architecture. They're two different sets of guarantees for two different points in a migration.

What this displaces is the assumption that a real conversion always means wiping the drive, and that anything short of that is a stopgap. It isn't. It's a choice about which guarantees you need first against hardware constraints.

What a reversible flip actually buys an engineering team

There are real clocks behind this work. Windows 10 IoT Enterprise LTSB 2016 loses security support on October 13, 2026, and later releases reach end of life behind it. Separately, the 2011 UEFI Secure Boot certificates begin expiring in 2026. Devices that never received the newer certificate firmware can lose their ability to receive boot-level security updates once the old certificates lapse. Foundation does not depend on the Windows Secure Boot chain, so a converted device steps around that second problem. Extended security updates are a shrinking, escalating-cost runway, not a fix.

An x86 Windows-to-Android flip adds a Foundation install that is the default in the boot order while Windows survives untouched. 

After conversion, the fleet runs Esper Foundation, operated through the Esper console for remote OTA, Seamless Provisioning, and lifecycle control. A Firebolt conversion requires both Esper Foundation and an Esper Deploy (MDM) subscription. Neither is available standalone without Esper MDM, because the OS-layer control only holds when the device management layer holds under it.

‍Talk to us about Firebolt

Windows-to-Android Flip on x86: FAQ

Can you dual-boot Windows and Android on the same x86 device?

Yes. The dual-boot path keeps a shrunken Windows partition in place and installs Foundation alongside it, so the same x86 device carries both. Dual-boot supports Android up to version 13 and applies to x86 hardware only.

How do you control which OS an x86 device boots into?

This is a Firebolt configuration option that you determine ahead of time. For the exact boot configuration, follow the Esper Foundation documentation.

Is a bare-metal Android install reversible?

No. A bare-metal ISO install wipes the drive and installs Foundation directly, and no Windows partition survives. There is no rollback path. If you need reversibility, use the USB dual-boot path instead.

How is Android delivered to an x86 fleet at scale?

Through delivery mechanisms that modify Firebolt: USB media, bare-metal ISO, PXE as a network-boot transport, and a push through your existing RMM tooling. PXE is commonly how bare-metal is delivered in some vertical market IT infrastructure. For per-path setup, defer to the Esper Foundation documentation.

Do you have to visit each device to flip it?

Only for the USB-based install. After that, you can flip devices using the RMM push path.

Why does an x86 Windows-to-Android flip work on some devices but not others?

Two gates decide it. The device hardware and required peripherals have to be supported, and the POS or kiosk application has to have an Android build. Windows-only software cannot be converted in place regardless of hardware brand.