The touchscreens still register. The payment peripherals are still in great shape. The cash drawers open and close just fine. Nothing about the hardware in your stores is failing. What's failing is the operating system on the drive, and it has a date on it.

TL;DR

• Firebolt is Esper's assisted, scoped engagement for converting Windows x86 devices to Esper Foundation for Android on the hardware you already own.
• The first decision is the commitment: a clean install that replaces Windows, or a dual-boot install that preserves it so you can prove Android in production first. Dual-boot supports Android up to version 13.
• The commitment is separate from the delivery mechanism. Firebolt reaches a device via a push through the remote-management tooling you already run, a PXE network boot, a local bare-metal ISO, or USB media.
• Windows 10 IoT Enterprise LTSB 2016 loses security support on October 13, 2026, and a UEFI Secure Boot certificate retirement running from October 2026 into spring 2027 adds exposure on its own timer.
• Firebolt is scoped and priced to your specific hardware and peripherals. It's the on-ramp to an Esper Foundation fleet, not a flat-rate product and not a self-serve download.

For supported-image and install specifics, see the Esper Foundation documentation.

What is Firebolt?

Firebolt is Esper's assisted, scoped engagement for converting fielded x86 Windows hardware to Esper Foundation for Android on the machines you already own.

Firebolt separates into three independent layers, and keeping them distinct is how you reason about a conversion without collapsing decisions that don't belong together.

• The commitment is what you decide: clean install or dual-boot. This determines whether Windows survives on the disk.
• The delivery mechanism is how the conversion reaches the device: a push through your existing management tooling, a PXE network boot, a local bare-metal ISO, or USB media.
• The configuration is how the Firebolt package itself is prepared for your fleet: the device model, the attached peripherals, the target image. It's set during scoping, independently of how the package gets delivered.

Firebolt is not a product you buy on its own, not a self-serve download, and not one identical process applied to every device. Two fleets running the same application on different terminals and different payment hardware are typically two different scopes.

What do you actually get?

Firebolt is a one-time conversion event; Esper Foundation is what the device becomes afterward and what you subscribe to. A conversion that hands you an operating system and walks away isn't the offer.

Foundation is a purpose-built Android OS for dedicated devices, built for the kiosk and point-of-sale use case rather than general-purpose Android repurposed for it. Three things sit on top of the OS itself:

• Built-in OTA infrastructure — Esper builds the updates, incorporates the security patches, and delivers them to the fleet. It's the engineering and the delivery both, not just the pipe, which is what separates it from one patch and done.
• The Foundation SDK — purpose-built capabilities that close the gaps stock Android carries for fixed-function devices.
• Esper Deploy device management — fleet-wide visibility and control, a capability in its own right rather than a byproduct of the update pipeline.

Firebolt is the door. Foundation, its OTA infrastructure, the SDK, and device management together are the house. The trade is a one-time conversion in exchange for permanently solving the problem a hardware refresh would have solved, without the capital outlay a refresh requires.

One honest boundary: a converted fleet runs on an ongoing Esper Foundation and Deploy device management subscription, and Foundation is managed by Esper. Firebolt is not a route onto a different management platform. If keeping an incumbent MDM is a requirement, this isn't the path.

Why convert Windows to Android instead of replacing the hardware?

The forcing function is a date. Windows 10 IoT Enterprise LTSB 2016 reaches end of security support on October 13, 2026, and later branches reach their own end-of-life behind it. A payment terminal running an unsupported OS is a compliance and breach-exposure problem that compounds every month it stays in the field.

A second risk runs on its own timer. The 2011 UEFI Secure Boot certificate is being phased out between October 2026 and spring 2027. Devices that never receive the newer certificate firmware can be left exposed once the old one is revoked, and that exposure is independent of the Windows end-of-support date. A device can be fully inside its Windows support window and still hit it. Foundation doesn't depend on the Windows Secure Boot chain, so a converted device steps around that problem rather than inheriting it.

Extended Security Updates are a runway, not a destination. Support is time-boxed, covers security patches only, and the cost escalates every consecutive year you stay enrolled. Enroll late and the skipped years come due. On the IoT SKU there is no centrally published price at all: the device manufacturer sets it, which means standard-SKU figures don't transfer to it and may not be a useful benchmark for what you'll actually be quoted. The shape holds regardless. Standing still costs more every year and never gets the fleet off the treadmill.

