Moving an organisation to a new endpoint platform is not an imaging exercise. It is a controlled change to hardware, applications, identity, networks, policies and support. The quickest route to a reliable FydeOS deployment is therefore to make the first rollout small enough to observe and representative enough to teach you something useful.
This guide provides a repeatable path from the first device inventory to a managed production fleet.
| Phase | Owner | Required output | Exit criterion |
|---|---|---|---|
| Discovery | Business owner and IT | Target users, workflows and constraints | Scope and exclusions are approved |
| Compatibility testing | IT and application owners | Device, application and peripheral results | No unknown blocker remains in the pilot scope |
| Policy design | Security and endpoint administrators | Baseline, group and exception policies | Effective settings are verified on representative devices |
| Pilot | Service owner and pilot users | Acceptance results, incidents and support effort | Agreed workflow, recovery and data tests pass |
| Wave rollout | Deployment lead | Batch plan, stop condition and communication | Each wave meets its acceptance threshold |
| Handover | Operations and service desk | Inventory, runbooks and ownership | Support can operate and recover the fleet |
1. Define the job before choosing the device
Start with users and workflows rather than a hardware count. Separate employees, shared workstations, classrooms, public-access terminals and single-purpose kiosks because each group needs a different sign-in model, application set and support process.
For every target group, record:
- the work that must be completed on the device;
- the identity provider and sign-in experience;
- required web, Android, Linux or remote applications;
- networks, certificates, proxies, VPNs and printers;
- local storage and data-retention rules;
- accessibility and peripheral requirements;
- expected service hours and recovery targets.
This becomes the scope against which a pilot can be accepted or rejected.
2. Build a model-level device inventory
Do not treat a fleet as a list of brand names. Two devices sold under the same family can contain different wireless adapters, touch controllers or storage devices. Record the exact model and, where practical, the important hardware variants.
| Inventory field | Why it matters |
|---|---|
| Model and processor architecture | Determines which FydeOS build and applications should be evaluated |
| Memory and storage | Influences local workload capacity and update headroom |
| Graphics, display and touch | Important for multi-display, touch and presentation workflows |
| Wi-Fi, Ethernet and Bluetooth | Must work with the organisation's real network and accessories |
| Camera, microphone and audio | Required for meetings, teaching and service desks |
| Docks, printers and specialist peripherals | Often reveal deployment blockers that a basic boot test misses |
| Firmware and boot configuration | Affects installation, recovery and operational support |
Choose at least one representative device from every material hardware group for testing. Compatibility on one model should not be assumed to prove compatibility on another.
3. Classify every application
Create an application register and place each workload into one of four paths:
- Web application: verify browser features, extensions, downloads, uploads, camera or microphone permissions and offline behaviour.
- Android application: confirm that the selected FydeOS edition and hardware support the required Android environment, then test the exact application and licence.
- Linux application: validate architecture, performance, updates, storage and support responsibilities.
- Windows-dependent application: decide whether it can move to a web service, VDI or remote desktop, or whether an exception device must remain.
Test business processes, not merely whether an application opens. Printing an invoice, joining a meeting, uploading a large file and authenticating with a certificate are better tests than reaching a login page.
4. Prepare identity and network access
Document how users and devices will authenticate before enrolment begins. Include organisational accounts, guest access, Wi-Fi, proxy settings, certificates, internal services and any segmented networks.
FydeOS Management Cloud can apply device, user and application policies. Organise the pilot into logical units that match real responsibilities, such as location, department, device ownership or workload. Keep the first policy set deliberately small: a known baseline is easier to diagnose than hundreds of settings changed at once.
5. Choose manual or zero-touch enrolment
Manual enrolment is useful for a small pilot because an administrator can observe every setup step. For repeatable fleet provisioning, FydeOS also supports a Zero-Touch Enrolment image that can register a device with the organisation after first boot and network connection.
Whichever method you use, document:
- who is authorised to enrol and de-enrol devices;
- which licence should be assigned;
- which organisational unit receives the device;
- what happens when enrolment fails;
- how a device is recovered, reassigned or securely erased.
See the official device enrolment guide for the current console workflow.
6. Build policy layers, not one giant configuration
A maintainable policy design normally has three layers:
- Fleet baseline: update behaviour, core network settings and organisation-wide restrictions.
- Group policy: applications, browser settings and peripherals needed by a department or location.
- Exception policy: a documented deviation for a small, named device group.
Record the owner and reason for every exception. Allow time for policy propagation and verify the effective configuration on the device instead of assuming that saving a console setting completes the change.
7. Agree pilot acceptance criteria
Use evidence that can be reproduced by another administrator.
| Area | Example acceptance test |
|---|---|
| Enrolment | A reset device reaches the correct organisational unit and receives the intended baseline |
| Applications | Every critical user journey is completed using production-like accounts and data |
| Network | Wi-Fi, proxy, certificates and internal services work on each target site |
| Peripherals | Required docks, displays, cameras, printers and scanners pass a documented test |
| Updates | The team can stage or defer updates and follow a documented recovery, reimage or replacement procedure when acceptance checks fail |
| Support | The service desk can identify the device, collect useful information and follow a recovery runbook |
| Data handling | Sign-out, local storage, downloads and device reassignment follow organisational policy |
Run the pilot long enough to include normal work, an update cycle and at least one recovery exercise.
8. Roll out in waves with a stop condition
Expand by a defined unit such as one office, one classroom or one device model. For each wave, set a maximum failure rate, define support capacity and establish a rollback criterion. A deployment calendar should include owner, device count, policy version, communication plan and post-wave review.
Do not use the pilot only to prove that FydeOS works. Use it to discover which users or workloads should not move yet.
Deployment checklist
- Target users and workflows are documented.
- Hardware groups and representative devices are identified.
- Business-critical applications and peripherals have owners.
- Identity, network and certificate requirements are tested.
- Enrolment, licensing and organisational units are defined.
- Baseline, group and exception policies are documented.
- Acceptance tests and rollback conditions are approved.
- Service desk and recovery procedures have been rehearsed.
Use the rollout plan with a representative pilot
If the rollout includes existing hardware, use the older PC compatibility checklist to assess each model group.
Prepare your device inventory, application register and target workflow before requesting a trial. The FydeOS Enterprise team can help you define a pilot around the hardware and operating conditions your organisation actually uses.