Every device fleet eventually reaches the point where hardware needs to be replaced. Batteries degrade. Processing speed falls behind updated applications. Manufacturer support ends. Models that were standard three years ago are no longer available for replacement units when one fails. The hardware refresh is not a question of if but when, and the organizations that handle it smoothly are the ones that planned for it well in advance.
A poorly executed hardware refresh disrupts operations at every location it touches. Devices are down while replacements are configured. New hardware arrives without the correct apps installed. Staff at locations receive devices they do not know how to swap. Content or configuration from the old device is lost and has to be rebuilt manually.
A well-executed refresh, supported by the right MDM platform and a structured plan, looks almost invisible from an operational standpoint. New devices arrive pre-configured, the swap takes minutes, and the location is back to full operation before the end of the business day.
When to Plan a Hardware Refresh
The biggest mistake in hardware refresh planning is waiting until devices start failing in the field to begin the process. By that point, the organization is managing replacements reactively, often paying premium pricing for urgent hardware procurement and spending IT resources on emergency deployments rather than planned rollouts.
Hardware refresh planning should begin when devices reach 70 to 80 percent of their defined useful life. For most tablet-based deployments, that means beginning refresh planning around years two to three of a three to five year lifecycle. For BrightSign players and other purpose-built hardware, the timeline may be longer, but the planning principle is the same.
Early planning provides several operational advantages. It allows procurement to happen through preferred channels including zero-touch compatible resellers rather than whatever is available under emergency conditions. It allows the new hardware to be tested with current applications before the rollout begins. It allows the refresh to be scheduled during lower-traffic periods rather than forced by a failure at an inconvenient time.
Step 1: Audit the Existing Fleet Before Ordering
Before purchasing replacement hardware, run a full inventory audit of the existing fleet through the Moki dashboard. The audit should confirm:
- The exact count of devices by type, location, and platform that are in the refresh scope
- The current configuration profile applied to each device group, which will serve as the template for new device configuration
- Which apps are installed at which versions, so the new device configuration matches exactly
- Any devices in the refresh scope that have already failed and been replaced with interim hardware, which may affect the count
- Any location-specific configuration variations that need to be carried forward to the new hardware
This audit prevents over-ordering, ensures configuration continuity, and surfaces any inconsistencies in the existing fleet that should be corrected rather than replicated on new hardware.
Step 2: Set Up New Device Configuration Profiles Before Hardware Arrives
New devices should never arrive at a location without their configuration already defined and tested in the MDM platform. The configuration work happens in Moki before the hardware ships, so that enrollment is the only step required when a device is powered on.
For Android refreshes using zero-touch enrollment, this means registering the new devices in the zero-touch portal and linking the correct Moki configuration profile before devices leave the warehouse. When the device is powered on at the location, it enrolls automatically and receives its full configuration without any manual setup.
For iOS refreshes using Apple Business Manager, new devices are assigned to the Moki MDM server in ABM before activation. When the device is powered on and connected to the internet, it is supervised, enrolled, and configured automatically.
For devices that cannot use automated enrollment, build and test the manual enrollment process so the person executing the swap can complete it with a documented procedure rather than figuring it out at the location during the swap.
Step 3: Pilot Before Full Rollout
Before refreshing the full fleet, pilot the new hardware at one or two locations. The pilot confirms several things that testing in a controlled environment cannot fully replicate:
- The new hardware performs correctly with all production applications at real-world transaction volumes
- The enrollment and configuration process works as expected in the actual network environment at deployment locations
- The swap process is executable by the person performing it, whether that is an IT technician, a field service partner, or a non-technical staff member at the location
- Any unexpected compatibility issues between the new hardware and existing peripherals, payment terminals, or network infrastructure are identified before they affect dozens of locations
Document any issues discovered during the pilot and resolve them before proceeding to full rollout. The time invested in a thorough pilot is consistently less than the time required to remediate problems discovered mid-rollout across 50 locations simultaneously.
Step 4: Plan the Rollout Sequence
For large fleets, a phased rollout sequence reduces operational risk compared to attempting all locations simultaneously. Sequence the rollout based on:
- Location priority: Highest-traffic locations benefit most from new hardware but carry the most operational risk if something goes wrong. Many organizations refresh lower-traffic locations first to build process confidence, then move to higher-traffic sites with a well-tested procedure.
- Geographic clustering: Grouping locations by geography reduces logistics costs and allows a single field technician or regional IT resource to complete multiple locations in one trip.
- Operational calendar: Avoid scheduling refreshes during peak business periods. Retail locations should not be refreshed during holiday seasons. Restaurant locations should not be refreshed during known high-volume periods.
Build the rollout schedule with buffer time between location groups so that problems discovered early in the rollout can be resolved before they affect later locations.
Step 5: Execute the Swap
The swap process at each location should follow a documented procedure that any qualified person can execute. The procedure should cover:
- Confirming the new device is enrolled in Moki and the correct configuration profile is applied before beginning the swap
- Verifying the new device is fully functional, including app launch, network connectivity, and kiosk lockdown if applicable
- Powering down the old device and documenting its serial number and asset tag for inventory update
- Performing the physical swap, including mounting hardware, cable connections, and peripheral pairing as applicable
- Confirming the new device is operating correctly in its live location before leaving the site or closing the support ticket
- Initiating remote wipe on the old device through the Moki dashboard before the device leaves the location
- Updating the physical asset inventory to reflect the swap, including the new device serial number and the decommission record for the old device
The remote wipe step is mandatory before any old device is transported or stored. Devices that have processed payment data or handled personal information must be wiped before leaving the deployment location.
Step 6: Decommission Old Hardware
Once old devices have been wiped and removed from Moki enrollment, they need to be formally decommissioned. Depending on the device’s age and condition, options include:
- Return to the manufacturer or reseller through a trade-in or buyback program
- Refurbishment and redeployment in a lower-intensity use case if the hardware is still functional
- Donation to a qualifying organization if hardware meets their needs and data has been wiped
- Disposal through a certified electronics recycler in compliance with applicable e-waste regulations
Maintain a record of how each decommissioned device was disposed of, including the wipe confirmation and the disposal method. For devices that handled sensitive data, this documentation is part of the compliance record.
Keeping Operations Running Throughout
The defining characteristic of a well-managed hardware refresh is that customers and staff at deployment locations experience no meaningful disruption. The combination of pre-configured new hardware, a tested swap procedure, and Moki’s remote management capabilities means each location is down for minutes rather than hours.
Moki’s platform supports every stage of the refresh process, from configuration profile management and automated enrollment through remote wipe of retired devices. Schedule a Moki demo to discuss how Moki supports hardware refresh workflows for your specific fleet, or start a free trial to begin building the configuration infrastructure that makes a future refresh straightforward. Moki’s case studies include examples of large-scale refresh projects executed with minimal operational disruption.