The Hardware Problem Nobody Mentions During Software Demos

Cisco's 2025 Global Networking Trends Report found that 40% of enterprise network infrastructure is aging or obsolete. Not "could be upgraded for better performance" — aging to the point where it constrains what software the organization can run. That statistic doesn't account for field environments, multi-site operations with inconsistent connectivity, or the reality that many teams are running hardware purchased under a budget cycle that predated the software they're now being asked to adopt.

In The Problem with Generic Tech Recommendations, I listed equipment and existing hardware as one of eight variables that should inform any technology recommendation. It's the one that surfaces last in most evaluations — usually after the contract is signed, during implementation, when someone discovers that the software requires bandwidth, processing power, or device capabilities that parts of the organization simply don't have.

The demo environment isn't the deployment environment

Software demos run on current-generation hardware, fast and stable internet connections, and clean test data. This is reasonable for demonstrating capability. It's misleading for evaluating fit.

A warehouse management system that performs beautifully on a demo laptop with a fiber connection behaves differently on a five-year-old rugged tablet over a cellular hotspot in a steel-framed building. A field service application that loads in two seconds on the vendor's conference room Wi-Fi takes forty-five seconds when a technician is on-site at a rural facility with intermittent LTE coverage. A collaboration platform that streams video seamlessly in the vendor's office becomes unusable at a location where the shared internet connection is already saturated by operational systems.

These aren't edge cases. For companies operating across multiple physical locations — retail chains, healthcare networks, manufacturing operations with distributed facilities, field service organizations — the worst-performing environment is the one that determines whether the software is viable. This is why recommendations that skip discovery fail so consistently — they're tested against the demo, not the deployment. The demo shows the ceiling. The deployment reveals the floor.

Where hardware constraints actually show up

The constraints are more varied than most evaluations account for.

• Device age and capability. Not every organization refreshes hardware on a three-year cycle. Many operate devices until failure, which means the fleet includes a range of ages, operating system versions, and processing capabilities. Software that requires a minimum OS version released in the last two years may exclude 20-30% of the devices in actual use. Browser-based tools that depend on features available only in recent browser versions create the same problem less visibly — the software "works" but renders incorrectly or runs slowly on older browsers that the devices can support.
• Connectivity variation. Ookla's Speedtest Global Index data consistently shows wide variance in connection speeds even within the same metro area, and the gap widens dramatically for rural and industrial locations. A software platform that assumes consistent 50+ Mbps broadband is making an infrastructure assumption that many locations can't meet. Offline capability, progressive loading, and low-bandwidth modes aren't luxury features — they're requirements for any team that operates outside a single well-connected office.
• Environmental factors. Temperature extremes, dust, moisture, vibration, and glare all affect hardware performance and usability. A touchscreen interface designed for an office environment may be unusable with work gloves in a cold storage facility. A tablet-based inspection system that overheats in direct sunlight is effectively unavailable for four months of the year in certain climates. These aren't software bugs — they're hardware-environment interactions that the software recommendation didn't account for.
• Peripheral and integration dependencies. Enterprise software doesn't operate in isolation. It connects to printers, scanners, label makers, payment terminals, sensors, and legacy systems through interfaces that may or may not be compatible with the new platform. A recommendation that focuses on the software's features without inventorying what it needs to connect to misses a significant category of deployment risk.

What a hardware-aware evaluation looks like

The goal isn't to reject any software that doesn't run on the oldest device in the fleet. It's to make the hardware constraint visible before the purchasing decision, so the total cost and timeline include what's actually required to make the software work.

• Inventory the real environment. Document what hardware is in use across every location where the software will be deployed — device models, OS versions, browser versions, connection speeds, and environmental conditions. This inventory frequently reveals a wider range than leadership assumed, because the headquarters environment is rarely representative of field or branch conditions.
• Test at the floor, not the ceiling. Request a trial deployment on the oldest hardware and slowest connection in your environment. If the vendor only supports testing on recommended hardware, that's useful information — it tells you they've optimized for a narrower environment than yours.
• Calculate the hidden hardware cost. If the software requires hardware upgrades to function, those upgrades are part of the total cost of ownership. A platform with a lower license fee that requires $200,000 in hardware refresh (a classic self-hosted vs. cloud tradeoff) across forty locations isn't cheaper than a higher-licensed alternative that runs on existing equipment. This math is straightforward but almost never presented in the initial comparison.
• Evaluate degraded-mode behavior. What happens when connectivity drops? Does the application queue transactions and sync later, or does it fail? What happens on a device with half the recommended RAM — does it run slowly or crash? Software that degrades gracefully under real-world constraints is more valuable in distributed environments than software that performs optimally only under ideal conditions.

Why this keeps getting overlooked

Hardware constraints are unglamorous. They don't appear in feature comparison matrices. Vendors don't volunteer that their platform performs poorly on aging equipment, because the comparison framework rewards capability, not compatibility. The evaluation process — demos, feature comparisons, reference checks — is designed to surface what the software can do, not where it breaks.

The result is a consistent pattern: organizations select software based on capability, discover hardware constraints during implementation — a pattern that also drives up total cost of ownership significantly, absorb unbudgeted hardware costs to make the software work, and either succeed at a higher total cost than planned or deploy partially, with the locations that needed the software most getting it last because their infrastructure needed the most work.

This is preventable. Not by choosing less capable software, but by making the deployment environment part of the evaluation from the beginning. The hardware your team actually uses is a constraint that the recommendation has to survive contact with — and a recommendation that ignores it isn't a recommendation for your organization. It's a recommendation for a hypothetical one.

Related reading

• Stop Watching What Everyone Else Is Building
• What I Tell Every CEO Who Asks Me About AI

Frequently asked questions

How do I evaluate software compatibility with aging hardware?

Start by documenting the actual hardware in use across all deployment locations — device models, OS versions, available memory, and connection speeds. Then request a trial or proof-of-concept deployment on the oldest and least capable devices in your fleet, not just the newest ones. If the vendor's minimum requirements exclude a significant portion of your equipment, factor the hardware refresh cost into the total cost of ownership before comparing options.

Should we just upgrade our hardware before adopting new software?

Sometimes, but the sequencing matters. Upgrading hardware to meet the requirements of a specific software product locks you into that product's infrastructure assumptions. A better approach is to assess your hardware environment independently, plan upgrades based on operational needs and lifecycle, and then evaluate software within the constraints of the realistic upgrade timeline. Hardware refresh cycles and software adoption cycles don't have to be coupled, and coupling them often creates budget pressure that compresses evaluation time.

What if our team operates in environments with unreliable connectivity?

Prioritize software that supports offline or low-bandwidth operation — the ability to queue data locally and sync when connectivity returns. This isn't a niche requirement. Field service, logistics, healthcare, retail, agriculture, and construction all routinely operate in environments where connectivity is intermittent. Any software evaluation for these contexts should include explicit testing under degraded network conditions, not just confirmation that an "offline mode" exists in the feature list.