The hardware side is asymmetric. A fleet-wide refresh is a multi-quarter capital project carrying procurement, imaging, kitting, site rollout, and disposal of equipment that still works. A scoped OS conversion is none of that, which is what makes it the realistic path when no refresh window remains before support ends. That said, it is possible a fleet refresh is your better option depending on your overall situation.

Does the hardware investment survive the migration?

Yes. The terminals stay. You keep the same x86 hardware, the same peripherals, and the same physical footprint at every location. The operating system is the only thing that changes (and maybe the app if you need to build for Android).

Esper benchmarked a 2015-vintage point-of-sale terminal running faster on Foundation than it had on Windows, on the same box. Old hardware and slow hardware are not the same claim.

What does Firebolt commit you to: Clean install or dual-boot?

The commitment is the decision that shapes everything downstream, and there are exactly two. They run on different underlying capability and they lead to different places.

A clean install replaces Windows entirely. The installer takes the whole disk and writes Foundation directly, and there's no partition left to roll back to. In exchange, the whole drive belongs to Foundation. That matters more than it sounds: an eight-year-old terminal often doesn't have much disk to divide, and splitting it between two operating systems is workable but not automatically the right answer. A clean install suits fleets that have already decided to move.

A dual-boot install preserves the Windows partition on disk, with the default  operating system configured by Firebolt and no technician in the field after the initial install. Dual-boot supports Android up to version 13 and applies to x86 hardware only. For the exact mechanism — the bootloader, the restore operation, what's remotely switchable — see How a Windows-to-Android Flip Actually Works.

Neither is the lesser option. Dual-boot is built as a genuine bridge, and it can be the right call for a fleet that needs real runway while budget or timeline gets sorted out. If keeping Windows on the disk matters to you, that's available up to Android 13. Two different commitments, both real. Which one fits depends on your fleet and your timeline, and Esper works that out with you during scoping.

How does the conversion reach the device?

