You’ve worked hard to achieve device scaling that meets your organization’s strategic goals. You’ve roadmapped and staffed for new site openings, designed deployment and provisioning flows, and built a support strategy that minimizes MTTR while balancing your team’s workload. But as your device count grows, you encounter the same challenge so many teams do. Old tooling can’t keep up, and scaling becomes about managing the pain, not enabling innovation. 

How did we end up here?

Visibility That Fails to Scale: The Reality on the Ground

Maintaining visibility for a fleet of edge devices running in the thousands (or tens of thousands) can feel like looking down at city traffic out the window of an airliner. You might be able to spot the worst congestion from 35,000 feet, but you’re missing a tremendous amount of detail, let alone the 360-degree perspective you’d need to see patterns or determine the root cause of a snarl. 

That’s exactly the level of visibility most device management tooling gives you: A tiny, top-of-the-world porthole through which to manage tremendous complexity on the ground. It doesn’t scale, and it introduces more blind spots the larger your fleet gets. 

The old saying may go “it is a poor carpenter who blames his tools,” but no one is going to suggest more hammers (additive manual work) are a viable alternative to a nail gun (automation at scale). Yet that’s effectively the approach traditional mobile device management (MDM) tools force IT leaders to defend: More staffing, more support, and more workarounds — not smarter solutions.

How Does Old Tooling Fail Modern Edge Device Fleets?

These are a few key areas traditional MDM tooling lets teams down as fleets expand.

• Device status as a “snapshot,” not a living state: Older MDM tooling was designed for one-and-done device configuration scripts where device state is recorded as a “snapshot” in time (e.g., successful script deployment, device boot, network connected, etc.), not ongoing visibility with live monitoring, device health, and granular update control.
• Assumptions of centralized versus edge distribution: Old device management solutions were built for single-site or campus-level device fleets, where “always online” local networks and ready physical access were a given. Enabling massive edge scale through remote diagnostics and resilient connectivity was not a priority.
• Complexity demands more resources, not more automation: Legacy MDMs were architected on the assumption that devices have a linear relationship with the resources to deploy and support them. The current explosion in device counts — and the extreme heterogeneity of form factors, OSes, and physical distribution — was never envisioned, and therefore no path to sustainably scaling that reality was, either.

Each of these factors can be further broken down by the many challenges they create in the field.

The gap between “device online” and “device healthy” is greater than ever

In the era of centrally managed corporate networks, online status was the gold standard for device health (or really, the only standard). If a device went offline or otherwise failed to check in, that was cause for investigation — but nearly any other kind of issue was left to end users to escalate. 

This simplistic model of device health was replicated in the MDM tooling many teams still use today, putting IT teams in a permanently reactive support posture. But in the age of modern edge device fleets, where thousands of end devices cannot be readily physically accessed (and are not even necessarily always online), this model quickly breaks down. IT teams can’t see the kinds of issues that can explode into major operational breakage, such as:

• Performance throttling
• App crashes
• Battery degradation
• Frequent peripheral disconnects
• Network instability
• Configuration drift
• Failed updates

Without visibility into these key indicators of device health, IT teams have to rely on employees or customers to flag problems with a device — problems they may not know how to describe, even with the help of remote support staff. Instead, they may just choose to avoid a device entirely, leading to a false “green” state in your dashboard. After all, if a device is online, that means it’s working as intended, right? With traditional MDM tools, that’s often all you have to go on.

Device Management for Complex Edge Fleets >

Scale and distribution are causing exponential blind spot growth

When IT leaders were responsible for managing devices across a single site or campus, hardware lifecycles, damage and theft, and device health were relatively known quantities to manage. Ready physical access to devices and a relatively narrow set of form factors and use cases to support meant growing the fleet footprint was largely predictable in terms of resourcing need and potential trouble points — systems and processes were finely tuned to the constraints they operated in.

Today, IT leaders are responsible for device fleets deployed across dozens or hundreds of sites, at regional or national scale. And each of those sites represents a diverse device ecosystem of form factors, operating systems, software, and their associated management tooling. For illustration, a single quick service restaurant might have:

• Stationary POS systems running Linux 
• Digital signage running Windows
• Mobile POS tablets running iOS 
• Self-ordering kiosks running custom Android

You could need three or even four separate device management frontends to see all of these devices for a single store, making a holistic site health assessment an extremely tedious and misaligned process (if not impossible), requiring manual reporting inside of a spreadsheet. This approach guarantees blind spots. Site health assessments must be kept to the absolute minimum number of shared reporting variables to scale, leaving you with the minimum viable level of visibility — and information that’s out of date the moment it’s collected.

Further, site-specific variables are simply lost when managing complex fleets with traditional MDM tools. 

• Site-specific networking issues: Are all the devices at a specific location experiencing network connectivity problems?
• Environmental variables: Are extreme temperatures or other environmental factors reducing hardware lifespan or performance?
• Usage and lifecycle: Do locations with extreme customer throughput need more devices, or to be placed on a fast track for upgrades because of greater wear and tear?

Without a comparative, real-time device health engine that allows you to break down all the devices at an individual site or business unit, you lack critical data about the cost, efficacy, and scalability of your fleet.

Lack of device visibility is locking IT teams out of automation, blocking business growth

If growing your device fleet means proportionally growing your admin and support staffing, you’re not in a sustainable position. Most IT leaders are being asked to do more in 2026 with the same resource they had in 2025, if not less than what they had before. Meanwhile, device counts keep growing. That means one thing: More automation.

The simple reality is that legacy MDM tools are at best apathetic to enabling automation, and at worst actively destructive to achieving it. These tools were built for a different time and operational mode, in which the growth of devices tended to be in lock-step with broader organizational growth. That meant the resources to deploy and support those devices would come along with them, and the tooling to manage them only needed to support more users and more entries in a database. In 2026, this feels a bit like describing the mainframe era of computing — something out of retro science fiction.

But unlike the old days, this isn’t just a matter of blocking the growth of devices. When fleet visibility doesn’t scale, it’s not just your fleet that doesn’t scale, it’s your business. And that’s put IT leaders in a seriously tough spot.

How Do I Escape the Device Visibility Gap?

We already know why these legacy MDM tools don’t scale. They mistake connectivity for health. They assume highly homogeneous fleet composition. They see devices as a series of snapshots, not a live state. In general, they impede the deep and always-on visibility that is fundamental for next-generation automation outcomes, like: 

• Self-healing devices
• Fully automated provisioning and deployment
• Remote diagnostics with automated bug reports
• Live device health analysis with automated issue flagging
• Automated fleet, region, site, and individual device-level reporting

These are the kinds of automations that support scale. If your team doesn’t have a pathway to achieving them, it’s time to conduct a basic assessment of your visibility gap. The following statements can help determine how severe your device visibility gap is.

• I’m not able to assess live device health factors (battery health, device performance, network stability, peripheral connectivity, device usage)
• I can’t readily assess my fleet health at the site, regional, or fleet level without manually querying multiple tools
• I don’t have a clear path to automating our device provisioning and deployment processes
• I can’t readily determine how many of my devices have drifted outside policy / compliance
• I don’t have a single dashboard where I can view devices with multiple operating systems
• I’m unable to see if a software or OS patch deployment has completed across my fleet

If more than two of the above statements are true for you, you likely have a significant fleet visibility gap. The way forward is building a plan to address it, step by step. While there’s no one “silver bullet” fix, there are ways to put your fleet on the path toward a more orchestrated, automated strategy.