Upper Grand District School Board (UGDSB) in Ontario, Canada, manages technology assets that can reach vendor end-of-life milestones while the underlying hardware is still functional. Replacing every retired device can put pressure on education budgets and contribute to electronic waste, but reusing devices without a clear security and support model introduces risks of its own.
UGDSB therefore launched a structured initiative to evaluate whether selected retired Chromebooks could be repurposed with FydeOS, a lightweight operating system based on ChromiumOS. The goal was not simply to install a different operating system. It was to determine whether the board could extend the useful life of existing hardware while maintaining its standards for security, privacy, management and support.
“Our objective was simple: determine whether we could responsibly extend the life of devices that still had useful hardware while maintaining the security, management, and support standards expected in a modern educational environment.”
— Peter Scantland, UGDSB ICT Manager
The challenge: useful hardware at the end of its primary lifecycle
UGDSB wanted to find a responsible way to:
- extend the lifespan of existing hardware;
- reduce unnecessary device disposal;
- support modern, web-based use cases;
- maintain security, privacy and operational standards;
- continue using existing Google Workspace for Education management practices; and
- increase access to computing resources without relying solely on new hardware purchases.
The ICT team compared several operating-system options for ageing Chromebook hardware. The project materials record concerns about end-of-life support for ChromeOS Flex in the evaluated context, poor performance with Ubuntu and Windows on the selected devices, and user-experience limitations with Lubuntu and Raspberry Pi OS.
Why FydeOS moved forward for evaluation
FydeOS provides a familiar, cloud-focused experience based on ChromiumOS, with support for web applications, Android applications and Linux environments. It can use local accounts or optional cloud integration, giving organisations flexibility in how devices are configured.
After comparative testing, UGDSB selected FydeOS for further evaluation. In the board's technical update for the hardware tested, FydeOS was reported to perform better than Ubuntu, ChromeOS, Windows and ChromeOS Flex. The same update recorded no crashes or recovery events during the test period. These observations apply to UGDSB's evaluated devices and test conditions rather than to every possible hardware configuration.
Security and governance came first
Security and privacy were foundational requirements. UGDSB's review considered the operating-system update cadence, patching, authentication, data storage, student-data risks, third-party services and acceptable deployment scenarios.
According to the approved project documentation, FydeOS:
- passed the board's internal security vetting;
- accepted the board's Google enterprise policy and could be managed in its Google environment; and
- supported locked-down software settings.
This work treated device reuse as a governed lifecycle programme, not simply an operating-system replacement.
An eight-phase path from feasibility to operations
UGDSB established an eight-phase framework before making any decision to scale:
- Discovery and feasibility: inventory devices, research support and licensing, and define possible use cases.
- Pilot planning: select representative devices, define success measures and document rollback.
- Technical testing: validate hardware, wireless connectivity, peripherals, battery health and performance.
- Security and compliance review: assess patching, authentication, data, privacy, third-party services and approved scenarios.
- Pilot deployment: use controlled environments and monitor stability, user experience and support incidents.
- Evaluation and decision: proceed, proceed with restrictions, or stop and retire the devices.
- Scaled deployment: create a standard image and workflow, deploy in batches and update asset records.
- Operational transition: define support boundaries, publish documentation, train support staff and set end-of-life criteria.
The project includes a clear safeguard: it can stop at any phase if security, stability or support risks are considered unacceptable.
Preparing for a potential 1,000-device build
UGDSB's technical planning material describes a potential 1,000-device build using parallel USB imaging. The proposed workflow allows one technician to handle multiple devices while parts of the build run unattended. The team's preparation and imaging efforts have averaged 10 devices per hour to date.
This figure is a reported result from UGDSB's current work, not a guarantee for other organisations. Actual throughput will depend on device condition, model consistency, imaging procedures, staffing and deployment requirements.
Results so far
At the point documented in the approved case study, UGDSB had:
- completed discovery and feasibility activities;
- completed the security and compliance review phase;
- reported no crashes or recovery events during technical testing;
- demonstrated compatibility with its existing Google enterprise policy and management practices;
- established a phased governance and deployment framework; and
- identified opportunities to extend hardware life and reduce electronic waste.
The next stages in the documented roadmap are pilot deployment, evaluation and an executive decision to proceed, proceed with restrictions, or retire the devices. Financial savings, deployment scale, user impact and educational outcomes will be assessed when those results are available.
A practical model for responsible device reuse
UGDSB's initiative shows that extending the life of retired Chromebooks is not only a technical question. A responsible programme also needs security review, operational ownership, measurable acceptance criteria, rollback plans and explicit decision gates.
For schools and other organisations managing end-of-life Chromebook fleets, FydeOS can provide a path worth evaluating on representative hardware. A controlled pilot helps confirm compatibility, management requirements and support costs before any wider rollout.