The real reasons Microsoft still dominates school computers

A school rarely chooses its desktop software on a clean sheet of paper. It inherits accounts, document archives, lesson templates, printers, assessment tools, staff habits, supplier contracts and years of informal workarounds. The visible question may be “Windows or Linux?”, but the operating decision is closer to “Which choice is least likely to interrupt teaching on Monday morning?” Institutional continuity usually beats licence ideology. Microsoft benefits because its products are already woven into email, identity, storage, classroom collaboration and administration. Microsoft’s own education portfolio presents these components as connected plans rather than isolated applications, with A3 and A5 adding desktop apps, security and management to the web-based A1 offer. That integration gives decision-makers one accountable vendor and a familiar path from basic use to wider management, even when another product could perform an individual task just as well.

The real reason schools stay with Microsoft

The people who approve school technology are also punished more visibly for disruption than for dependency. A failed migration produces immediate complaints: files look wrong, a projector does not connect, a specialist application will not launch, or teachers cannot find a command during a lesson. Remaining with the incumbent produces quieter costs spread across future budgets, lost bargaining power and harder exits. Risk is therefore measured asymmetrically. The administrator sees the possible chaos of changing this year, while vendor lock-in appears as an abstract problem for a later leadership team. OECD work on digital education describes procurement as a force that shapes the entire technology ecosystem, not a narrow purchase. It also notes that procurement guidance often seeks security, data protection and interoperability, which means schools are balancing institutional duties rather than comparing two price tags.

Microsoft’s strongest advantage is not that every component is superior. It is that the bundle reduces the number of separate decisions. A school using Microsoft identity can provision accounts, assign licences, connect Teams classes, store files in OneDrive and apply policies through related management tools. Replacing the desktop alone may leave the rest of that structure untouched, so Linux arrives as an extra platform rather than a substitute. A partial alternative can initially increase complexity. Staff must support two sets of instructions, two compatibility paths and two troubleshooting trees. The open-source option may be technically sound yet organizationally awkward because the institution has not redesigned the surrounding workflow. This explains why open-source software often appears first in servers, web systems, coding environments or narrowly managed labs, where tasks are controlled and integration boundaries are clearer.

The question also contains an assumption that deserves correction: schools do use open source, often without calling it that. Learning platforms, web servers, programming languages, browsers, content-management systems and network tools may all contain or be built on open-source components. Moodle explicitly describes its learning platform as downloadable and customizable open-source software, while UNESCO treats free and open-source software as a foundational layer for open educational resources, open access and open data. The real divide is usually the managed staff-and-student desktop, not the whole school stack. On that desktop, habit, support contracts and compatibility carry more weight than philosophical preference. The persistence of Microsoft is therefore less a mystery than the predictable result of incentives that reward continuity, concentrate responsibility and hide long-term exit costs.

The bias toward continuity is reinforced by accountability structures. School leaders can point to a contract, a reseller and a recognizable product when auditors, parents or regulators ask who is responsible. With a community edition assembled locally, responsibility may be technically clear to specialists but politically diffuse. Procurement often buys a chain of accountability as much as software. Commercial open-source support can provide the same chain, yet it must be specified, funded and understood before deployment. Where local procurement capacity is weak, the packaged incumbent looks safer because the support model is already legible.

This does not make the incumbent choice irrational or permanent. It means any credible alternative must solve the institutional problem, not merely demonstrate that Linux boots and LibreOffice edits documents. A school needs ownership of identity, support, training, accessibility, data retention and emergency recovery. Open source wins when it arrives as a maintained service, with named people, tested procedures and budgeted lifecycle work. It loses when advocates present freedom as a substitute for operations.

A useful decision test asks whether the school could switch suppliers without losing access to records, identity data or core teaching routines. If the answer is no, the product may still be right, but the dependency must be recorded. Continuity should be chosen consciously, not inherited silently.

Price is only the visible part of the bill

“Linux is free” and “Microsoft is expensive” are both incomplete statements. A licence can cost nothing while the deployment consumes months of staff time, and a proprietary licence can be heavily discounted while creating future renewal and exit costs. Schools buy an operating capability, not a download. The full bill includes device preparation, account integration, software packaging, classroom images, printer and projector testing, accessibility checks, staff training, help-desk coverage, data migration, document conversion, backup, cybersecurity monitoring and support during examinations. Open-source software removes or reduces some licence charges, but it does not remove these operating tasks. The Document Foundation itself advises schools and large organizations to use enterprise versions and certified partners when they need service-level agreements, migration help and long-term support. That is a responsible warning against treating community software as a costless institutional service.

Microsoft’s price also depends on who is paying. The company donates Office 365 A1, including web tools, to eligible institutions, while paid education plans add desktop applications, security and device management. Some governments negotiate centralized agreements that make products appear free at school level because the ministry funds them. New Zealand’s Ministry of Education, for example, describes a national agreement under which eligible schools access Windows, Office 365, management and security products without a direct school charge during the agreement period. In Slovakia, the Technical University in Zvolen stated in 2025 that students received Microsoft 365 Education under an agreement involving the education ministry. A zero line item in a school budget does not mean zero public cost, but it powerfully changes the local decision: a headteacher compares a ministry-funded incumbent with an alternative that requires local planning and support.

Total cost of ownership also changes over time. During the first year, migration and training may make open source look expensive. During later years, reduced licence exposure, longer hardware use and stronger bargaining power may improve the calculation. The opposite can happen if the school cannot recruit Linux skills, relies on costly consultants, or keeps Microsoft subscriptions for a minority of users while adding a second platform. Dual running is often the most expensive phase, yet it may be necessary to control risk. A fair comparison therefore needs at least a five-year horizon, separate capital and operating costs, assign monetary value to staff time, and include the cost of leaving each option. The European Commission’s open-source policy explicitly calls for equal assessment based on total cost of ownership, including exit costs, rather than licence price alone.

The hardest costs to price are disruption and dependence. A teacher who spends ten extra minutes fixing formatting across several classes creates a real labor cost even if no invoice appears. A school that cannot export data cleanly may face a large future conversion project, but the cost remains invisible until it tries to leave. Vendor-specific skills can also narrow the curriculum, while an unsupported open-source rollout can erode trust in technology generally. The honest answer is not that one model is always cheaper. Microsoft often wins because its current costs are known, budgeted and shared across the system; open source asks the institution to fund change now in exchange for possible savings and control later. Good governance makes those time horizons visible before anyone declares a winner.

Hardware complicates the bill further. A supported Linux distribution may keep an older computer useful for web access, writing and coding after that device falls outside a proprietary operating system’s supported path. Windows 10 reached end of support on 14 October 2025, and Microsoft directs organizations toward Windows 11, extended security updates or replacement. Windows 11 requires features including UEFI, Secure Boot and TPM 2.0, which can exclude some otherwise serviceable machines. Extending hardware life can be a major open-source saving, especially in large fleets, but only after schools verify battery health, storage, wireless adapters and classroom performance.

Environmental and procurement accounting should capture that effect without exaggeration. Reusing devices avoids immediate purchases, yet an old computer with failing batteries or poor energy performance may still be a bad classroom asset. The correct comparison measures usable service, repairability and support life, not age alone. A cheap computer that wastes lesson time is expensive. The bill should include device failure rates, spare capacity, technician visits and the educational cost of slow startup or unstable video.

The final model should show best, expected and worst cases. Support demand, conversion effort and hardware survival are uncertain, so a single headline total creates false confidence. Scenario ranges expose where the decision is fragile and which pilot measurements would reduce uncertainty before a large commitment.

Education discounts reshape the comparison

Microsoft has spent decades making education a strategic market, and education pricing changes the apparent economics of platform choice. The current plan structure offers a donated web-based A1 tier to eligible institutions, while A3 and A5 add desktop applications, management, analytics, communications and more advanced security. The entry price is deliberately lower than the commercial impression of Microsoft 365. For a school that needs email, browser-based office tools, videoconferencing and shared storage, A1 may cover much of the daily requirement without a licence invoice. For a school already using Microsoft identities and file formats, the marginal cost of staying can therefore be smaller than advocates of a fresh Linux installation expect.

Discounting also creates a funnel. Teachers and students become familiar with Word, Excel, PowerPoint, Teams and OneDrive; school templates are built around them; administrators learn the related controls; and families expect files to open in the same environment at home. Paid features later solve problems created inside the same ecosystem, such as installing desktop applications, applying device policies or adding advanced compliance tools. A cheap first layer can make later layers feel compulsory. This is not unique to Microsoft, and it is not proof of misconduct. It is a standard platform strategy: reduce adoption friction, build network effects and sell higher-value capabilities once the institution depends on the platform. The practical consequence is that open-source competitors are not merely challenging a word processor. They are challenging a subsidized bundle plus the habits and integrations accumulated around it.

Central agreements strengthen the funnel because the person using software is separated from the person paying for it. When a ministry or regional authority purchases licences in bulk, local schools receive a standardized entitlement and a ready support route. The New Zealand agreement renewed for 2025–2027 illustrates the mechanism: participating schools can access a defined set of Microsoft software under ministry funding, and the ministry encourages use of free A1 licences where possible to control costs. Central purchasing lowers transaction costs and narrows local choice at the same time. It can improve security and consistency, yet it also makes an alternative school responsible for building its own business case, finding support and proving compatibility against a nationally normalized environment.

Education discounts should therefore be evaluated as public policy, not accepted as gifts without conditions. Authorities should ask what happens when pricing changes, which data and documents can be exported, whether accounts can federate with other services, and how much it would cost to operate a mixed environment. They should distinguish a free web application from the paid desktop, security and management layers described in Microsoft’s service documentation. The decisive metric is the cost of autonomy over time. A discounted platform may still be the rational choice, especially where staff capacity is thin, but the contract should preserve open formats, data portability and a credible exit. Without those safeguards, today’s discount can purchase tomorrow’s dependency; with them, a school can use Microsoft where it works while keeping competition alive.

The competitive response should not be to demand that open-source projects imitate the same subsidy. Governments can purchase shared support, package a school-ready distribution, fund localization, maintain repositories and train regional technicians. Vitalinux in Aragon shows the institutional form: a purpose-built Linux distribution, central management and political backing, rather than a request that each school assemble its own desktop. Its published case study reported thousands of centrally managed PCs across participating schools with a very small education-department team at that time. Scale becomes possible when the public sector funds the common layer. The lesson is not that every region can copy those historical numbers; it is that coordination converts free code into an operable service.

Discounts also deserve periodic competition tests. A ministry should compare renewal pricing, support quality, security obligations, data-export performance and the cost of running credible alternatives. It should publish assumptions rather than presenting the incumbent entitlement as natural infrastructure. Education pricing is a policy lever with long consequences. Used carefully, it can broaden access; used without an exit design, it can narrow the market that future schools inherit.

The fairest market is not one where every product has the same sticker price. It is one where public buyers account for subsidies, switching costs and interoperability in the same evaluation. Transparent costing prevents a temporary discount from being mistaken for permanent affordability.

A review at every renewal should test those assumptions against actual usage and current alternatives.

Existing files and workflows create lock-in

A school’s archive is not a neutral pile of documents. It contains Word templates with macros, Excel sheets with formulas, PowerPoint lessons with embedded media, mail archives, shared calendars, forms, scripts, naming conventions and permissions. Every accumulated workflow is a small switching cost. A simple text document may open perfectly in LibreOffice, but a heavily formatted worksheet, a mail merge connected to a database or a presentation using proprietary fonts can behave differently. The problem is not that open-source software cannot read common formats; it often can. The problem is that schools need predictable fidelity across thousands of files created by many people over many years, including files whose authors have left and whose hidden dependencies were never documented.

Lock-in becomes stronger when documents trigger actions. A spreadsheet may feed a finance process, a Word template may create official letters, or a PowerPoint file may be the only version of a lesson that includes narration and animations. If a migration changes pagination, formulas, macros or media playback, staff must inspect and repair the result. Compatibility is a workload, not a checkbox. The institution may have no inventory of which files matter, so it must either test broadly or discover failures during live use. This is why changing the default document format can be more consequential than installing a new operating system. OASIS defines the OpenDocument Format as an application-independent and platform-independent format, while OECD guidance links open standards to lower interoperability barriers. Open formats reduce future dependence, but existing proprietary archives still require a managed conversion plan.

Workflows also extend outside the school. Parents send attachments from home, local authorities distribute forms, examination bodies specify submission formats, publishers provide lesson materials, and partner institutions expect particular file behavior. A school that adopts Linux but continues exchanging complex Microsoft files may spend more time testing compatibility than one that changes both its software and its communication rules. The ecosystem can veto a technically successful migration. That veto is rarely formal. It appears as hundreds of small exceptions: “this form must remain in Excel,” “this textbook resource only runs on Windows,” or “this meeting requires Teams.” Each exception preserves a piece of the incumbent environment until the alternative becomes an extra layer rather than a replacement.

The remedy is not a forced mass conversion. Schools need an archive policy that classifies files by legal value, operational importance, complexity and frequency of use. Read-only records can often be preserved as PDF or another stable archival form; active templates need testing and redesign; disposable duplicates should not be migrated at all. New documents should use open, documented formats whenever external requirements permit. Lock-in weakens when the school controls its information model. That means separating content from application-specific automation, documenting critical macros, insisting on export functions and testing round trips between products. The immediate goal is not to eliminate Microsoft files. It is to stop creating new dependencies unknowingly and make the cost of future change measurable rather than mysterious.

Identity and permissions create another layer of dependence. A file stored in a cloud drive is tied to account lifecycle, sharing rules, retention settings and collaboration history. Exporting the document may not preserve comments, version history, links, approvals or fine-grained permissions. Data portability is broader than file download. OECD defines interoperability across technical, semantic, organizational and legal dimensions, a useful warning that an exported folder is not the same as a functioning replacement system. A school must know which relationships and metadata are required, then test whether they survive migration.

