Most teams running Zebra scanners manage them twice: once in their actual device platform, and again through StageNow staging and manual file-pushing just to get a scanner configured in the field. That split is slow, error-prone, and usually depends on the one person who knows the hidden file paths. The rest of the team works around the gap or waits for that person to be available.

The distribution half of that problem doesn't have to live outside the platform that governs the rest of your fleet. When you can take the DataWedge profile or MX config you've built and deploy it through the same system that controls every other device setting, you stop running two parallel distribution workflows for one category of hardware.

That means you can deploy and govern Zebra scanner configuration from the same platform that runs the rest of your fleet, instead of distributing DataWedge profiles and MX settings through a separate StageNow-and-manual-file workflow. You still author the profiles in Zebra's tooling, but deployment, enforcement, and lifecycle move into Blueprints alongside your apps and policies.

TL;DR

• You can deploy and govern Zebra scanner config (DataWedge profiles and MX configuration) through the same platform and lifecycle that runs the rest of your fleet.
• You still author profiles in Zebra's tooling (StageNow or the DataWedge app on a reference device). What moves into Esper is distribution, enforcement, and lifecycle, not the authoring step.
• Esper handles this inside Blueprints: take your DataWedge .db file or MX XML, attach it to a blueprint, deploy it to your Zebra Android devices. Scanner distribution stops being a specialist side-task and becomes part of normal fleet operations.
• Availability: this is rolling out for Zebra Android devices behind a feature flag, enabled for design-partner customers first. Support for additional rugged OEMs (Honeywell, Datalogic) is on the roadmap, not available today. 
• Config syntax and field specifics: defer to Zebra OEMConfig documentation and Esper documentation for parameter-level detail.

Why Zebra scanner config lives outside your device platform today

Every platform that touches Zebra scanners eventually runs into the same split. The MDM or device management platform controls the device: apps, OS policy, kiosk lockdown, network config, compliance rules. But the scanner configuration itself sits in a different stack entirely.

StageNow handles the staging and distribution. DataWedge profiles (.db files) define what the scanner does when the trigger pulls: which symbologies are active, how intents fire, what format the barcode data takes when it hits the app. MX configuration (XML) and OEMConfig payloads set hardware-level parameters: trigger mode, connectivity behavior, power management, display brightness.

Those configurations don't flow through the same system that controls the rest of the device. They flow through StageNow barcodes, manual file copies to specific directories, or custom scripts that someone wrote two years ago and nobody wants to touch. The result is a parallel workflow. One system governs 90% of the device. A different set of tools and tribal knowledge governs the scanner.

This split persists for a straightforward reason: scanner configuration is OEM-specific. Zebra's DataWedge API, MX framework, and OEMConfig schema are proprietary to Zebra hardware. General-purpose MDMs never absorbed that layer because it's niche and deep. Dedicated device platforms mostly ignored it for the same reason. So the config stayed in StageNow, and teams built manual distribution processes around the gap.

The cost isn't dramatic on day one. It's cumulative. Every new store opening, every device refresh, every scanner replacement runs through the same manual steps. The person who knows the DataWedge profile structure and the right file paths becomes a bottleneck. When that person is out, scanner deployments stall. When the profile needs to change across 500 devices, someone is scripting a push or walking through StageNow staging one site at a time.

How Esper manages Zebra scanner config inside Blueprints

The alternative is bringing scanner config distribution into the same system that already controls the device. Not a separate integration. Not a side tool. The same define, configure, attach, deploy flow that governs every other setting on the device.

In Esper, scanner configuration for Zebra Android devices runs through Blueprints. A blueprint is the declarative definition of what a device should look like: apps, policies, network config, and now scanner settings. When you add scanner configuration to a blueprint, it deploys and enforces alongside everything else.

Three configuration methods are supported for Zebra scanner config inside Blueprints today:

• ‍DataWedge profile deployment: Export the .db file that defines your DataWedge profile from your reference device or StageNow, attach it to a blueprint, and deploy. Every device that receives that blueprint gets the same scanner behavior: symbology selection, intent configuration, data formatting rules. No StageNow barcode staging per site. No manual file copying device by device.‍
• MX configuration via XML: Zebra's MX framework exposes hardware-level controls: symbology enable/disable, trigger mode, connectivity settings, kiosk parameters, power management. Export the MX XML and upload it into the blueprint configuration, and those settings deploy as part of the blueprint lifecycle. (MX 11–13 is the supported baseline.)‍
• OEMConfig managed configurations: Add Zebra's OEMConfig app and set device policies through Blueprints — select settings directly or paste/upload a JSON config, and the blueprint delivers it to every enrolled device. Covers the settings Zebra exposes through OEMConfig, with schema-driven fields instead of hand-built files. No JSON authoring from scratch. No separate deployment path — it publishes and converges with the rest of the blueprint settings.

Both methods run through the same RBAC and policy controls that govern every other blueprint setting. The same roles that control who can modify app policy or network config also control who can modify scanner settings.

Here's the honest boundary, and it's the same one that runs through how dedicated fleets should think about device state: Esper reports the execution outcome of a scanner config deployment — every deployment resolves to a terminal state (delivered or failed with a reason), with no silent failures. What Esper does not do today is read the applied DataWedge state back off the device and confirm the scanner is running exactly that configuration, because the OEM contract doesn't expose reliable readback for those settings. That's not an Esper limitation; it's a DataWedge one. The platform tells you what it deployed and whether the deployment completed. It doesn't pretend to verify scanner runtime state it can't see.

What's not available today: Support for non-Zebra rugged OEMs (Honeywell, Datalogic) is on the roadmap, not shipping. The scope today is a curated subset of Zebra configuration capabilities, deliberately bounded.