Once the commitment is set, a conversion reaches the device one of four ways — a technician on-site with USB media, a local bare-metal ISO install, a PXE network boot at scale, or a push through the RMM tooling you already run. Each is a way of delivering Firebolt, never an alternative to it. [How a Windows-to-Android Flip Actually Works](⟨pillar's how-it-works URL⟩) breaks down each path, when it's used, and how they pair with the commitment you've made.

How a dual-boot fleet graduates from pilot to production

A dual-boot rollout moves up a ladder, and every rung stays reversible until the last one. Pilot Android in a lab and a handful of stores. Advance if it holds, revert if it doesn't. Scale through your existing tooling with Windows still present as a safety net. Wipe Windows once Android has proven itself in production.

You graduate to a larger rollout, never to a different tool. The mechanism that runs the pilot is the mechanism that runs the fleet, so nothing gets re-architected between proof and production.

For partition sizing, boot configuration, and the restore operation, defer to the Esper Foundation documentation rather than treating this post as the reference.

Can every Windows fleet be converted? What gates eligibility

No. Eligibility clears two gates, and both have to pass before any commitment is made. The first is whether Foundation can run on your hardware at all and has support for your required peripheral set — usually yes on x86 point-of-sale and kiosk equipment, with real exceptions that only a scope turns up (What Can Flip cluster). The second is whether your point-of-sale or kiosk application has an Android build.

The application gate is the one that surprises people. Firebolt converts the operating system; it does not port software. If the application is Windows-only, there's no in-place conversion no matter how healthy the hardware is, and that gate cuts across every hardware brand.

So the first question isn't whether your hardware is supported. It's whether your software runs on Android. Esper confirms both gates during a scoped evaluation.

That gate cuts the other way too. If you've had an Android build of your point-of-sale application waiting in the wings — approved, tested, blocked on the fact that none of your terminals can run it — the conversion isn't the obstacle. It's the thing that finally lets you ship it.

One more limit worth being clear-eyed about, though it may not be your limit. Preserving application data or state stored on the device across the conversion is not a shipping capability. If your point-of-sale application already keeps its state in the cloud — which most of the Android-ready platforms do — this isn't a problem you have. Where it bites is applications holding meaningful local state on the terminal itself: order queues, loyalty caches, offline transaction logs. That depends on how your ISV built the application, and the translation logic has to live with that vendor's development team. Esper can provide the plumbing at the OS layer; it can't parse a third party's proprietary data format.

What does a Firebolt conversion cost?

Firebolt is scoped and priced to your specific hardware and peripheral configuration rather than sold at a flat per-device rate, so the honest answer is that it depends on your fleet.

A full implementation across every device variant and peripheral can carry a real engineering lift. Where that support work is large, it may require meaningful non-recurring engineering before a true proof of concept. Firebolt is not free, not bundled into the subscription, and not uniformly priced. What it saves against a hardware refresh is worth modeling for your own fleet rather than taking from a page like this one.

You don't need new hardware to get off Windows

When an operating system reaches end of life, the default response is to replace the hardware running it. Budget a replacement fleet, schedule the installs, treat the capital request as the responsible move. The reflex is established enough that most replacement plans never pause on the question of whether the hardware needed replacing.

It usually didn't. Hardware lifespan and OS support windows are separate clocks, and treating them as one clock is a capital-planning error rather than a technical necessity. A 2016-vintage terminal that has run a point-of-sale application reliably for eight years is not always at the end of its physical life. What expired is one operating system and the certificate chain underneath it. Both of those are software facts.

A conversion severs the two, retiring a dying OS on its own schedule while the capital you already spent on terminals keeps earning. Every other route off Windows does more than that: it keeps you inside the Microsoft lifecycle, re-platforms your application layer, or lands new machines to solve a software problem.

Device management vendors can't answer this, and the reason is structural rather than competitive. General-purpose and dedicated MDMs manage Android after Android exists on a device. None of them put Android on a Windows x86 terminal in the first place. Esper can, because Esper owns the OS.

The mechanism travels beyond Esper's own hands, too. A third-party integrator has executed field conversions at franchise scale independently of Esper's team, with a reported success rate above 95% on the remote bootstrap.

The enemy here is the rip-and-replace default, not any hardware maker. OEMs build good terminals. The argument is against a planning assumption. In the end a refresh may be the right answer. We are here to help you figure it out.

Firebolt lets a fleet outlive its operating system

Firebolt converts x86 devices from an unsupported Windows install to Esper Foundation for Android on the same hardware, so an end-of-life date costs a company its operating system instead of its fleet.

‍Learn more about Esper Firebolt

FAQ

Can you install Android on a device currently running Windows?

Yes. Firebolt converts x86 devices from Windows to Esper Foundation for Android on the same hardware. Whether the existing Windows partition is preserved depends on which commitment you scope: a dual-boot install keeps it, a clean install replaces it.

Can a device run both Windows and Android during a migration?

Yes, on a dual-boot install. The default operating system is configured by Firebolt, and the Windows partition is preserved so the conversion stays reversible until you commit. Dual-boot supports Android up to version 13 on x86 hardware.

Can you roll back to Windows after converting to Android?

Only on a dual-boot install, where the Windows partition survives and reversal is a documented restore operation. A clean install leaves no Windows partition to return to, so getting that device back on Windows means a fresh install from your own media rather than a restore.

Do you have to replace hardware when Windows 10 IoT reaches end of life?

No. If the hardware is healthy and your application has an Android build, the operating system can be converted instead of refreshing the fleet. Windows 10 IoT Enterprise LTSB 2016 reaches end of security support on October 13, 2026, which is the deadline driving most of these conversions.

Is Firebolt a self-serve tool you can download?

No. It's an assisted engagement scoped and priced to your specific devices and peripherals, not a uniform download or a flat per-device rate. Esper confirms eligibility during a scoped evaluation before any commitment. 

Can any Windows POS fleet be converted to Android?

No. Eligibility clears two gates: whether Foundation can run on the hardware and required peripherals, and whether your point-of-sale or kiosk application has an Android build. Windows-only application software can't be converted in place, and that gate cuts across every hardware brand.

What runs on the device after the conversion, and what does it require?

Esper Foundation, a purpose-built Android OS for dedicated devices, with built-in OTA infrastructure, the Foundation SDK, and Esper device management through the Esper console. A converted fleet runs on an ongoing Foundation Android operating system and Deploy device management subscription.