The archive can be made less fragile through routine discipline. Schools should publish approved formats, maintain a font set that works across platforms, avoid unnecessary macros, store source media separately from presentations and require owners for critical templates. They should also run annual export tests from cloud services. An exit plan is a recurring operational test, not a document in a drawer. When export fails, the school can fix the problem while it still has time and bargaining power.

Open formats cannot guarantee perfect rendering, and proprietary formats are not automatically unusable. The policy value lies in documented implementation rights and multiple independent tools. A format with several viable readers gives the school more recovery options when one supplier changes terms or ends support.

That resilience steadily compounds across public records that must remain reliably readable after current applications, contracts and staff members are gone.

Teacher time dominates migration economics

Teachers are not spare implementation capacity. Their schedules already combine classroom instruction, planning, assessment, communication, safeguarding and administration. A software change that looks minor to an IT team can alter dozens of repeated actions: opening a register, annotating a worksheet, presenting slides, sharing homework, recording marks or responding to parents. Minutes multiplied across a staff body become the largest migration cost. If a new office suite changes shortcuts, menu locations or formatting behavior, the school pays through slower work, duplicated checking and frustration. These costs rarely appear in the procurement document because they are distributed across salaries rather than invoiced by a supplier.

Training alone does not solve the problem. A two-hour workshop can introduce LibreOffice or a Linux desktop, but competence develops while staff perform real tasks under time pressure. Teachers need role-specific guidance built around their own templates and classroom routines, not a generic tour of menus. They also need rapid support during the first term, when confidence is fragile. A migration fails socially before it fails technically when staff conclude that leaders have transferred project risk onto them. OECD analysis of interoperability notes that manual or semi-automated work consumes staff time and can make data tasks feel tedious and alienating, especially for teachers. The same principle applies to platform migration: every broken integration converts institutional design debt into individual labor.

Microsoft’s familiarity lowers that labor cost. Even staff who have never used school-managed Microsoft 365 may recognize the basic interface from previous jobs or home use. Colleagues can answer questions informally, online instructions are abundant, and new hires often arrive with relevant habits. Open-source tools also have documentation and communities, but the local concentration of knowledge may be thinner. Informal peer support is an economic asset. It shortens help-desk queues and lets teachers recover during a lesson without escalating a ticket. A school choosing Linux must deliberately recreate that support network through trained champions, clear escalation routes, tested quick guides and protected time for practice.

The strongest migration plans therefore treat teacher time as a budget line. They fund release periods for template conversion, pilot with volunteers from different subjects, measure task completion rather than attendance at training, and postpone nonessential changes during exam or reporting seasons. They keep a small set of legacy workstations for tasks that cannot move immediately. No platform saves money if it makes teaching less reliable. Open source may repay the initial effort through control, flexibility and reduced licence exposure, but only when the institution invests in people as seriously as it invests in devices. Microsoft often remains because schools can see the disruption cost of leaving more clearly than the long-term cost of staying.

Change fatigue matters as much as training design. Schools may be introducing a new curriculum, student-information system, safeguarding process or device fleet at the same time. Adding a desktop migration can overload the same people even when each project is sensible by itself. The calendar is part of the technical architecture. Leaders should map reporting periods, examinations, admissions and staff turnover before choosing a rollout date. A summer installation may look convenient, but returning staff still need working routines on the first day of term.

Feedback must also distinguish discomfort from failure. Some complaints reflect temporary unfamiliarity; others reveal inaccessible controls, missing functionality or broken workflows. Treating every objection as resistance alienates staff, while treating every objection as proof that migration is impossible preserves lock-in. Measure real tasks and error rates. Time how long representative users take to prepare a lesson, complete a report, collaborate on a document and recover a previous version before and after the change. Evidence turns a cultural argument into a manageable design process.

Teacher representatives should sit on the migration board with authority to delay a step that threatens instruction. Their role is not ceremonial consultation after the technical choice. Operational consent improves the design because classroom staff see edge cases that procurement teams and technicians miss.

Support metrics should be visible during the pilot. Count tickets by task, subject, device type and user group; record resolution time; and identify repeat failures that training cannot fix. A flood of identical questions may indicate poor interface design or weak guidance rather than user reluctance. The support desk is a research instrument during migration. Its evidence should change packaging, defaults and rollout order. When leaders close that feedback loop, staff see that reporting problems improves the system instead of merely documenting frustration.

IT staffing shapes the platform choice

A school with two hundred devices and one overstretched technician does not choose software the way a well-funded university or ministry does. The technician may manage accounts, Wi-Fi, printers, projectors, filtering, backups, cybersecurity, repairs, purchasing and classroom emergencies at once. The scarce resource is operational attention. Microsoft’s integrated education stack is attractive because identity, collaboration, storage and device controls can be learned as one vendor environment and purchased through established partners. Even when individual components are complex, the school can escalate problems through a recognized support channel. A Linux deployment assembled from separate projects may be more transparent, but the local team must decide which distribution, lifecycle, management system, repository, authentication method and support provider it will own.

Open source does not require amateur administration. Canonical offers long-term support releases, extended security coverage and commercial phone and ticket support; The Document Foundation recommends enterprise-backed LibreOffice for large organizations; and many vendors support Linux fleets. The support market exists, but schools must procure it deliberately. In regions where public frameworks list many Microsoft resellers but few Linux specialists, the proprietary route is easier to buy. Procurement officers can compare familiar offers and contract terms, while an open-source service may require a custom specification. The technical capability may be available nationally yet absent within reasonable travel distance or response time for a small school.

Staffing risk also affects recruitment and continuity. A Microsoft administrator can often be replaced from a broad labor market, and many managed-service providers advertise the same product set. A school whose Linux environment depends on one enthusiastic teacher or technician has a key-person risk, even if that person built an excellent system. A platform is not durable when its knowledge lives in one head. Documentation, configuration management, automated deployment and shared credentials matter more than the logo on the desktop. Open-source advocates sometimes underestimate this institutional requirement because reproducible code feels self-documenting. In practice, local choices, exceptions and integrations must still be recorded so another team can recover the service.

The incumbent environment benefits from accumulated vendor training, certifications, templates and peer networks. Staff can search a precise error message and usually find documentation or forum discussions written for the same interface. Linux communities also provide deep knowledge, but answers may span distributions, desktop environments and package versions. That diversity is a strength for innovation and a burden for a small support desk. Standardization turns community knowledge into school capacity. A regional authority can select one supported distribution, publish a baseline image, maintain approved packages and provide a shared help desk. Without that common layer, each school repeats design work and carries avoidable variation.

The Aragon Vitalinux case illustrates the role of central engineering. The project did not merely tell schools to download Linux; it offered a purpose-built distribution, central inventory and remote management, with education-department staff maintaining participating systems. The historical case reported more than six thousand PCs across forty schools at the time of publication. Those figures should not be treated as a universal staffing formula, but they show that centralization can make open source easier to operate than fragmented proprietary estates when hardware and software are standardized.

A sensible staffing test precedes any platform decision. Leaders should list recurring tasks, required response times, specialist applications, security duties and the people who can perform each function. They should model absence, turnover and vendor failure. A Linux pilot is credible only if support survives the departure of its champion; a Microsoft deployment is credible only if the school understands rather than blindly outsources its configuration. The choice should reduce single points of human failure. Schools stay with Microsoft partly because the support labor market is already organized around it. Public policy can change that outcome only by funding shared open-source operations, training and procurement frameworks, not by asking individual schools to become software integrators.

Budget structures can worsen the staffing imbalance. Capital grants may pay for devices while recurring technical salaries, training and support contracts must come from constrained operating budgets. A school can therefore afford a new fleet but not the people needed to redesign its platform. Funding rules quietly favor packaged services over institutional capability. A regional open-source program should protect recurrent money for maintenance, security and user support, not spend everything on the initial image. It should also create progression routes for technicians so trained staff do not leave immediately for better-paid roles.

The internal team needs knowledge to govern an outsourced service. Technical sovereignty begins with informed ownership, even when operations are contracted.

Central management favors integrated suites

Classroom computers are not ordinary personal devices. They must be reset, patched, filtered, inventoried and configured for changing groups of users, often without technicians visiting each room. Administrators need to push applications, restrict settings, enforce encryption, rotate credentials, remove departing accounts and recover lost devices. Management capability often decides the operating system before teachers see the desktop. Microsoft sells education plans that connect office applications with identity, security and device administration, and its service descriptions separate web access from richer paid management and compliance functions. Schools may dislike subscription costs yet still prefer a bundle whose components share policies and support boundaries.

Linux can be managed centrally through established tools, directory integration, configuration systems and image deployment. The barrier is not absence of technology. It is the amount of design required to assemble a coherent service and the scarcity of school-specific packages, documentation and providers. Integration work moves from the vendor to the institution or its contractor. A large authority may welcome that control because it can select components, inspect configurations and avoid dependence on one supplier. A small school may experience the same freedom as an obligation to make architectural choices it is not staffed to evaluate.

Integrated suites also simplify the user lifecycle. When a student enrolls, one identity can activate email, storage, class membership and application access; when the student leaves, disabling the account can close several services. In a mixed environment, the same result is possible through open identity standards and automated provisioning, but connectors must be configured and monitored. Failed synchronization creates subtle risks: former users retain access, class groups lag behind enrollment changes, or permissions diverge between systems. Identity errors are operational and privacy failures, not minor inconvenience. The perceived safety of a single stack comes from fewer integration seams, even though concentration creates its own systemic risk.

Vendor dashboards further shape management expectations. School leaders want compliance reports, device health, threat alerts and simple proof that policies were applied. A polished console translates technical state into something an auditor or principal can review. Open-source tools may provide equal or deeper information, but they can require several interfaces and more interpretation. Visibility must be designed for governance, not only technicians. An open-source school platform needs clear reports, delegated roles, audit trails and documented evidence collection. Without those layers, technically capable systems lose procurement contests because decision-makers cannot see or explain their control environment.

Cloud management changes the cost structure. It reduces local server work and supports remote devices, which became especially attractive when learning moved between school and home. It also makes connectivity, subscription terms and provider availability part of daily classroom operations. A local Linux environment can preserve more offline capability, yet remote collaboration and management still require services somewhere. The real comparison is centralized vendor cloud versus consciously designed service architecture, not cloud versus no cloud. Schools must decide which functions need local continuity, which can tolerate internet failure and which data should remain under their direct control.

The strongest open-source proposals therefore arrive as platforms with lifecycle ownership. They specify supported distributions, management tools, identity integration, update rings, recovery procedures, monitoring and service-level commitments. They also limit variation: teachers may install approved applications through a curated catalog rather than arbitrary packages. Freedom at the institutional level can require constraint at the device level. Microsoft remains common because it packages that constraint into a recognizable product and partner market. Open source becomes competitive when a ministry, region or qualified provider performs the same integration work and gives schools a service they can operate, audit and explain.

Suite integration can conceal concentration risk. A single identity or policy error may affect email, files, meetings and devices at once, while a provider outage can remove several classroom functions simultaneously. Separate services create more seams but can also create fault boundaries. Convenience and resilience are not the same property. Architecture should include offline teaching procedures, local administrator access, tested backups and alternative communication routes. The school should know which services remain usable when the cloud account, internet link or identity provider fails.

Open-source architecture can deliberately separate components, yet careless fragmentation produces the worst of both worlds. The goal is replaceable modules connected through documented standards, not a random collection of tools. Modularity needs governance. Each component requires an owner, lifecycle, data contract and recovery objective. When those are present, integration no longer belongs exclusively to one vendor and the school gains room to change parts without rebuilding everything.

Procurement scorecards rarely reward openness

School procurement documents often ask whether a product supports required features, meets security controls, integrates with current systems and can be supplied within budget. Those questions sound neutral, but the current environment defines the requirement. A tender that demands native compatibility with existing Microsoft macros, management tools and account structures may exclude alternatives before price is compared. Incumbent-specific requirements can masquerade as operational necessity. Some are genuinely necessary during a transition; others simply preserve past choices. The procurement team needs to separate outcomes—such as collaborative editing or device encryption—from brand-specific implementation details.

OECD analysis treats procurement as a way governments shape digital education ecosystems. It reports that jurisdictions use centralized purchasing, guidance and support to influence what schools buy, with goals including security, data protection and interoperability. The same machinery can either widen competition or freeze the market. A framework agreement is a technical policy even when written as purchasing administration. If it lists only familiar proprietary products, schools receive speed and consistency but lose an easy route to alternatives. If it includes supported open-source services and migration assistance, local leaders can test another model without inventing a procurement process from scratch.

A better evaluation grid

The table shifts evaluation from claims to testable evidence. It also prevents “open source” or a famous brand from receiving automatic credit without operational proof.

Tender scoring commonly undervalues exit because departure lies beyond the contract period. A supplier can score well on deployment and support while leaving data export, format conversion and identity separation undefined. The European Commission’s open-source policy explicitly says proprietary and open-source options should be assessed on total ownership cost, including exit costs. An exit clause has value only when tested. Schools should require sample exports, documented schemas, deletion procedures, transition assistance and price limits for extraction work before signing.

Procurement also favors bidders that can assume liability, provide insurance and meet formal service conditions. Community projects are not legal entities offering warranties, so the buyer needs a company, consortium or public service wrapper. This is not unfair by itself; schools handle children’s data and cannot rely on goodwill for critical recovery. Open code still needs a contractual operator. Policy should build a market of operators rather than lowering accountability. Shared contracts can aggregate demand, make support economically viable and require contributions upstream so public fixes do not remain private forks.

Technical trials should carry material score weight. Vendors can answer questionnaires generously, while real users expose formatting, accessibility, offline and integration failures. A procurement pilot should use anonymized copies of representative documents, devices and workflows; include teachers, administrators and students with access needs; and record support effort. Evidence from the school’s own workload is stronger than feature matrices. It also creates a defensible record if the cheaper sticker price loses because transition cost is genuinely too high.

A neutral scorecard does not guarantee Linux will win. It may show that Microsoft is currently the lower-risk choice for staff desktops while Linux is stronger for labs, kiosks or older devices. The policy gain is transparency: dependencies become priced, standards become requirements and future competition remains possible. Procurement should buy capability and reversibility together. When openness, portability and exit are scored as operational outcomes, schools can use proprietary products without surrendering choice and can adopt open source without pretending that licences are the only cost.