For MX and OEMConfig field specifics, parameter syntax, and DataWedge profile structure, refer to Zebra's documentation and Esper's documentation.

Making scanner distribution something anyone on the team can do

The operational payoff isn't just fewer tools. It's fewer specialists in the distribution path.

When scanner config distribution lives in StageNow and manual scripts, deploying a new scanner or refreshing an existing one requires someone who understands the DataWedge profile format, knows which directory the .db file goes in, and can navigate StageNow's staging workflow at each site. That's usually one person on the team. Sometimes it's the person who set it up originally and documented nothing.

When scanner config lives inside a blueprint, deploying a configured scanner is the same motion as deploying any other device. Attach the blueprint. Power on the device. The scanner configuration arrives with everything else. The operator who provisions a kiosk or a POS terminal can provision a scanner the same way, because the workflow is identical.

This matters most during fleet refreshes and site rollouts. A scanner fleet refresh that used to require the StageNow specialist at every step becomes something any operator can execute, because the scanner configuration is embedded in the same blueprint that defines the rest of the device state. New site? Same blueprint, same deployment motion, same result.

The compounding effect is real. Every device refresh, every new location, every replacement device runs through the same automated distribution path instead of the manual one. The team that used to wait for the one StageNow expert now runs scanner deployments on the same schedule as everything else.

For teams running Blueprints across their fleet, adding scanner config to that flow isn't a new capability to learn. It's the same define-and-attach pattern they already use for app policy, network config, and compliance rules.

Why moving scanner config into Blueprints is a lifecycle decision, not a feature swap

Framing this as "Esper replaces StageNow" overstates what ships today and misses the actual point. StageNow is a staging and authoring tool. Esper is a device infrastructure platform. The argument isn't that one tool replaces another tool one-for-one. The argument is that scanner configuration should be governed by the same lifecycle that already runs your fleet, instead of distributed through a parallel specialist workflow bolted on the side.

You still author the DataWedge profile or MX config in Zebra's tooling today. What changes is everything after authoring. When scanner config runs through Blueprints, it inherits what the blueprint lifecycle already provides: version control, RBAC, staged rollouts, and per-device execution visibility. You don't get those things by staging the same profile through StageNow at every site. You get them by moving scanner config distribution into the infrastructure layer that was designed to enforce device state at scale.

The honest boundary matters here. Today, this means a curated Zebra configuration subset: OEMConfig, DataWedge profile and MX deployment for Zebra Android devices, rolling out behind a feature flag to design-partner customers. The roadmap expands OEM coverage and adds a UI-based editor, but the current shipping capability is Zebra-only.

The directional claim is real: scanner configuration should be governed by the same platform, the same policy engine, and the same deployment lifecycle as every other device setting. 

This is the same pattern that plays out across tool sprawl in device fleets. Every specialized side-tool that runs a parallel workflow adds operational overhead, tribal knowledge dependencies, and failure modes the primary platform can't see or control. Moving scanner config distribution into the primary platform isn't about features. It's about reducing the surface area of things that can go wrong when nobody is watching.

Bottom line

Zebra scanner configuration doesn't have to be distributed through a specialist StageNow ritual bolted onto your device platform. Authored in Zebra's tooling but deployed and governed inside the same blueprint lifecycle that runs every other device in your fleet, scanner setup becomes something any operator can deploy — not a per-site workflow only one person knows.

Book a Demo

Frequently Asked Questions

Does this replace StageNow entirely?

Not entirely, and not yet. You still author DataWedge profiles and MX configs in Zebra's tooling. What moves into Esper is the distribution, enforcement, and lifecycle: instead of staging through StageNow barcodes site by site, you attach the exported config to a blueprint and deploy it across the fleet. For the distribution and governance half of the workflow, StageNow is no longer in the path. For authoring, it (or the DataWedge app on a reference device) still is.

What Zebra scanner settings can I configure through Esper today?

Three methods: DataWedge profiles (uploaded as .db files, defining symbology selection, intent configuration, and data formatting) and MX configuration (uploaded as XML, covering symbologies, trigger modes, connectivity, kiosk settings, and power management; MX 11–13 baseline) and OEMConfig (Uploaded as JSON file or giving you schema-based access to Zebra device settings within Blueprints without hand-building JSON). For the full list of supported fields, refer to Zebra's documentation and Esper's docs.

Is this generally available?

It's rolling out for Zebra Android devices behind a feature flag, enabled for design-partner customers first rather than switched on for every account at once. If you're running Zebra rugged devices and want access, that's a conversation with your Esper contact about enablement.

Does this work with non-Zebra scanners?

Not today. The initial release supports Zebra Android devices only. Support for additional rugged OEMs such as Honeywell and Datalogic is on the roadmap.

How does scanner config deploy to devices, and can I confirm it worked?

Scanner configuration attaches to a blueprint and deploys as part of the normal blueprint lifecycle. When a device receives the blueprint, the scanner settings deploy alongside every other setting. Every deployment resolves to a terminal state — delivered, failed with a categorized reason, or skipped with a reason — so you're never left guessing whether something silently didn't run. One honest caveat: Esper reports the deployment outcome, not a readback of the scanner's live runtime state, because DataWedge doesn't expose reliable applied-state readback. You can confirm the config was deployed; verifying the scanner is running exactly that profile still requires an on-device check.

Do I need to know MX or OEMConfig XML to use this?

Today, you bring the configuration in as a file you've already authored in Zebra's tooling, so you work at the level of exporting and uploading rather than hand-writing XML from scratch. 

Can I roll out scanner config changes to a subset of devices first?

Yes. Blueprints support staged rollouts. You can deploy a scanner configuration change to a test group, check the per-device execution status, and then expand to the full fleet. The same staged deployment controls that apply to any blueprint change apply to scanner config changes.