Every organization that has successfully deployed and managed a device fleet at scale has a collection of lessons that came from the first deployment. Some are organizational. Some are technical. Some are about vendor selection and some are about internal process. Almost universally, the people who went through the first deployment wish they had known these things before they started rather than after.
None of these lessons require learning the hard way. They are predictable, common, and entirely avoidable with the right preparation.
“We should have standardized hardware from the start”
The most consistent structural lesson from first-time MDM deployments is the cost of hardware fragmentation. When the initial device purchases were made opportunistically, different teams bought different models, different OS versions, or different manufacturers without considering how the diversity would affect management. By the time an MDM platform is in place, the fleet has five device types instead of two, and each one has its own enrollment quirks, compatibility considerations, and update cadence.
Standardizing on a defined set of approved hardware models before the first device is purchased makes every subsequent management task simpler. The configuration profile works the same way across every device. The enrollment process is identical. Troubleshooting follows the same steps. Hardware refresh cycles are predictable.
This does not mean every location needs identical hardware. Moki’s platform manages iOS, Android, and BrightSign simultaneously. But within each platform, limiting to one or two approved models per use case dramatically reduces management complexity.
“We enrolled devices before we built the configuration profiles”
Enrollment without configuration is a common sequencing mistake in first deployments. Devices are enrolled into the MDM to get them into the system, and the plan is to configure them properly afterward. But in practice, devices that are enrolled without a configuration profile applied immediately can end up in the field in an unconfigured state, and reconfiguring deployed devices remotely is more complicated than configuring them correctly before they ship.
The correct sequence is to define and test configuration profiles in the MDM platform first, then begin enrollment. When devices enroll, they receive the correct profile immediately and are deployment-ready from the moment enrollment completes.
Moki’s configuration workflow supports this sequence. Profiles are built and tested in the dashboard before any devices are enrolled, and the enrollment process applies the correct profile automatically based on the device group assignment.
“We underestimated how important device grouping would be”
Device grouping seems like a minor organizational detail at the start of a deployment. It becomes a critical operational capability as the fleet grows. A fleet with no logical grouping structure means that every update, content push, or configuration change has to be applied individually or blasted to all devices indiscriminately. Neither option is acceptable at scale.
Experienced MDM teams build their grouping structure before enrollment, typically organized around three dimensions: location, device type or use case, and platform. With those three layers of grouping in place, a content update for digital signage displays at a specific region of stores is a single targeted operation. A firmware update for one Android model in the fleet does not touch iOS devices or BrightSign players.
The grouping structure should be documented in the device deployment playbook so new devices are always enrolled into the correct group and the structure is maintained as the fleet grows.
“We did not think about alert routing until a device had been down for six hours”
This is the alert configuration lesson, and it comes up in nearly every first-deployment retrospective. Alert configuration was deprioritized during the rollout, devices went live without monitoring thresholds set, and the first indication of a problem was a store manager calling to report a kiosk that had been dark since the morning shift started.
The fix is straightforward: alert configuration is not optional and it should be completed before devices go live, not added later. Setting offline thresholds, routing notifications to the right people, and testing that alerts actually fire takes a fraction of the time it takes to manage one avoidable escalation.
The secondary lesson in this category is that alerts need to route to someone who can act on them. An alert that goes to a general IT inbox that is not monitored on weekends provides no value for a customer-facing device fleet that operates seven days a week.
“We assumed IT could handle enrollment manually for the first deployment”
Manual enrollment at scale is underestimated every time. At five devices, manual enrollment is trivial. At 50 devices, it is a half-day project. At 500 devices across 40 locations, manual enrollment is a weeks-long logistical effort with significant room for configuration error at each device.
Zero-touch enrollment for Android and Apple Business Manager for iOS exist specifically to solve this problem, and organizations that plan to scale beyond a small pilot should invest in setting up automated enrollment from the beginning. The setup overhead is front-loaded but the payoff is linear with every additional device deployed.
The practical implication: if zero-touch enrollment is the right answer for the deployment (and it usually is for any fleet over 20 devices), the device purchasing process has to account for it. Devices must be purchased through zero-touch compatible resellers and registered in the enrollment portal before they ship. That requires coordinating procurement before devices are ordered, not after they arrive.
“We did not test the full deployment scenario before going live”
First deployments often test components in isolation. The enrollment process is tested. The configuration profile is tested. The app is tested. What does not get tested is the full scenario from factory-fresh device to live customer-facing deployment.
When the full scenario test does not happen, integration issues surface during the actual rollout: the Wi-Fi profile does not apply before the enrollment screen requires connectivity, the app does not install silently as expected because a Managed Google Play approval step was missed, or Single App Mode activates before the app is fully downloaded and the device ends up in a locked state with no app running.
Running at least one device through the complete end-to-end process, from unboxing through live customer-facing operation, before the full fleet deployment begins catches these issues where they are easy to fix rather than at scale where they are not.
“We did not document anything the first person learned”
When the first MDM deployment is owned by one person or a small team, the institutional knowledge of how it was set up lives in their heads rather than in documentation. When that person leaves, is reassigned, or goes on vacation during a deployment issue, the knowledge gap is immediately and painfully apparent.
A device deployment playbook does not need to be elaborate. It needs to document the configuration profile structure, the enrollment process, the device grouping logic, the alert configuration, and the escalation path for device problems. Written once and maintained as the fleet evolves, it makes every future deployment faster and every staffing change less risky.
“We picked an MDM vendor on feature lists instead of support experience”
Feature parity between MDM platforms is closer than it appears on comparison matrices. Most platforms can enroll a device, push an app, and lock a screen. What is not on the feature matrix is what happens when the enrollment fails at 8 PM before a store opens at 9 AM, or when a configuration change causes an unexpected device behavior across the fleet.
Support quality, response time, and the willingness to dig into a specific issue rather than refer to documentation are differentiating factors that only become apparent after a problem occurs. Moki’s support model is built around resolving tickets on the first interaction, with a team that has direct access to devices through remote control to diagnose problems rather than troubleshooting blindly.
Before committing to an MDM vendor, the questions to ask are: what does support access look like at the tier we need, what is the resolution time expectation for critical issues, and can the support team access our devices directly to troubleshoot? The answers matter more in practice than any additional feature on the comparison sheet.
Starting the Next Deployment Differently
None of these lessons require a painful first deployment to internalize. They are the accumulated practical wisdom of teams who have been through the process and have thought carefully about what they would do differently.
Moki’s onboarding process is structured to surface and address these common first-deployment challenges before they become problems. From enrollment method selection through configuration profile design, alert setup, and deployment testing, the onboarding team works through the decisions that determine whether a deployment is smooth or difficult.
Schedule a Moki demo to walk through your specific deployment scenario before you begin, or start a free trial to begin building and testing your configuration. Moki’s eBook library and FAQ are also good starting points for teams planning their first deployment and looking to get ahead of the most common challenges.