Specifications should also prevent contract bundling from suppressing comparison. A supplier may package licences, migration, training, security and hardware so tightly that evaluators cannot see the price or quality of each element. Lots or modular pricing allow specialist firms to bid for support, integration or open-source components. Unbundling creates competition only when interfaces are clear. Otherwise the school becomes responsible for disputes between suppliers. Contracts need a lead integrator, shared incident rules and obligations to cooperate.

Market engagement before tender can expose impossible requirements. Schools can publish outcomes, invite demonstrations and ask both proprietary and open-source providers how they would meet them without promising a brand. That process must follow applicable procurement law and preserve equal treatment. Early technical dialogue is most useful when it changes the requirement, not when it merely confirms the incumbent design. It can reveal available support partners, realistic migration periods and standards the buyer did not know to request.

The evaluation record should remain available after award. Publishing the criteria, assumptions and scored evidence lets auditors, parents and future procurement teams understand why a platform won. It also gives unsuccessful suppliers a precise signal about missing support, accessibility or interoperability. Transparent evaluation turns one purchase into market intelligence for the next renewal.

Hardware compatibility is less simple than it looks

Linux is often proposed as a way to keep older school computers in service, and that claim has a sound technical basis in many ordinary workloads. A supported distribution can run on hardware that does not meet the requirements of a newer proprietary operating system. Windows 10 reached end of support on 14 October 2025, while Windows 11 requires, among other features, UEFI, Secure Boot and TPM 2.0. A platform change can postpone hardware replacement for part of a fleet. The saving may be substantial when devices still have adequate processors, memory, storage and batteries for web work, documents and coding.

Yet “Linux runs on old hardware” is not a deployment plan. Schools need reliable Wi-Fi, audio, webcams, graphics, suspend and resume, touch input, interactive displays, printers, scanners and specialist peripherals. A device that boots but loses sound after sleep is not classroom-ready. Driver support also varies by model, firmware and kernel version. Compatibility must be tested on exact hardware, not inferred from a brand name. A pilot should include every major device family and peripheral, then record cold boot, login, video conferencing, projection, printing, battery use and recovery from updates.

New equipment can create the opposite problem. Manufacturers may certify their management utilities, firmware tools or docking stations only for Windows. Educational robotics kits, science probes and assistive hardware may ship with proprietary configuration software. Linux support can be excellent for standard components and weak for a single device that a department depends on. One unsupported peripheral can preserve an entire Windows island. The rational response is not to abandon Linux across the school, but to classify rooms and workflows so specialist stations remain where needed while general-purpose devices use a different platform.

Windows compatibility also carries hardware costs of its own. Unsupported systems require replacement, paid extended security arrangements or a different operating system. Microsoft’s guidance directs organizations with incompatible Windows 10 devices toward Windows 11-capable hardware or other support options. A Linux migration may therefore turn an imposed refresh into a selective refresh. The economic value lies in avoiding premature replacement, not keeping every machine forever. Schools should retire devices with failing storage, weak batteries, poor displays or unacceptable energy use even when Linux can technically run them.

Imaging and repair practices matter. A standardized Linux image can reduce drift and make restoration fast, while package repositories can provide a controlled software catalog. Windows environments offer mature deployment and management paths too. The decisive question is how quickly a technician can return a damaged device to known state and whether spare parts remain available. Fleet uniformity often saves more support time than operating-system licence differences. A mixed collection of donated laptops may look cheap but consume hours through unique chargers, firmware quirks and batteries.

Environmental claims need the same discipline. Extending useful life reduces demand for new manufacturing and delays disposal, but the school should not claim a precise carbon saving without a lifecycle assessment that matches its devices and energy mix. It can state the verified operational fact: fewer machines were purchased because existing ones remained serviceable. Repair, reuse and selective replacement form a stronger policy than indefinite retention. Linux can be central to that policy, especially after proprietary support deadlines, but success depends on inventory, testing and maintenance rather than the operating system’s reputation alone.

A hardware inventory should capture more than model and serial number. Record processor generation, firmware mode, TPM state, memory, storage health, battery condition, network chipset, display outputs and attached classroom equipment. Then map each device to a task profile. Compatibility becomes manageable when the fleet is described as evidence. The school may discover that a large middle group can run either platform, a small group needs replacement regardless, and a specialist group must retain Windows.

Procurement can improve the next cycle by requiring Linux certification or at least documented driver support for selected models. Framework buyers have more influence than individual schools because volume justifies vendor testing. Hardware neutrality must be purchased in advance. Waiting until migration to ask whether a proprietary docking station or interactive panel supports Linux leaves the school with little influence and an expensive installed base.

A repair policy completes the hardware plan. Schools need approved replacement parts, secure data wiping, battery rules and a threshold for retiring unreliable devices. Reuse saves money only while classroom availability remains acceptable. Tracking failures by model shows whether Linux is extending useful life or merely moving replacement cost into technician hours and lesson disruption.

Specialist applications keep Windows in the building

General classroom tasks—browsing, writing, presentations, spreadsheets and coding—have credible open-source options. The harder barrier appears in vocational subjects, design, media, engineering, science and assessment, where a specific application may define the course. Adobe’s current Creative Cloud requirements focus desktop support on Windows and macOS, and Autodesk states that AutoCAD and its vertical products are officially supported on Windows and macOS rather than Linux. A school cannot replace an operating system while ignoring the software that gives a lab its purpose. Web alternatives and open-source tools may cover some learning goals, but curriculum, teacher expertise and external certification can make product substitution a separate educational decision.

The distinction between teaching a concept and teaching a product matters. Image composition, vector graphics, three-dimensional modeling and computer-aided design are transferable concepts. A course can teach them with GIMP, Inkscape, Blender, FreeCAD or browser tools. Yet employers, examination boards or partner institutions may expect familiarity with a named commercial package. Curriculum reform cannot be hidden inside an IT migration. Subject leaders must decide whether an open alternative meets learning outcomes, whether assessment accepts its files, and whether students lose or gain opportunity by switching.

Virtualization, remote desktops and dual boot can preserve specialist applications while moving general work to Linux. Each method adds cost and complexity. Virtual machines need sufficient hardware and licensing; remote applications depend on servers and network performance; dual boot complicates patching and support. Wine or other compatibility layers may run some Windows programs, but an unsupported configuration is risky for examinations or production coursework. Compatibility workarounds are useful bridges, not automatic long-term platforms. The school should define which failures it can tolerate and retain vendor-supported paths for high-stakes tasks.

Specialist hardware creates related dependencies. Music interfaces, embroidery machines, CNC equipment, data loggers, microscopes and accessibility devices may rely on Windows-only drivers or configuration utilities. Even when the main application has a Linux version, the full workflow may not. Procurement must test the device, driver, file exchange and support agreement together. The smallest proprietary component can control the largest room. Future purchases should therefore score cross-platform support, documented protocols and export formats so each new device does not deepen the lock.

A mixed estate is often the right answer. Libraries, general classrooms and coding labs may use Linux; administration and specialist suites may remain on Windows; cloud services may span both. This arrangement avoids ideological purity but requires clear boundaries, common identity and support ownership. Role-based computing is more realistic than one operating system for everyone. It also creates an evidence base: the school learns which tasks move easily, where compatibility costs persist and whether the Windows footprint can shrink at each renewal.

Over time, application markets change. Browser-based tools may reduce desktop dependence, open-source projects mature, and suppliers may add platform support. Schools should review exceptions rather than granting them permanent status. They can ask vendors for Linux clients, open APIs, standard formats and browser access, especially in collective procurements. Demand shapes the support market. Microsoft remains because many critical applications assume Windows; open source expands when buyers stop treating that assumption as invisible and make cross-platform operation a scored requirement.

Licensing can block apparently clever technical solutions. A Windows application may permit installation on physical school devices but restrict shared servers, remote access or virtualization. Cloud versions may have different feature sets or storage rules. Technical feasibility does not establish contractual permission. The school must review licence terms and support conditions before building a remote-app bridge, and it should document whether students can use the service from home or personal devices.

Open alternatives deserve the same educational scrutiny. A program may be free and powerful but lack accessible documentation, local-language materials or predictable file exchange with assessment partners. Teachers need time to rebuild examples and marking guides. Application choice belongs to subject governance. IT can test deployment and security; curriculum leaders must judge whether the tool teaches the intended knowledge and whether its workflow is fair to students.

Schools can also separate authoring from viewing. A specialist Windows workstation may create a complex model while ordinary classroom devices open exported results through a browser or standard format. That design narrows licence and hardware needs without pretending every application has a Linux equivalent. It works only when exports preserve the educational content students must inspect and assess.

The result is a portfolio, not a purity test. Compatibility evidence should decide which specialist stations remain proprietary and which general tasks can move.

Exams and administrative systems dictate compatibility

A school can tolerate a minor formatting problem in an optional worksheet; it cannot tolerate failure during an examination, payroll run, statutory return or admissions deadline. High-stakes systems therefore carry disproportionate influence over desktop choice. The least flexible workflow often sets the standard for everyone. If an exam client, government portal, finance package or student-information tool is certified only for Windows and a particular browser, leaders may standardize the whole estate rather than maintain a separate, tightly controlled group of machines. The choice looks conservative because the cost of failure is immediate and public.

Compatibility claims need careful reading. A web service that works in Chrome may appear operating-system neutral, yet authentication middleware, document-signing tools, printing components or secure exam browsers can reintroduce platform requirements. The public page may omit the exact client configuration supported by the supplier’s help desk. Browser-based does not automatically mean platform-independent. Schools must test the complete transaction: login, identity verification, file upload, digital signature, printing, accessibility tools and recovery after interruption. They also need written confirmation that the vendor will support the chosen setup during high-stakes periods.

Administrative templates preserve Microsoft dependence in quieter ways. Ministries, municipalities and partner agencies may distribute spreadsheets with macros, protected cells or complex validation. A school can open them in another suite but cannot safely assume every formula and control behaves identically. Staff then keep one Windows machine “just in case,” and that exception expands because it is easier than redesigning the exchange. External authorities can create lock-in downstream without buying school desktops. Open standards policies must therefore cover the documents and portals public bodies require schools to use, not only the software schools procure themselves.

Assessment fairness adds another constraint. Students should not be disadvantaged because the school’s platform renders an exam differently, lacks an assistive feature or behaves unlike the environment specified by the awarding body. A Linux deployment can satisfy high-stakes assessment where the platform is supported and tested, but unsupported workarounds are unacceptable. Reliability must be demonstrated under exam conditions. That includes locked-down accounts, time synchronization, network loss, device replacement, printing, screen readers and incident logging. The correct standard is not whether a technician can make the software run; it is whether invigilators can operate it predictably.

Segmentation is usually cheaper than surrender. The school can maintain a small, hardened Windows pool for examinations and statutory applications while using Linux elsewhere. Those machines should have named owners, limited software, strict patching and clear booking rules. An exception should remain bounded and measurable. Annual reviews can ask whether the vendor has added browser or Linux support, whether an open alternative is accepted, and whether the pool can shrink. Without review, temporary compatibility stations become permanent proof that no migration is possible.

Public authorities hold the strongest lever. They can require suppliers of education and administration systems to support documented web standards, standard identity protocols, open exports and multiple operating systems. OECD guidance links open standards to reduced vendor lock-in and better interoperability across education systems. The desktop market follows the requirements written by system owners. Schools will keep Microsoft where external obligations demand it; those obligations can change only when ministries, examination bodies and procurement frameworks treat cross-platform access as part of service quality.

Contract timing reinforces caution. Administrative and assessment suppliers may update support lists on their own schedule, so a school cannot assume that a configuration tested this year remains certified next year. Renewal reviews should capture operating systems, browsers, middleware and end-of-support dates across every high-stakes service. A dependency register turns surprise into planned work. It should name the service owner, vendor contact, fallback procedure and successful test. Unsupported does not always mean nonfunctional, but it does mean the school may stand alone when failure occurs.

Business continuity tests should include manual alternatives. If the student-information system is unavailable, can attendance be captured securely and entered later? If exam devices fail, are spares imaged and ready? If a required portal rejects Linux, is access limited to a managed Windows jump station rather than restoring Windows everywhere? Fallback design reduces the incumbent’s power to dictate the whole estate. It also improves resilience regardless of which platform the school chooses.

Cross-platform certification should be part of acceptance testing for any system. The buyer can require browser versions, keyboard-only operation, identity integration, printing, file upload and recovery on more than one operating system. A supplier that cannot meet the requirement should document the dependency and end date, allowing the authority to price the resulting constraint.

Parents and students reinforce network effects

School technology extends into homes. Students open homework on family laptops and phones; parents join meetings, read attachments and complete forms; teachers answer messages outside the building. When most participants already have access to Microsoft formats or web services, using the same environment feels inclusive because fewer instructions are needed. Familiarity behaves like infrastructure. Each additional user makes the shared platform more convenient, which reinforces the choice even when alternatives are technically available.

The network effect is strongest around documents. A teacher sends a presentation, students edit it in different places, and the class expects layout, comments and media to survive. Open standards can support cross-product exchange, but people often default to the format their current application saves most reliably. A school that changes software while continuing to exchange proprietary files may create visible imperfections that users blame on the alternative. The social standard can outweigh the formal standard. To change it, the school must set clear default formats, provide browser access or viewers, and explain which files are meant for reading versus editing.

Account expectations matter too. A single school login for email, storage, assignments and meetings reduces friction for families. Microsoft’s education plans bundle those functions, and eligible institutions may receive web tools without a direct charge. A family does not see procurement history; it sees whether the link opens. Convenience at the edge protects the platform at the center. An open-source replacement must provide equally simple onboarding, password recovery, mobile access and notifications. Technical freedom loses public support when every service requires a separate account or a confusing URL.

Home hardware also shapes equity. Requiring a desktop application that runs only on a recent operating system can exclude students using older devices, tablets or shared computers. Browser-based tools reduce that barrier, whether proprietary or open source. Linux can extend the life of school-issued devices, but families should not be required to install an unfamiliar operating system merely to submit homework. The school must provide an access path, not assume household capacity. That may mean loan devices, web applications, offline packages or school study spaces.

Students themselves create peer effects. They share tips, templates and shortcuts, and they expect collaborative features to behave the same across classes. A fragmented teacher-by-teacher choice creates more cognitive load than a well-managed mixed platform with common rules. Consistency matters, but consistency need not mean one vendor. Schools can standardize identity, file formats, submission methods and support while allowing different applications for different subjects. The policy should describe outcomes students can rely on, not only product names.

Communication is central to any transition. Parents need advance notice, short instructions and a support route; students need practice before graded work depends on the new environment. Schools should publish files in accessible, non-editable formats when editing is not required and avoid using a proprietary attachment as the only channel for critical information. Network effects weaken when participation does not depend on ownership of one product. The goal is not to force families into Linux or LibreOffice. It is to ensure that a public education service remains reachable from diverse devices and that convenience does not quietly become exclusion.

Network effects can also spread mistakes. If everyone exchanges editable files by attachment, duplicate versions and accidental disclosure become normalized. A platform migration is an opportunity to decide when collaboration should use shared links, when records should be locked, and when public information should be published as accessible HTML or PDF. Good workflow design is more inclusive than product uniformity. Families should receive the least demanding format that serves the purpose.

The school should avoid transferring software costs to households. Requiring a paid desktop suite at home undermines the claim that a familiar format is convenient. Eligible Microsoft web access may remove that charge for some communities, while LibreOffice offers a free local option; both can be part of an access plan. Choice at home should remain real. Homework instructions should state supported formats and provide a school-controlled route for students whose devices cannot run the preferred tool.

Students also shape the network through peer support. A familiar interface lets them solve minor problems for one another, while a new platform initially routes more questions to teachers. That cost falls after practice only if the interface remains consistent and help materials exist. Student digital leaders can support a pilot, but they should supplement rather than replace accountable technical support.

Workplace familiarity influences curriculum decisions

Schools hear a persuasive argument for Microsoft: students will encounter Word, Excel, PowerPoint, Outlook and Teams in employment, so teaching those products prepares them for work. The argument contains truth but can be used too broadly. Digital competence is larger than product familiarity. Students need to structure information, analyze data, collaborate, protect accounts, understand formats, automate tasks and adapt to unfamiliar interfaces. Memorizing one ribbon layout provides immediate confidence but weak preparation for a career in which versions, employers and tools change.

Product knowledge still has value. A vocational course tied to office administration, finance or a particular employer may reasonably teach software used in that workplace. The mistake is turning that local labor-market signal into a universal operating-system requirement for every subject and age. Teaching a market-leading tool is not the same as making the whole school dependent on it. A mixed curriculum can teach Microsoft applications where occupational relevance is explicit and open-source tools where transparency, coding, customization or hardware reuse support the learning goal.

Open-source software adds a distinct educational opportunity. Students can inspect source code, study licenses, contribute translations, report bugs and learn that digital systems are constructed rather than natural. UNESCO places free and open-source software within a wider portfolio of open knowledge, and its education technology report notes that proprietary systems can create vendor locks that hinder interoperability and exchange. Software freedom can itself be curriculum content. It connects computing to civic questions about control, public infrastructure, privacy and the ability to repair or modify tools.

The labor market is also more diverse than the desktop stereotype. Web development, cloud infrastructure, cybersecurity, data science and embedded systems rely heavily on open-source tools and Linux environments. Students who only learn graphical office routines may be less prepared for technical paths than those comfortable with terminals, package managers, version control and multiple operating systems. Platform diversity builds transfer rather than confusion when taught deliberately. The curriculum should name similarities and differences: a formula is not “an Excel thing,” a file is not its application, and collaboration is not synonymous with one service.

Teacher confidence can narrow curriculum unintentionally. Staff teach the tools they know because lesson materials, examples and assessment rubrics already exist. Switching applications requires rebuilding that pedagogical content, not just installing software. Leaders should fund subject teams to map concepts to tools and create materials that survive interface changes. Curriculum independence requires reusable learning design. Screenshots and click sequences date quickly; tasks centered on concepts, standards and outcomes can move between products.

A sound policy asks two separate questions: which digital concepts should every student master, and which named products are justified by a course or partnership? It then provides exposure to more than one environment so students learn adaptation. The graduate should not be stranded when a menu moves or a subscription ends. Microsoft can remain part of that education without being the invisible definition of computing. Linux and open-source applications earn their place not because workplaces reject proprietary tools, but because modern work rewards people who understand systems beyond a single vendor’s interface.

Assessment should reward transferable competence. A spreadsheet task can evaluate formulas, references, validation and interpretation without demanding an exact sequence of Excel clicks. A document task can assess structure, styles, citations and accessible formatting across office suites. Product-neutral rubrics make learning more durable. Named-product certification may still sit alongside them where a vocational program requires it, but it should not replace the underlying concepts.

Employer partnerships can improve the evidence. Schools should ask local employers which tasks new staff actually perform, which file standards matter and how often tools change. They may discover that adaptability, data judgment and security habits matter more than a branded interface. Labor-market relevance should be tested, not repeated as folklore. Where employers genuinely require a product, the school can target that training instead of using it to justify every institutional dependency.

Teacher development should therefore include comparison, not product advocacy. Showing the same task in two suites reveals which skills transfer and which depend on a vendor. Students can learn to inspect formats, export safely and recover from compatibility failures. Those habits prepare them for workplaces that mix web services, mobile devices, proprietary applications and open infrastructure rather than one permanent desktop.

Career guidance can make this distinction explicit. Students should know employers hire for tools in roles while expecting adaptation in others. Teaching tool fluency and underlying concepts gives learners a truer account of the labor market than presenting one suite as universal.

Open source is already inside schools

The claim that schools do not use open source collapses as soon as the technology stack is examined below the desktop. Web servers, network appliances, programming languages, databases, content systems, browsers, learning platforms and cloud services often incorporate open-source components. Schools may depend on Linux without placing it on a teacher’s laptop. The distinction matters because it shows that the debate is not trust versus distrust of open source. It is about where schools feel able to operate and support it directly.

Moodle is an obvious education example. The project describes its learning management system as open source and downloadable for customization, while commercial hosting and support are available around it. That model separates the code’s license from the service used by an institution. Open source and paid service are compatible business models. A school may pay a provider for hosting, updates, backups and support while retaining greater ability to move or modify the software than it would have under a closed platform.

Browsers further blur the categories. A Windows desktop can run open-source applications; a Linux desktop can connect to proprietary cloud services. LibreOffice works on more than one operating system, and open standards can reduce dependence before an operating-system change. Migration is a sequence of layers, not a binary flip. Schools can begin by adopting cross-platform applications, standardizing formats, moving web services to documented interfaces and building staff familiarity. The desktop operating system can change later, after surrounding dependencies have weakened.

Cloud vendors also build on open-source components, although customers may interact with a closed service and have no direct control over the deployed code. Using open-source libraries inside a proprietary cloud does not give the school portability or governance rights. Component openness is not service openness. Decision-makers must ask whether they can export data, run the service elsewhere, inspect relevant code, choose another operator and preserve configurations. The label matters less than the rights and operational options attached to the actual service.

Security practice confirms the ubiquity of mixed stacks. NIST guidance says open-source components are pervasive and recommends trustworthy repositories, vulnerability identification, software composition analysis and controlled internal libraries. These controls apply because both proprietary and open products commonly contain community-developed dependencies. Buying closed software does not remove open-source supply-chain risk. It may move visibility and responsibility to the supplier, which can be useful, but the school still needs contractual evidence about patching, disclosure and component management.

Recognizing existing use changes the policy conversation. Instead of asking whether open source is acceptable in principle, schools can inventory where it already works, who supports it and which governance patterns succeed. Server teams may have automated patching and documented recovery that desktop teams can reuse. Teachers may already use open creative or coding tools. The institution has more open-source experience than its procurement labels reveal. That experience can support a measured expansion while exposing the areas—usually user support, specialist compatibility and integrated management—where new public investment is needed.

An inventory should distinguish community code, commercial open-source products, managed open-source services and proprietary services built on open components. Those categories carry different rights and support duties. A school using a hosted Moodle instance may have contractual support but limited administrative access; another may self-host and control everything while carrying more operational risk. The deployment model determines practical freedom. License alone does not reveal who patches the server, controls backups or can move the data.

Public buyers can use this inventory to direct investment. Widely shared open components may deserve pooled maintenance, security review or contributions upstream. The European Commission’s strategy links open source with sharing, reuse, skills and control, rather than treating it only as a procurement discount. Contribution is part of responsible consumption. Schools rarely contribute code directly, but ministries can fund fixes, translations, accessibility work and documentation that benefit every participating institution.

The same distinction matters for libraries and classroom devices. Firefox, Chromium, Linux kernels, web servers and programming languages may already carry lessons and portals even when the screen shows a Microsoft-branded service. Mapping these dependencies makes security ownership clearer. It also prevents leaders from treating open source as an unfamiliar external proposal when it is already embedded in daily operations.

An open-source inventory should feed risk management, not only advocacy. Unsupported plugins and abandoned libraries require removal or replacement regardless of who wrote them. Conversely, mature components with active maintainers and clear update paths should receive the same operational recognition as commercial dependencies. Naming both strengths and liabilities produces a truthful software estate.

Linux succeeds where tasks are controlled

Linux performs especially well in school settings where the device has a narrow purpose and the institution controls the software image. Computer labs, coding rooms, library terminals, kiosks, thin clients and refurbished laptop programs fit this pattern. A bounded task reduces compatibility risk. The school can choose applications that run reliably, test a limited set of peripherals and restore devices quickly when students change settings. It does not need to reproduce every historical staff workflow on day one.

Coding education is a natural fit. Linux provides direct access to common compilers, scripting languages, servers, containers and command-line tools, while package repositories simplify installation of approved development environments. Students can learn permissions, processes, networks and automation on the same family of systems widely used in servers and technical computing. The operating system becomes part of the lesson rather than an invisible launcher. A Windows machine can teach the same concepts through modern subsystems and tools, but Linux offers a coherent environment with fewer layers between student and system.

Older hardware is another controlled use case. A school can assign refurbished devices to browser-based learning, writing or programming after testing a supported Linux distribution on the exact models. The Vitalinux case in Aragon was built around reuse, central inventory and managed school desktops, reporting thousands of PCs across participating schools at the time. Reuse worked because the project combined software with central management. It was not a collection of uncoordinated personal installations.

Kiosk and thin-client models reduce local variation further. The device may launch only a browser, remote desktop or set of approved applications, with user data stored centrally. Linux can lower licence exposure and provide strong configuration control in that role. Yet the backend, identity service and network become more critical, so savings on endpoints may be exchanged for server and connectivity requirements. Control shifts rather than disappears. The school must design capacity, offline procedures and recovery for the architecture as a whole.

Success in bounded environments creates useful evidence. Technicians learn packaging and updates; teachers see that students can work productively; procurement gains real support data; and leaders can compare device life and incident rates. A pilot should not be dismissed as unrepresentative merely because it starts in a lab. A narrow pilot is supposed to control variables. Its value lies in identifying which assumptions hold before the school exposes high-stakes administration or every classroom to change.

The next step should follow task similarity, not political ambition. If Linux works in coding labs, move to general student browsing or libraries before staff finance systems. Expand only when identity, printing, accessibility and support metrics meet agreed thresholds. Keep documented exceptions for applications that remain Windows-dependent. Growth by verified use case is safer than a date-driven universal switch. Linux succeeds where schools define the service, maintain the image and align applications with the purpose; it struggles when expected to absorb every legacy dependency without redesign.

Controlled deployments also make security easier to reason about. The school can allow software only from approved repositories, lock down administrative rights and test updates against a small application set. NIST recommends acquiring open-source components through trustworthy repositories and maintaining sanctioned libraries where appropriate. Curation matters more than unlimited installation. A Linux lab that lets every user add unreviewed packages is not automatically safer than a managed Windows lab; a disciplined repository and image process are the control.

Teaching staff should define the pedagogical boundaries before technicians define the image. A library terminal needs printing and accessibility tools; a coding lab needs compilers and version control; a media lab may need graphics acceleration and specialist peripherals. Purpose determines the baseline. A clear baseline makes support faster, training shorter and performance measurements useful, giving Linux a fair trial instead of forcing one generic image onto incompatible uses.

Measurement should be modest but concrete. Record login time, application launch, printing success, update failures, support tickets and completed classroom tasks. Compare those figures with the existing Windows service rather than with an ideal. A controlled Linux deployment earns expansion when it meets the school’s service threshold consistently, not when a demonstration looks impressive on newly prepared hardware.

User feedback should be tied to tasks. “I dislike Linux” and “the projector failed after resume” are different evidence. The first signals training or familiarity; the second identifies a defect that can be reproduced and fixed. Separating preference from service failure respects users without allowing either advocates or opponents to convert every reaction into a verdict.

Desktop Linux faces a support-market gap

Desktop Linux is technically mature, but schools buy more than technical maturity. They need local-language training, device certification, classroom management, accessible help materials, rapid incident response and suppliers that understand term calendars. The missing product is often the surrounding service. A distribution can receive years of security maintenance and still be difficult for a school to procure as a complete desktop operation. Canonical publishes five years of standard security maintenance for Ubuntu long-term support releases and offers longer coverage and commercial support, demonstrating that Linux itself is not confined to volunteer help. The gap appears between enterprise support and the specific workflows of ordinary schools.

Microsoft’s partner ecosystem has a long head start. Resellers, managed-service companies, training providers and hardware vendors know how to quote familiar education packages. Job candidates list Microsoft skills, and administrators can compare certifications and references. A Linux provider may be capable but harder to find, especially outside large cities. Market depth lowers perceived risk. Buyers are not only asking whether one contractor can deploy the system; they are asking whether another contractor can take over in three years without rebuilding it.

Fragmentation contributes to the problem. Linux offers multiple distributions, desktop environments, packaging formats and management choices. That diversity lets expert users select a precise fit, but public buyers want a stable baseline. A tender for “Linux support” is too vague because suppliers may propose incompatible architectures. Choice must be narrowed into a maintained standard. A ministry or regional authority can select one or two long-term platforms, define approved hardware, publish configuration profiles and require suppliers to preserve portability rather than create private forks.

The support gap is also economic. Schools are dispersed, budgets are small and demand is irregular. A technician may travel far to solve a printer problem that produces little revenue, while a national proprietary contract concentrates licensing and support through existing channels. Open-source service firms need aggregated demand to hire staff, maintain test labs and offer guaranteed response times. Public purchasing can create the market it claims is absent. Multi-year regional contracts, shared help desks and common images make school support commercially viable without granting one vendor control of the code.

Community support remains useful but cannot carry institutional accountability alone. Forums and issue trackers provide expertise, yet a principal needs a named party responsible for triage and recovery. The Document Foundation’s recommendation to use enterprise versions and certified migration consultants for large organizations reflects this distinction. Community knowledge and contractual responsibility are complements. A provider can draw on upstream communities while giving the school service levels, documentation and escalation.

The gap will not close through advocacy that treats paid support as betrayal. Open-source freedom allows competition among operators, but operators must be paid to maintain that freedom in practice. Schools should budget support, require configurations to remain documented and upstream-compatible, and avoid customizations that only one contractor understands. A healthy market offers replaceable suppliers around a common platform. Microsoft remains easier where that market already exists. Linux becomes a serious default when policymakers invest in packaging, skills and procurement structures that turn open code into a dependable local service.

Regional authorities can shorten the distance between enterprise Linux and classroom reality by maintaining a reference service catalogue. It should name supported laptops, printers, interactive displays, accessibility tools and identity integrations, together with tested versions and known limitations. Suppliers would bid against the same baseline instead of inventing a new stack for each school. The catalogue should be updated through reported incidents, so one school’s discovery becomes shared operational knowledge.

Training capacity needs similar aggregation. A single school may not justify a full Linux administrator or curriculum specialist, but a district can maintain a mobile engineering team and a common training programme. Teachers then receive help tied to actual classroom workflows rather than generic desktop instruction. Support contracts should include busy-period coverage before term starts, examinations and reporting deadlines, because average response time can hide failure at the moment education is most exposed.

The strongest signal to the market is predictable demand. A public buyer can announce a multi-year sequence of pilots, supported devices and service lots while preserving competition among providers. Firms can then invest in staff and certification with some confidence that the market will exist. Without that demand, schools interpret the scarcity of suppliers as a technical defect in Linux. It is more accurately a consequence of fragmented purchasing and policy that funds licences centrally but leaves alternative support to individual institutions.

Document formats are the quiet battleground

Operating systems are visible, but file formats often determine whether a migration survives. A school can install Linux in an afternoon; it may spend years untangling documents whose layout, formulas, macros and embedded objects assume Microsoft Office behavior. The durable asset is the information, not the application. If records and teaching materials cannot move cleanly, the nominal freedom to change software has little value.

OpenDocument Format was designed as an application-independent, platform-independent format for text documents, spreadsheets, charts and related office content. OASIS publishes the standard, and multiple office suites implement it. That creates the possibility of competition because no single vendor has exclusive implementation rights. An open specification lowers legal and technical barriers to alternative readers and writers. It does not guarantee identical rendering, especially where applications interpret optional features differently, but it gives schools a documented baseline for testing and preservation.

Microsoft’s modern Office formats are standardized too, and Microsoft Office can work with more than one format. The practical issue is not a simple “open versus closed” label. It is which subset of a standard each product implements, how extensions are used, whether macros are portable, and which format external partners expect. Standards compliance must be tested through real round trips. A school should save representative files in one suite, open and edit them in another, then compare formulas, styles, comments, accessibility tags, images and metadata.

Fonts create hidden incompatibility. A document can use a standardized format yet reflow because the destination lacks the original typeface or substitutes one with different metrics. Presentations may lose line breaks, page counts may change and worksheets may print differently. Schools should use a tested cross-platform font set for new templates and embed fonts only when licensing permits. Visual fidelity depends on dependencies outside the file format. Media codecs, linked images, extensions and printer settings deserve the same inventory.

Macros and automation are the hardest layer. Visual Basic for Applications code may encode years of administrative logic without formal documentation. Rewriting it can be expensive and risky; running it only on legacy Office preserves dependence. The first task is to identify which macros are actually used, who owns them and what business rule each performs. Undocumented automation is institutional debt. Some macros can be replaced by formulas or web workflows; others need a controlled rewrite and parallel verification.

Format policy should distinguish creation, exchange and archive. New editable documents can default to an open format where workflows allow; external exchange may require a negotiated format; final records can be preserved in suitable archival forms; and high-risk legacy files can remain unchanged until reviewed. A gradual format transition reduces operating-system risk. Schools that adopt open formats while still running Windows and Microsoft Office build future choice without forcing every interface to change at once. The quiet battle is won when documents remain usable across suppliers and years, not when one extension disappears overnight.

Document cleanup has an educational and operational payoff even if migration stops. Removing duplicate templates, naming authoritative versions and documenting spreadsheet logic reduces errors under Microsoft Office as well as LibreOffice. It also reveals records that should not depend on an editable office file at all. A database, form service or controlled information system may be safer than a workbook passed between staff by email.

Compatibility testing needs severity levels. A changed line break in an internal worksheet may be acceptable; a shifted label on an examination paper, altered formula result or inaccessible heading structure is not. Teams should define which defects block migration, which require correction and which can be accepted. Without that hierarchy, supporters dismiss serious failures as cosmetic while opponents use harmless differences to reject the entire programme.

The archive deserves separate treatment from active collaboration. Records retained for legal, historical or administrative reasons need stable rendering, documented metadata and integrity controls, not endless editability. Schools can preserve a source file alongside a validated archival representation where policy permits. Periodic test opening is necessary because no format choice removes software aging. A format strategy therefore combines standards, validation, migration planning and custody rather than trusting a file extension to guarantee permanence.

Public reference documents can lower compatibility risk further. Authorities can publish approved templates, font packages and conversion guidance, then update them when suites change. Shared test sets should include complex spreadsheets, accessible documents and records with long retention periods. This turns document portability from a promise into a repeatable public test and gives software suppliers concrete defects to address.

Cloud collaboration moved the contest beyond operating systems

The classic Linux-versus-Windows debate assumed applications lived on the local computer. School work now moves through browsers, identity providers, cloud storage, shared documents, videoconferencing and learning platforms. The operating system may be the least powerful layer in the relationship. A Linux laptop signed into Microsoft 365 can remain deeply tied to Microsoft accounts, formats and cloud services; a Windows laptop using open web platforms may preserve more service-level choice.

Microsoft’s education offer illustrates the shift. The donated A1 tier provides web applications and cloud services to eligible institutions, while paid tiers add desktop software, management and security. A school can therefore standardize collaboration before it standardizes devices. Cloud adoption creates lock-in through data, identity and workflow rather than installation media. Class memberships, comments, versions, permissions, recordings and automation live inside the service. Exporting final files does not necessarily preserve those relationships.

Browsers lower migration barriers because the same application can run on Linux, Windows, macOS, tablets and phones. They also concentrate dependence on connectivity and provider availability. A local office suite keeps working during an internet outage; a cloud-first lesson may not. Schools need offline procedures, synchronization rules and clarity about which records exist only online. Platform neutrality at the browser can conceal infrastructure concentration behind it. The service owner, hosting region, authentication path and export capability still matter.

Open-source cloud platforms can be self-hosted or purchased from managed providers, offering more deployment choice. That choice brings operational duties: capacity planning, updates, backups, monitoring, incident response and integration. A school should not self-host merely to avoid a subscription if it cannot protect the service. Control without capability becomes risk. Regional hosting, shared public infrastructure or contracted European providers may offer a middle path between local servers and a global vendor.

Identity is the strategic control point. When one account governs email, files, meetings, classroom membership and device access, replacing any component becomes harder. Open protocols and federation can separate authentication from applications, but they require disciplined architecture. OECD describes interoperability across technical, semantic, organizational and legal dimensions, which is especially relevant to cloud ecosystems. A portable identity and data model matters more than a portable desktop image.

Schools should evaluate cloud services with exit drills. Create test users and courses, export representative data, restore it elsewhere, check metadata and permissions, then document what is lost. Require deletion evidence, transition assistance and standard interfaces in contracts. A service is only as open as the school’s tested ability to leave it. Linux can reduce device dependence, but it cannot deliver digital sovereignty by itself. The contest has moved upward into accounts, data and collaboration, where procurement and architecture decide whether another provider remains credible.

Collaboration habits deepen the dependency. A lesson may rely on live comments, assignment workflows, automatic notifications, embedded forms and meeting recordings that cannot be reproduced by moving a document alone. Before replacing a service, schools should map the complete activity from creation to assessment and retention. The replacement must preserve the required educational outcome, but it need not copy every incumbent feature if some steps were adopted only because the suite made them convenient.

Cloud cost is also distributed. Subscription prices are visible, while bandwidth, identity administration, storage growth, e-discovery, backup and support may sit in separate budgets. Self-hosted alternatives shift more of that spending into staff, infrastructure and contracts. Comparing only the application fee repeats the desktop licensing mistake at a higher layer. A sound model follows each service through operation, recovery and exit.

A layered architecture limits the consequences of one decision. Schools can keep an established collaboration suite while requiring independent backups, portable course exports and standard identity interfaces. They can run a separate learning platform or communication channel where that reduces concentration. The objective is not maximum fragmentation; too many systems create support and privacy problems. The objective is to prevent convenience at one layer from making every other layer unchangeable.

Service ownership must remain visible when applications move to the web. Teachers need to know who restores a deleted class, who investigates a failed synchronization and which provider handles an identity incident. A browser makes delivery look uniform, but responsibility may cross several suppliers. Incident maps and joint escalation rules prevent each party from treating the fault as someone else’s problem.

Cloud migration also changes evidence retention. Version histories, chats and recordings may follow different rules, and exports may omit context needed for complaints or audits. Schools should define official records, preservation locations and deletion authority before changing platforms.

A realistic cost model changes the debate

Cost arguments become unreliable when one side counts licences and the other counts every migration problem. A fair model applies the same categories to both options across a useful period, usually long enough to include at least one renewal and a substantial portion of the device lifecycle. Five-year ownership cost is a better starting point than first-year price. It should show cash spending, internal labor, risk allowances and residual obligations rather than compressing everything into one attractive total.

The baseline must be measured before alternatives are priced. Schools need current licence entitlements, actual feature use, device age, support tickets, staff training time, server costs, cloud storage, contractor fees and hours spent on manual compatibility work. Central funding should appear even if it does not hit the school’s account. Unmeasured incumbent cost is treated as free by default. The same discipline applies to open source: community editions cannot be costed at zero when enterprise support, packaging and migration are necessary.

Five-year cost categories to model

The model exposes costs hidden by both slogans. It should be populated with local evidence and ranges, not generic industry averages.

Scenario analysis is more honest than a single forecast. A best case may assume high device reuse and rapid staff adaptation; a worse case may include complex macro conversion, dual running and consultant dependence. The Microsoft path also needs scenarios for price changes, storage growth, security add-ons and hardware replacement. Uncertainty belongs inside the comparison. Decision-makers can then see which assumptions control the result and design pilots to measure them.

Benefits should be recorded separately from cost. Open formats, supplier choice, local skills and hardware reuse have strategic value even when they do not produce an immediate saving. Microsoft integration, familiarity and support-market depth also have value beyond licence price. Combining every benefit into a speculative monetary figure can create false precision. Score strategic benefits transparently rather than inventing cash values. The final decision can balance verified cost with policy goals.

The model must include exit on both sides. An open-source deployment can create lock-in through a contractor’s undocumented customization just as a proprietary cloud can create it through data and identity. Contracts should price transition help, require configuration documentation and preserve data in usable forms. The European Commission’s procurement position explicitly includes exit costs in total ownership assessment. Reversibility is an operating asset that deserves a budget line.

Once the model is complete, the result may justify staying with Microsoft, moving selected roles to Linux or funding a wider transition. The value lies in replacing moral certainty with auditable assumptions. A defensible decision explains who pays, when they pay and what options remain afterward. Schools should update the model annually with actual ticket volumes, training hours, licence use and device survival so the next renewal begins with evidence rather than inherited belief.

Internal labor should be recorded at realistic rates and by role. An hour of teacher preparation, technician troubleshooting and senior leadership review has a different opportunity cost, even when none appears on an invoice. Estimates should distinguish temporary migration work from recurring administration. Otherwise the proprietary path inherits years of embedded skill at no cost while the alternative is charged for every learning hour, or the reverse.

Device life requires cohort analysis rather than one average assumption. Some computers may gain useful years under Linux, while others fail batteries or storage regardless of operating system. Windows 11 eligibility may accelerate replacement for a defined group, but schools should not attribute every future purchase to Microsoft. Testing each hardware cohort produces a defensible range and identifies where reuse creates genuine savings. Microsoft’s published Windows 11 requirements give buyers a concrete baseline for that assessment.

Decision-makers should also inspect who bears each cost. A ministry-funded licence may be cheap for a school but expensive for the public budget; a local Linux project may save national fees while imposing uncompensated work on teachers. Costs transferred to families through required devices or software belong in the social assessment even when they sit outside the institution’s accounts. A fair comparison follows public money, staff time and household burden rather than celebrating savings achieved by shifting them elsewhere.

Sensitivity testing should be readable by nontechnical governors. Show how the result changes if training takes twice as long, ten percent fewer devices can be reused, or a support contract rises at renewal. The purpose is not to predict one exact future but to reveal assumptions that could reverse the decision. Leaders can then place contractual protections or pilot measurements around the most influential variables.

Updates refine assumptions.

Security arguments cut both ways

Security is often used as a final argument for whichever platform a speaker already prefers. Microsoft supporters point to integrated identity, endpoint protection, centralized policy and paid incident support. Linux supporters point to transparent code, rapid package updates, lower exposure to some common desktop malware and the ability to remove unnecessary components. Neither licence model guarantees secure operation. Security depends on configuration, patching, identity controls, backups, monitoring, user behavior, supplier practice and the school’s capacity to respond.

Microsoft’s education tiers bundle different security and compliance capabilities, so saying that a school “has Microsoft 365” does not establish which controls are active. The service description distinguishes features across A1, A3 and A5, and some advanced protections sit in higher tiers or add-ons. A familiar brand is not a security control. Schools must inventory licences, verify configuration and test alerts rather than assuming purchased capability is deployed capability.

Open-source transparency can support independent review, but public code does not mean every line has been reviewed or every vulnerability will be fixed quickly. Projects differ in maintainership, funding, release discipline and dependency management. NIST says open-source components are pervasive and recommends trustworthy repositories, vulnerability scanning, controlled libraries and software-composition practices. The right question is who maintains this exact package and how the school knows.

Repository-based Linux management can be a security strength. Administrators can distribute signed packages from approved sources, limit local installation and apply updates across a standardized image. It becomes a weakness when schools use unsupported distributions, add random repositories or depend on abandoned packages. Long-term support releases provide a clearer lifecycle, and Canonical publishes defined standard and extended maintenance periods for Ubuntu. Lifecycle policy matters more than novelty.

Concentration creates another trade-off. One integrated cloud may apply policy consistently and give a small team broad visibility. The same concentration means a compromised administrator account, identity outage or configuration error can affect many services at once. A modular open-source stack may contain failures but create more interfaces to secure. Architecture changes the shape of risk rather than eliminating it. Schools need multifactor authentication, least privilege, separate emergency accounts, immutable backups and incident exercises whichever platform they choose.

Procurement should demand evidence from both models: supported versions, vulnerability disclosure policy, patch timelines, secure update channels, logging, backup compatibility, software bills of materials where appropriate and clear incident responsibilities. CISA’s open-source roadmap and NIST guidance both treat open-source security as an ecosystem and governance challenge, not a reason to reject open code. Security belongs in continuous operations, not sales comparisons.

A school should choose the platform it can manage securely and improve that capacity over time. Staying with Microsoft may be safer than an unsupported Linux experiment; a well-run Linux fleet may be safer than a poorly configured Microsoft tenant. Operational maturity is the decisive variable. The policy objective is evidence: patched devices, recoverable data, controlled identities, tested response and accountable suppliers.

Backups provide a useful test of operational maturity. Schools should restore a representative workstation, shared folder and identity service under timed conditions, then document dependencies that prevent recovery. A backup that has never been restored is an assumption, not a control. The same exercise exposes whether recovery depends on one vendor portal, one contractor or undocumented local knowledge.

Patch speed must be measured end to end. A vendor or open-source project may publish a fix quickly, but the school remains exposed until packages are approved, distributed and confirmed on devices. Maintenance windows, bandwidth and failed updates all affect the result. Reporting should show supported versions, overdue devices and exceptions, allowing leaders to compare actual exposure rather than brand reputations.

User permissions deserve special attention in mixed estates during every major platform change. Staff who have local administrator rights to install a Windows application may carry that expectation to Linux, while restrictive Linux images may push them toward unsanctioned web tools. Security policy must connect application requests, rapid review and usable approved alternatives. Controls that make legitimate work impossible often move risk outside the managed platform instead of removing it.

Supplier diversity is another security variable. A school should know whether critical response depends on one account team, one cloud control plane or one regional Linux specialist. Concentration may improve coordination while increasing succession risk. Contracts, documentation and cross-training should make handover possible. The test is not whether the current provider is trusted, but whether security can continue when that relationship eventually changes.

Privacy and sovereignty raise harder questions

Schools process information about children, families and employees, including identities, communications, attendance, assessment and sometimes sensitive support needs. Moving that work into a global cloud changes who can technically process data, which contracts govern it and how rights requests are answered. Privacy is not solved by choosing a famous supplier or by hosting open source locally. It requires lawful purpose, data minimization, transparent information, access controls, retention rules, processor oversight and practical ability to respond to people.

The 2025 Austrian Microsoft 365 Education decision reported by the privacy group noyb sharpened the issue. Noyb stated that the Austrian Data Protection Authority found unlawful tracking cookies and failures around access and transparency, while assigning obligations across Microsoft and public education actors. Because the public summary comes from the complainant organization, its characterization should be read with that attribution rather than treated as Microsoft’s account. The case shows that schools cannot outsource legal responsibility by accepting default cloud terms.

Open source can improve inspectability and deployment choice. A public authority may run software on infrastructure under its control, choose a regional provider or audit the code. Yet self-hosting creates its own privacy risks if access logs, backups, administrator privileges or updates are poorly managed. Control is useful only when matched by governance capacity. A small school server in an unlocked room with weak backups may protect data less well than a carefully contracted cloud.

Digital sovereignty adds a wider concern: whether a public institution can continue operating if pricing, corporate strategy, legal jurisdiction or geopolitical conditions change. The European Commission’s open-source strategy links open source with digital autonomy, sharing, security and staying in control. The Interoperable Europe Act creates a legal framework for higher public-sector interoperability across the Union. Sovereignty is practical capacity to choose and continue, not national symbolism.

Data location alone does not settle sovereignty. A service may store files in Europe while relying on proprietary control planes, foreign support teams, nonportable identity systems or contracts the school cannot negotiate. Conversely, an open-source service operated by a capable European provider may offer portability even if some infrastructure components are global. Schools should ask who holds encryption keys, who can administer the service, which subprocessors participate, how data is exported and how operations continue after contract termination. Jurisdiction, technology and operational dependence must be assessed together.

Privacy impact assessments should use real workflows. Test student onboarding, parental communication, analytics, recordings, support access, deletion and subject-access requests. Avoid collecting optional telemetry or retaining data merely because storage is available. Require vendors and open-source operators to document roles and changes. The safest data is often data the school never collected.

A mixed strategy may offer the strongest near-term position: retain services that meet verified needs, reduce data concentration, use open formats, separate identity where feasible and build exit capability. Privacy and sovereignty improve through architecture and contract discipline, not through a one-day switch from Microsoft to Linux.

Contract review should identify the evidence a school can obtain rather than assuming the provider will answer every question. Large cloud contracts may be negotiated nationally, leaving individual schools little power to amend terms. That makes central due diligence, public guidance and clear allocation of controller and processor duties especially important. A local open-source provider may offer more negotiable terms, but the authority still needs technical and legal competence to test them.

Telemetry deserves a separate inventory. Operating systems, office suites, browsers, learning applications and security agents may all send diagnostic information for different purposes. Schools should know which flows are mandatory, optional or configurable, how long they persist and whether they are linked to identifiable accounts. Turning off unnecessary collection is more reliable than relying on a broad promise that data is used responsibly.

Sovereignty planning should include staffing and documentation. A school does not control a system merely because the server is in its building if only an external contractor understands the configuration. Conversely, a managed service can preserve practical choice when data exports, automation, keys and operational procedures are portable. The practical measure is whether another qualified operator could assume responsibility within an acceptable period without losing records or interrupting teaching.

Students and parents need understandable privacy notices that describe actual tools and choices. Generic statements covering every possible technology do not explain which service processes homework, recordings or diagnostic data. Notices should change when the workflow changes, and schools should provide a route for questions and rights requests. Transparency is operational work, not a document published once and forgotten.

Accessibility must be tested rather than assumed

A platform decision that saves money but blocks a disabled student or employee is not a successful migration. Accessibility covers screen readers, keyboard navigation, magnification, speech input, high contrast, captions, cognitive load, document structure and compatibility with specialist devices. Feature lists cannot substitute for task testing by real users. A suite may advertise keyboard access and accessibility checking while still presenting barriers in a particular workflow, version or assistive-technology combination.

Microsoft has invested heavily in accessibility across its products, and its education service description includes an Accessibility Checker across listed plans. Familiarity among support providers and compatibility with widely used Windows assistive technologies can make the environment safer for schools that lack specialist testing capacity. Existing accessibility knowledge is part of the incumbent advantage. That does not prove every Microsoft workflow is accessible, but it lowers the uncertainty around established configurations.

LibreOffice documents support for external assistive applications, keyboard access, readability controls and interface zoom. It also includes an accessibility checker for document structure and can export PDF/UA when configured. Open-source alternatives have concrete accessibility features, not merely good intentions. The question is whether those features work with the exact screen reader, operating system, language, templates and tasks used in the school.

Operating-system accessibility matters alongside application accessibility. Desktop environments differ in screen-reader integration, scaling, touch behavior and settings discoverability. Hardware drivers can affect braille displays, switches, eye-tracking equipment or audio devices. A Linux pilot that uses only nondisabled volunteers cannot reveal these failures. Accessibility users must participate before procurement, not after rollout. Their time should be paid or protected, and findings should carry authority to block or redesign a deployment.

Documents are a major source of barriers independent of platform. Poor heading structure, unlabeled images, low contrast and inaccessible tables remain inaccessible when moved between suites. Training should teach staff to create structured content, run checks and test exported files. Accessible authoring is a workflow, not an automatic product property. Standard templates can reduce effort, but they must be validated in every supported format.

Procurement needs measurable acceptance criteria. Representative users should complete tasks such as logging in, joining a class, reading a worksheet, editing a document, submitting work, recovering a file and contacting support. Record success, time, errors and workarounds. Require suppliers to fix high-severity barriers and define support for assistive technologies. A claimed standard conformance should begin investigation, not end it.

A role-based migration may preserve Windows for some accessibility configurations while other users move to Linux, but that should not isolate or stigmatize anyone. The school must maintain equal access to collaboration and documents across platforms. No user should become the permanent exception because the project failed to budget accessibility. The right platform is the one that delivers verified participation and a credible path for fixing defects.

Accessibility testing must continue after launch because updates change interfaces and assistive technologies evolve. Release management should include a small regression suite covering login, navigation, document authoring, collaboration, printing and recovery for representative users. Critical failures need an escalation path that reaches the supplier or upstream project, not a local workaround that silently becomes permanent.

Procurement teams should examine the accessibility of support itself. A telephone-only help desk may exclude some users; inaccessible ticket portals and training videos without captions can block assistance even when the application works. Documentation should be available in usable formats and plain language, with alternatives for people who cannot complete a standard workflow independently.

Schools also need a process for individual adjustments. Standardization lowers support cost, but equality may require specialist hardware, software, settings or additional time. These exceptions should be documented securely, tested during upgrades and transferred when a student changes device or class. Treating them as part of service design prevents emergency improvisation and makes platform costs honest.

Cost models should reserve money for remediation found during testing. Accessibility defects often require template changes, configuration, training or supplier work rather than abandoning the whole platform. A contingency makes correction possible without pressuring users to accept barriers for the sake of schedule. It also stops projects from treating accessibility as an optional enhancement after the main budget is committed.

Testing records should follow the user across upgrades and device replacements. Consent, privacy and dignity matter, so reports should describe barriers and required settings without exposing unnecessary medical information. A controlled adjustment profile lets technicians reproduce support reliably while limiting access to sensitive details. That practice is useful on both Linux and Windows.

Open source requires governance rather than enthusiasm

Open-source adoption often begins with a capable enthusiast who sees waste, installs a better tool and proves that it works. That energy is useful, but a public institution cannot base a critical service on personal commitment alone. Governance turns a successful experiment into durable infrastructure. It assigns ownership, lifecycle decisions, security review, support, documentation, funding and authority to accept or reject changes.

The school must know what it is adopting. “Linux” can mean many distributions and support models; “LibreOffice” can mean a community build or an enterprise-supported package; “Moodle” can mean self-hosting or a contracted service. Each choice changes responsibility. Open code does not make operating roles self-evident. A service catalog should name the version, operator, data owner, technical owner, support route, backup location, recovery objective and end-of-support date.

Upstream relationships matter. A school or regional provider may customize software, but private forks become costly when they diverge from the main project and no longer receive straightforward updates. Contributions, bug reports and funding can keep local needs aligned with upstream development. The European Commission’s strategy includes sharing, contributing, securing and staying in control, which reflects governance rather than passive consumption. Durable open source includes participation in the ecosystem.

A regional Open Source Programme Office can coordinate legal questions, inventories, procurement, training and reuse. Schleswig-Holstein’s public-sector experience shows that an OSPO can act as a point of contact, map existing resources and support migrations, though a state administration is not identical to a school system. The transferable lesson is organizational: expertise must have a home.

Decision rights should be clear. Teachers choose pedagogical methods within agreed boundaries; IT owns baseline security and supportability; data-protection officers review processing; accessibility specialists test participation; procurement enforces portability and service terms; leadership accepts residual risk. Shared input does not mean blurred accountability. A committee without named owners can discuss problems indefinitely while the enthusiast continues operating the system unofficially.

Funding must cover maintenance after the launch. Security updates, new hardware testing, documentation, training and migration to future releases recur. Grants that pay only for initial deployment create abandoned systems. Free licences do not create free lifecycles. A multi-year budget should include support and contribution, with spending compared against avoided proprietary costs but not dependent on optimistic savings.

Governance also protects open-source choice from political reversal. When configurations are documented, service levels are met and costs are measured, a new leader can evaluate evidence rather than folklore. Institutional memory is the strongest defense against both vendor lock-in and hobbyist fragility. Open source becomes ordinary when it is managed with the same seriousness expected of any critical school service.

Legal governance belongs beside technical governance. Open-source licences impose obligations that vary with distribution, modification and network delivery, while proprietary contracts impose use restrictions, audit terms and renewal conditions. Schools need qualified advice at the shared authority level rather than expecting local technicians to interpret every licence. A software inventory should connect each component to its licence, support status and distribution method.

Operational documentation should be tested through staff absence. Another technician must be able to rebuild a device, restore a service and locate administrative credentials without calling the original champion. Runbooks need dates, owners and evidence that steps still work. Documentation that merely describes an ideal architecture but omits local exceptions creates false confidence.

Governance can also set a contribution policy. Not every school should maintain code, but recurring bugs, translations and accessibility fixes should be reported upstream through an accountable channel. Regional authorities can fund maintainers or procurement suppliers to contribute accepted changes. That approach reduces private forks, improves the common product and converts public spending into reusable capability rather than a one-off local patch.

Service metrics should be agreed with users. Availability alone says little when a system is technically online but printing, file exchange or assistive access is broken. Measure successful tasks, recovery time, unresolved accessibility defects, patch compliance and support satisfaction by role. Governance bodies can then see whether the platform is serving education rather than merely meeting infrastructure uptime.

A change advisory process should be proportionate. Routine security updates can follow tested automation, while major desktop or application upgrades need compatibility review and communication. Emergency changes require retrospective documentation. The aim is not bureaucracy for every package; it is a visible rule for deciding when change may affect teaching, records or access.

Succession planning completes the model. Credentials, keys, contacts and renewal dates must survive staff departure. A service dependent on one administrator is not institutionally controlled.

Migration failures usually begin before installation

Most failed migrations are described through visible symptoms: angry users, broken documents, missing applications or a retreat to the old platform. The root causes often appear months earlier in incomplete inventory, unrealistic deadlines, weak sponsorship and a business case built around licence savings alone. Installation is the easiest part of a desktop migration. The hard work is deciding which workflows must change, which exceptions remain and who has time to make the transition.

A poor inventory misses macros, fonts, browser plugins, peripherals, shared mailboxes, specialist software, accessibility setups and unofficial tools. These dependencies surface only when a user needs them. The project then treats each discovery as unexpected resistance rather than evidence that planning was incomplete. Unknown dependencies turn normal work into emergencies. Interviews, automated software inventory, document sampling and observation of real tasks are all needed because no single method finds everything.

Projects fail when pilots use only technical volunteers. Enthusiasts tolerate rough edges, search forums and understand workarounds that ordinary staff cannot use during a lesson. A pilot must include skeptical users, administrators, people with access needs and departments with complex documents. Representative difficulty is more useful than enthusiastic success. The goal is to discover conditions under which the rollout would fail, not to produce a flattering demonstration.

Deadlines can become political promises detached from readiness. A leader announces that Microsoft will be gone by a fixed date, and teams hide problems to protect the schedule. Another leader refuses any timeline, so exceptions expand forever. Milestones should be tied to acceptance evidence. Move a user group when its documents, applications, training, support and recovery tests pass; pause when they do not.

Communication failures are equally damaging. Staff hear “free software” and conclude that leaders value licences more than their time. Technicians hear “simple replacement” and know the integration work has been ignored. Parents hear “Linux” without knowing whether homework will still open. People resist being made responsible for unacknowledged risk. Honest communication should state benefits, limitations, retained Windows use and the support available.

A rollback plan is not defeatism. It defines how to restore service if a release introduces critical failure and preserves data created during the pilot. Without rollback, every issue becomes a crisis and leaders become afraid to test. Reversible change creates confidence. The project can learn aggressively because it knows how to protect teaching.

The migration succeeds before installation when governance, inventory, testing, support and decision thresholds are in place. Software deployment then becomes one controlled step in a longer service redesign. Open source cannot compensate for weak change management, and Microsoft cannot compensate for it either.

The inventory must include people as well as technology. Identify who knows each macro, template, classroom routine and emergency workaround, then capture that knowledge before the rollout. Staff turnover can remove a dependency as surely as a software update. Interviews should ask what users do when the official process fails, because the unofficial path often contains the most important compatibility requirement.

A migration office should maintain an issue taxonomy. Separate defects in the chosen product from training gaps, unsupported legacy design, hardware faults and policy disagreements. Without classification, every ticket becomes evidence for a predetermined position. Trends by severity, role and workflow tell leaders whether engineering, training or scope change is the proper response.

Political sponsorship must survive bad news. A credible sponsor protects staff who report failures, authorizes extra time and changes the plan when evidence contradicts the original business case. The purpose of a pilot is to make uncertainty visible while the blast radius is small. Declaring success before users have completed a full reporting, assessment or examination cycle removes the main value of the exercise.

Data conversion should be treated as a controlled information project. Keep originals, document the conversion tool and version, sample results by document type and record known losses. High-risk records may require manual verification or parallel retention. Deleting source files immediately after conversion removes the evidence needed to diagnose a later discrepancy.

Support teams need authority to solve recurring causes rather than closing the same ticket repeatedly. If every lesson requires a manual printer reset or every spreadsheet needs a compatibility correction, the project has not achieved a stable service. Problem management should identify patterns, assign owners and decide whether to fix, replace or retain the incumbent workflow.

The final readiness review must include those carrying the consequences. Teachers, technicians, leaders and privacy staff should sign off against evidence and recorded risk.

Successful transitions are phased and role-based

A whole-school replacement creates the largest possible blast radius. A phased transition reduces risk by moving groups whose tasks are understood, measuring results and carrying lessons into the next stage. The unit of migration should be a role or workflow, not a device count. Fifty library terminals with a stable browser task may be easier than ten administrators using undocumented macros. Progress should reflect completed capability, not how many Linux images were installed.

The sequence often begins above or beside the operating system. Schools can adopt cross-platform applications, standard fonts and open document formats while still running Windows. They can move selected services to interoperable or open platforms, build identity federation and test data exports. Reducing dependence before changing the desktop lowers the eventual migration load. LibreOffice can run on Windows, letting staff learn a new office suite without simultaneously learning a new operating system.

Pilots need entry and exit criteria. Before a group moves, critical applications, peripherals, accessibility needs, training and support must be ready. After a set period, leaders review task success, tickets, downtime, user confidence, document fidelity and costs. A pilot without a decision rule becomes a permanent exception or a public-relations exercise. Metrics should be agreed before results are known so supporters and critics cannot move the goalposts.

Windows islands should be designed rather than tolerated. Specialist labs, exam stations or finance desktops may remain for verified reasons. Keep them patched, limit applications, document owners and review the exception at every renewal. A smaller proprietary footprint can deliver most sovereignty benefits without forcing unsuitable workflows onto Linux. Segmentation also reveals the true cost of each retained dependency.

Training follows the rollout wave. Generic mass training months before migration is forgotten; training after deployment leaves staff exposed. Use role-specific sessions, sandbox accounts, converted templates and floor support during the first live days. Protect time for peer champions and document recurring fixes. Support intensity should peak when behavior changes.

Infrastructure teams should standardize images and automate configuration before scaling. Manual installation may prove a concept but produces drift across hundreds of devices. A production platform needs approved repositories, update rings, monitoring, recovery images and inventory. Automation is the bridge from pilot to service. It also preserves knowledge when staff change.

The end state can remain mixed. Success means each role uses a supported platform, information moves through documented standards, data can be exported and no single supplier is impossible to replace. Phasing is not indecision when every stage reduces a measured dependency. It is the method that turns open-source adoption from an ideological event into controlled institutional change.

Each wave should have a named service manager who reviews incidents and authorizes expansion. Technical teams need permission to stop a rollout when recovery, accessibility or high-stakes tasks fail. Teachers need a rapid route to distinguish a local question from a platform defect. Governance at wave level prevents a central project board from learning about classroom problems only after confidence has collapsed.

Parallel running should be limited and purposeful. Keeping both suites and operating systems indefinitely doubles testing and confuses which version is authoritative. The project should state which workflows require dual access, how long it lasts and what evidence closes the period. Where a retained Windows application remains permanent, integrate it as a documented service rather than calling the whole migration unfinished.

Benefits should be reviewed after the novelty period. Early support demand may be high, while promised device-life or supplier-choice gains appear later. Compare actual outcomes with the baseline at six, twelve and twenty-four months where practical. Publish unfavorable findings as well as savings. Transparent review lets future schools reuse the lesson and prevents the programme from surviving only through political loyalty.

Migration waves can differ in destination. One group may adopt Linux and LibreOffice, another may keep Windows while moving to open formats, and a third may retain Microsoft Office through a managed remote service. Treating these as planned patterns avoids forcing every role through the same technical route. The common measures are supportability, portability and documented cost.

Champions should have defined duties and limits. They can demonstrate workflows, collect feedback and reduce anxiety, but they should not become unpaid first-line support or arbiters of whether colleagues’ problems are legitimate. Formal support must absorb the knowledge champions produce and remain available when those staff move roles.

A phased programme closes when every retained platform has an owner, support path, review date and documented reason. Temporary dual systems then end and ordinary governance begins.

Schools can reduce dependence without abandoning Microsoft

A school does not need to uninstall every Microsoft product to gain bargaining power and resilience. The more practical goal is to remove points where one vendor controls information, identity, workflow and support simultaneously. Dependency can be reduced layer by layer. A school may keep Microsoft 365 for collaboration while adopting open formats for archives, Linux for coding labs, Moodle for courses or an independent backup and export process.

Document policy is an early lever. Use stable open or archival formats for records and external publication where appropriate, standardize cross-platform fonts and avoid unnecessary macros. Test important files in more than one suite. Information that survives application change is a strategic asset. OASIS’s OpenDocument standard and OECD guidance on open standards provide a basis for interoperability, though implementation still needs local testing.

Identity can be separated gradually. Instead of letting one cloud account become the sole authoritative source for every service, schools can maintain a controlled directory and use standard federation or provisioning interfaces. That architecture requires expertise but makes individual applications more replaceable. The login should connect services without owning the institution.

Backups and exports deserve independent control. A synchronized cloud folder is not necessarily a backup, and an export that loses permissions or versions may not support recovery. Schools should keep protected copies under a separate administrative boundary and run restoration tests. Data exit should be exercised before it is needed. Contract renewals are stronger when the school can demonstrate that records and critical metadata are recoverable.

Procurement can unbundle new needs. A school that remains on Microsoft desktops can still require a new learning platform, website, analytics tool or communication service to use open APIs and portable data. It can ask vendors to support Linux and multiple browsers in future hardware and applications. Every neutral requirement prevents the next dependency. Collective buyers can create stronger incentives than one school acting alone.

Staff exposure to alternatives matters. Install LibreOffice alongside Microsoft Office for selected tasks, teach students more than one suite and use Linux in subjects where it fits. This builds internal skill and reveals compatibility problems without a crisis deadline. Capability is an option value. A school that knows how alternatives perform can negotiate or migrate; one that has never tested them must accept the incumbent’s timetable.

Microsoft may remain the best-supported choice for important functions. The objective is not punishment or purity. It is to ensure that continued use rests on verified value rather than inability to leave. A mixed, interoperable estate can be more independent than a nominally open system controlled by one contractor. Control comes from standards, skills, exports, contracts and alternatives that have been tested in practice.

Browser and device policy provide another low-conflict step. Require critical teaching and administrative services to work in current standards-based browsers, and test them on at least two operating systems during procurement. New peripherals should have documented cross-platform support where the use case permits. These requirements expand future choice without disrupting current staff.

Schools can also separate records from convenience copies. Important documents, course exports and configuration data should be retained under school-controlled policies rather than relying solely on a collaboration tenant’s live state. Periodic exports reveal missing metadata and give administrators practice with recovery. The result is useful even when no supplier change is planned.

A mixed strategy needs an architecture record so temporary compromises do not become invisible permanence. List each Microsoft-dependent function, the reason it remains, its cost, the owner and the next review date. Do the same for open-source services tied to one contractor. Independence grows when every exception is explicit, challengeable and supported, not when one brand disappears from the desktop wallpaper.

Contract negotiation becomes stronger once alternatives are operational. Even a limited Linux estate gives the school evidence about device life, support demand and user acceptance. That evidence can challenge renewal assumptions and justify narrower licence tiers. A credible option has more bargaining value than a policy statement that has never been tested.

Curriculum policy can preserve pluralism. Teach file formats, web standards, privacy, automation and system concepts alongside the interfaces students will encounter in work. Provide at least occasional exposure to different operating systems and office suites. The purpose is not equal classroom time for every product, but confidence that digital competence extends beyond one account and menu.

The remaining Microsoft footprint should be contained and recoverable. Limit privileges, separate critical administration, test backups and avoid making one identity the sole gateway to every service.

Procurement rules can create real competition

Schools respond to the market presented to them. If national frameworks list Microsoft packages with clear prices and support while open-source options require bespoke tenders, local leaders predictably choose the easier route. Competition begins in procurement design, not at the classroom door. Governments can create framework lots for Linux desktop services, LibreOffice migration, open cloud platforms, training, security and support, giving schools a lawful and comparable purchasing path.

Requirements should describe outcomes and standards. Ask for collaborative editing, identity federation, offline access, device management, accessibility and export rather than naming a product unless compatibility with a named system is genuinely unavoidable. OECD guidance argues that open standards reduce interoperability problems and vendor lock-in in education. Brand-neutral wording is insufficient if the technical specification still assumes the incumbent.

Total ownership models should be mandatory for major platform contracts. They must include migration, training, internal labor, dual running, hardware, support, data extraction and exit. The European Commission’s open-source policy calls for equal assessment including exit costs. A low renewal price should not erase the cost of dependence, and a zero licence should not erase the cost of building a service.

Frameworks can require modularity. Identity, office applications, storage, meetings and device management do not have to come from one supplier, though integration responsibilities must remain clear. Interfaces should be documented, data models exportable and subcontractors disclosed. Modular procurement creates choice only when one party owns end-to-end incidents. A lead integrator or public platform team can prevent suppliers from blaming one another.

Public authorities should fund reference implementations and test laboratories. A standard Linux image on approved hardware, connected to common school identity and printers, gives bidders and schools a shared baseline. Accessibility users and subject specialists can test it once for many institutions. Shared evidence lowers the cost of trying an alternative. It also prevents each school from repeating the same compatibility mistakes.

Contracts should reward upstream contribution and discourage private lock-in. If a supplier modifies open-source software with public money, the buyer should seek rights and processes that allow reuse, subject to security and legal limits. Configuration and automation scripts should be delivered in documented form. Open code can still be trapped by closed operations.

Slovakia’s broader ICT procurement challenge has already drawn OECD recommendations for more coordinated, agile purchasing and stronger governance. School technology can use the same principle: smaller pilots, user feedback, modular outcomes and evidence before scale. Public purchasing can create a support ecosystem around open source rather than waiting for one to appear spontaneously.

Evaluation should include proof-of-concept tasks before a formal promise of scale. Suppliers can demonstrate deployment, update, recovery, document exchange, accessibility and identity integration on the buyer’s representative hardware and data. The authority should retain test scripts and results so claims can be compared. Demonstrations must not use idealized devices that hide the diversity of the real fleet.

Award criteria need enough weight to influence behavior. A five-percent score for portability will not counter a specification built around one ecosystem, while an openness declaration without tests rewards polished paperwork. Buyers can set minimum gates for export, supported standards and transition assistance, then score service quality and cost among compliant bids.

Framework managers should monitor delivery after award. Contract dashboards can record update compliance, incident resolution, export success, accessibility defects and use of subcontractors. Renewal decisions should examine these results rather than starting from the assumption that changing supplier is too disruptive. Procurement creates competition only when poor performance can lead to a credible replacement.

Public-sector buyers can cooperate on contract language. Shared clauses for data export, open formats, vulnerability reporting, accessibility, subcontractor changes and transition assistance reduce legal cost and make expectations predictable for suppliers. Common language should still allow local needs, but it prevents every school from negotiating fundamental protections alone.

Competition also depends on timing. A tender issued weeks before licence expiry gives the incumbent an advantage because alternatives cannot complete discovery or pilots. Authorities should begin market and exit work well before renewal, with access to documentation and test environments. The option to extend briefly may be cheaper than signing another long contract under artificial urgency.

Appeal and audit processes benefit from concrete evidence. When requirements, test scripts and scoring rationales are preserved, the authority can defend a choice based on educational need rather than brand preference. That discipline also exposes discriminatory specifications early, before bidders spend money responding to a contest they cannot realistically win.

A practical roadmap for school leaders

The first decision is not whether to install Linux. It is whether the school wants lower cost, longer device life, stronger privacy, more supplier choice, better computing education or resilience against a specific renewal. A migration without a ranked objective cannot resolve trade-offs. Leaders should choose measurable goals and accept that different goals may produce different platform choices.

Begin with an inventory of devices, applications, documents, cloud services, accounts, peripherals, accessibility needs, contracts and staff skills. Include unofficial tools and critical spreadsheets. Record support dates and external requirements. The inventory should map tasks to dependencies, not merely count licences. Ask what fails if each service disappears for a day and who can restore it.

Create a governance group with named authority. Include leadership, IT, teachers, administration, data protection, accessibility and student or parent representation where suitable. Assign a service owner, technical owner and decision-maker. Consultation must end in accountable choices. Publish scope, risks, success criteria and a route for reporting problems.

Build the financial baseline. Count central subsidies, local spending, staff time, support, device refresh and exit exposure across several years. Model Microsoft, mixed and open-source paths with ranges. Do not promise savings before the pilot produces evidence. The case may rest on control or hardware reuse even if the first years cost more.

Reduce avoidable dependencies before the operating-system pilot. Standardize fonts, use open or archival formats where suitable, clean obsolete files, document macros, test exports and introduce cross-platform applications. Separate identity through standards where capacity permits. Preparation creates value even if the desktop never changes.

Select a bounded pilot with representative users. General student devices, a coding lab or library terminals may be suitable, but include real printing, projection, accessibility and support. Keep rollback and spare devices ready. Train close to deployment. Measure task completion, incidents and recovery, not sentiment alone.

Choose a supported architecture. Use a long-term distribution, approved repositories, automated configuration, monitoring, backups and a named support provider. Avoid unique local forks. Require documentation and an exit route from the contractor. The school needs a service, not an image file.

Review evidence at a fixed point. Expand by role when thresholds pass, redesign when failures are fixable and retain Windows where a verified requirement remains. Reprice the model with actual labor and device data. Each phase should leave the school more reversible than before. That is a credible roadmap whether the final estate is mostly Linux, mostly Microsoft or intentionally mixed.

The roadmap should begin with a written problem statement approved by leadership. “Use open source” is not a problem statement; “keep 600 classroom devices serviceable for three more years without weakening security” is. A precise problem lets teams compare Linux, hardware replacement, browser-based use and mixed options against the same outcome.

Set a small evidence budget before seeking a transformation budget. Pay for inventory, application testing, accessibility review, document sampling and a supported pilot. Those activities produce reusable knowledge even when the final decision favors Microsoft. They also prevent a large tender from embedding assumptions that nobody has tested.

Record decisions in plain language. For each major dependency, state the evidence, accepted risk, owner and review date. Publish a staff-facing version that explains what will change and what will not. Honest records reduce rumor, help new leaders understand the programme and keep technical nuance from becoming a contest between slogans.

The roadmap needs stop conditions as well as milestones. Pause when a high-severity accessibility barrier remains, recovery tests fail, examination compatibility is unresolved or support capacity falls below the agreed level. A stop condition protects users and gives technical teams authority to fix causes before political momentum expands the damage.

Create a communication calendar around real school events. Avoid major change immediately before examinations, reporting deadlines or enrollment. Give staff converted examples and a named support route before their first live task. Parents and students should hear what changes for homework, accounts and file submission, not a technical manifesto.

At each review, compare three choices: continue, redesign or stop. Continuing should require passed evidence; redesign should have a bounded action and new test date; stopping should preserve lessons and reusable work. A pilot that concludes Microsoft remains preferable can still justify its cost by documenting dependencies and improving future procurement.

Finally, connect the roadmap to normal budget and risk cycles. Open-source adoption becomes credible when ownership, funding, training and review continue after the launch team leaves.

The policy choice is resilience rather than ideology

The debate is often framed as a moral contest between expensive corporate software and free community software. Schools cannot govern critical systems through that frame. Microsoft offers familiar applications, integrated management, a deep support market and education discounts; Linux and open-source tools offer inspectability, deployment choice, open standards, hardware reuse and the possibility of supplier competition. Both models solve real problems and create real dependencies.

Microsoft dominates many school desktops because institutions inherit workflows, centrally funded licences, staff habits, compatible applications and risk structures that reward continuity. That outcome is not proof that Linux is unsuitable. It is evidence that software choice is institutional. A technically superior component loses when the surrounding service is absent. Open-source policy must therefore fund support, packaging, training, accessibility and governance, not merely recommend a download.

The public interest lies in preserving options. OECD work links interoperability to lower manual burden and reduced vendor lock-in, while the European Commission promotes open source, reuse and control within its own strategy. The Interoperable Europe Act reinforces public-sector interoperability as a Union objective. Open standards are the minimum protection even when proprietary software remains.

Resilience means a school can continue teaching during an outage, restore data after an attack, replace unsupported hardware selectively, recruit or contract support, and change suppliers without losing its records. It also means disabled users can participate, teachers can perform critical tasks and students are not excluded by household software costs. The platform is successful only when the education service survives its failures.

A resilient estate may be mixed. Linux can run labs, kiosks, servers and general student devices; Microsoft can remain for specialist applications, administration or collaboration while dependencies are reduced. Open-source applications can run on Windows, and proprietary web services can run on Linux. Layered choice is more realistic than a single-vendor identity.

Governments have a larger responsibility than individual schools. They can negotiate contracts, mandate portability, fund shared open-source services, certify hardware, maintain reference images, create support frameworks and require cross-platform access in examination and administration systems. Without shared infrastructure, local freedom becomes local burden. With it, schools can choose based on evidence rather than support scarcity.

The answer to the original question is therefore uncomfortable but useful. Schools use Microsoft because the institution around Microsoft is already paid for, familiar and accountable, while the institution around desktop Linux often has to be built. The remedy is not to shame schools or deny migration cost. Build credible alternatives, measure full costs and keep exits open. A school that can leave Microsoft may rationally stay; a school that cannot leave has not made a choice.

Resilience also requires institutional diversity. When every school uses the same identity, storage, communication and device platform, central management becomes easier, but one contractual dispute or widespread outage can have a larger reach. Diversity without coordination creates its own fragility, so the goal is not random local stacks. Shared standards and recovery plans allow selected diversity while preserving support.

Education policy should treat software knowledge as public capacity. Technicians, teachers and procurement staff who understand open formats, Linux administration, cloud exit and accessible design give the system options that no contract can guarantee. Training budgets should build that capacity even when the current supplier performs well. Skills are a form of insurance against market and technical change.

The strongest policy does not predetermine one winner for every role. It creates testing, pays for the support needed by credible alternatives and protects information from application dependence. Microsoft may win many evaluations on service maturity; Linux may win where control, hardware reuse or curriculum fit matters more. The public value comes from a decision that can be revisited without crisis.

Public reporting should avoid triumphal numbers. Counting migrated devices says little about service quality, while headline licence savings may omit training and support. Report task completion, accessibility, incidents, device survival, full public cost and remaining dependencies. Evidence that a mixed strategy works is more useful than a claim that one platform defeated another.

National policy can create fallback capacity. Shared repositories, reference images, interoperable identity services, training materials and emergency support make it possible for schools to change suppliers without starting from zero. Those assets should use documented standards and permit multiple contractors to participate. A public alternative need not replace the market; it can ensure the market remains contestable.

The mature question is which combination preserves teaching, access, security and public control at acceptable cost. Tested alternatives and transferable skills make staying or moving a real decision.

Questions that decide a school platform choice

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Compare Microsoft 365 Education plans
Microsoft’s current comparison of Office 365 A1 and Microsoft 365 Education A3 and A5, including web, desktop, security, management and accessibility features.

Microsoft 365 Education
Microsoft Learn’s service description showing feature availability across education plans and the differences between web, desktop, security and compliance capabilities.

Windows 10 reaching end of support
Microsoft’s lifecycle notice confirming the October 14, 2025 end-of-support date and the available upgrade, replacement and Extended Security Updates paths.

Windows 11 system requirements
Microsoft’s official hardware baseline for Windows 11, including processor, memory, UEFI, Secure Boot and TPM requirements.

Public procurement shaping digital education ecosystems
OECD analysis of how procurement choices, frameworks and requirements shape digital education markets and institutional technology decisions.

Interoperability unifying and maximising data reuse within digital education ecosystems
OECD analysis of technical, semantic, organizational and legal interoperability in education systems.

Guidance and regulatory frameworks for digital education
OECD guidance on open standards, interoperability, regulation and reducing inefficiency and vendor lock-in in digital education.

Quality and innovation in the EdTech and education materials markets
OECD discussion of EdTech market structure, vendor lock-in, teacher autonomy and the conditions for competition and innovation.

Technology in education 2023 GEM Report
UNESCO’s global education monitoring report on technology in education, including governance, evidence, costs and dependence on commercial platforms.

Free and Open Source Software
UNESCO’s overview of free and open-source software as a foundation for open digital solutions, knowledge sharing and access.

Open source software strategy
The European Commission’s institutional strategy on using, sharing, contributing to and governing open-source software, including total ownership and exit considerations.

The EU Open Source Strategy
The European Commission’s 2026 strategy connecting open source with technological sovereignty, public procurement, skills, maintenance and long-term ecosystem support.

Regulation EU 2024/903 establishing measures for a high level of public sector interoperability across the Union
The official text of the Interoperable Europe Act and its framework for public-sector interoperability.

Towards Agile ICT Procurement in the Slovak Republic
OECD assessment of Slovak public ICT procurement and recommendations for coordination, governance and more agile purchasing.

For business
LibreOffice guidance distinguishing community software from professionally supported deployments and recommending certified migration expertise for large organizations.

Ubuntu release cycle
Canonical’s published support lifecycle for Ubuntu releases, including standard maintenance and extended commercial coverage.

Moodle open source
Moodle’s explanation of its open-source model and the relationship between downloadable software, customization, hosting and commercial services.

Vitalinux Aragon’s school Linux distribution
An Interoperable Europe case study describing Aragon’s centrally maintained Linux distribution for schools, shared support and hardware reuse.

Schleswig-Holstein’s Open Source Strategy a year on
An Interoperable Europe review of Schleswig-Holstein’s Open Source Programme Office and the organizational work supporting public-sector migration.

Microsoft software licences for schools
New Zealand Ministry of Education guidance on centrally funded Microsoft licensing for eligible schools during the 2025–2027 agreement period.

Bezplatný Microsoft 365 Education pre študentov
Technical University in Zvolen information on Microsoft 365 Education access under a Slovak ministry agreement.

Open Document Format for Office Applications OpenDocument Version 1.2
The OASIS standard defining an application-independent and platform-independent office document format.

Software Security in Supply Chains Open Source Software Controls
NIST guidance on trustworthy repositories, vulnerability scanning, sanctioned libraries and governance for open-source components.

CISA Open Source Software Security Roadmap
CISA’s roadmap for strengthening open-source software security through ecosystem coordination, visibility and risk management.

Technical requirements for Creative Cloud apps
Adobe’s official operating-system and hardware requirements for Creative Cloud desktop applications.

AutoCAD and verticals on Linux
Autodesk’s support statement explaining that AutoCAD and its vertical products are not officially supported on Linux.

Accessibility in LibreOffice
LibreOffice documentation for assistive technologies, keyboard operation, zoom and other accessibility functions.

Accessibility Check
LibreOffice documentation for checking document structure and identifying accessibility problems.

PDF export universal accessibility
LibreOffice documentation for PDF/UA export and accessibility-related PDF settings.

noyb win Microsoft 365 Education tracks school children
Noyb’s account of the 2025 Austrian Data Protection Authority decision concerning Microsoft 365 Education, tracking, access and transparency obligations.