Why self-hosted file sharing for education starts with student records
Campus IT and records offices facing semester-based onboarding, large student populations and FERPA obligations usually start with Nextcloud, with Seafile as the main alternative. Both can run on infrastructure the institution controls, so the decision turns less on feature checklists and more on three things: how education records are handled, how identity is federated, and what each active user costs over the life of the platform. Nextcloud is the usual starting point because its LDAP app, OpenID Connect and SAML backends let directory and campus login accounts appear in the platform, and it offers a paid Enterprise edition aimed at education users. Seafile remains a credible option where the team wants a simpler file sync and share service and has already tested its identity and storage fit.
Under FERPA (34 CFR Part 99), the institution remains responsible for who sees a student's education records, and any outside party that runs the service must qualify as a school official under the conditions in 34 CFR 99.31(a)(1)(i)(B). Before choosing a product, confirm which records will live in the platform, who administers it, and whether the hosting partner's staff will have access to content. Also confirm how the institution will meet the access-control and disclosure-logging duties in 34 CFR 99.31(a)(1)(ii) and 34 CFR 99.32, because those requirements shape role design, group permissions and audit configuration from day one.
Cost per user is where education deployments most often diverge from plans. Nextcloud Enterprise is sold with a 100-user minimum, and the published list prices in the Nextcloud pricing page are quoted per user per year, so enrollment counts, seasonal peaks and guest accounts all change the figure. Ask every vendor or partner to price the full student population, the staff population and the expected external collaborators separately, and to state what is one-time (installation, identity integration, migration of existing storage) and what recurs (subscriptions, hosting, administration time). This page covers only the education-specific differences, so the general sizing and cost model sits in the file sharing cost guide.
Which education rules shape the file sharing build
This table maps the education rules most likely to apply to a university or school file sharing platform into concrete build requirements. Read each row as a requirement, what it means for the Nextcloud design, and the evidence an assessor or auditor will ask to see. Whether each rule applies depends on funding, student age and your legal counsel's reading of your institution's status.
| Rule | What it means for the build | Evidence to keep |
|---|---|---|
| FERPA school official exception (34 CFR 99.31) | Vendors or contractors operating the platform can see student records only if they perform a service the school would otherwise do itself and remain under the school's direct control. Limit access by group so staff see only records tied to their educational interest. | Signed contract or data processing terms, role-to-group access mapping, and documented legitimate educational interest rules |
| FERPA access and disclosure logging (34 CFR 99.32) | Log each request for and disclosure of personally identifiable information from student records, including who accessed it and why. Retain these logs for as long as the records are kept, so audit log retention must match records retention. | Exported access logs, log retention settings, and a sample reconstruction of who accessed a given student file |
| FERPA inspection timelines (34 CFR 99.10) | Files and folders holding education records must be findable by student or record identifier within the statutory window of not more than 45 days. Search metadata, folder naming and index settings affect whether this is achievable. | Documented search procedure and a timed test retrieval for a sample student file |
| FERPA enforcement exposure (34 CFR 99.67) | A failed FERPA compliance position can lead to withheld funding or termination of funding eligibility. This raises the stakes for access control and logging decisions made during the build, not just later operations. | Board-approved data governance policy and a named FERPA compliance owner |
| COPPA retention limits for under-13 users (16 CFR 312.10) | Where the platform holds personal information from children under 13, such as in K-8 deployments, set retention and deletion timeframes for accounts, uploads and trash. Indefinite retention is not permitted, so default settings should not keep data forever. | Written data retention policy with deletion timeframes and evidence of scheduled deletion jobs |
| COPPA security program (16 CFR 312.2 and 312.8) | Operators collecting children's personal information must maintain a written information security program with a designated coordinator and at least annual risk assessments. Plan for this program to cover the file platform and any hosting provider. | Written security program, named coordinator, and annual risk assessment reports |
| GLBA Safeguards Rule written program (16 CFR 314.4) | Title IV institutions must run a written information security program covering systems that hold student financial aid data. Financial aid files that land in general file shares need to be identified and placed in a restricted area. | Written information security program, data inventory showing where financial aid data lives, and risk assessment records |
| GLBA multi-factor authentication (16 CFR 314.4(c)(5)) | Require multi-factor authentication for anyone accessing any information system holding covered data, including administrators and staff using sync clients. Configure this in the identity provider and enforce it for Nextcloud logins, including app passwords where allowed. | MFA enforcement settings, exception register with approvals, and sign-in logs showing MFA use |
| GLBA breach notification (16 CFR 314.4(j)) | If a notification event affects at least 500 consumers, notify the FTC within 30 days of discovery. Access logs and alerting on Nextcloud must be fast enough to scope an incident inside that window. | Incident response runbook with a named FTC notification owner and tested log export procedure |
| ADA Title II web and mobile accessibility (28 CFR Part 35 Subpart H) | Public institutions must make web and mobile content accessible. Choose sync clients, the web interface and any editing or viewing apps with accessibility in mind, and test them with assistive technology before rollout to students. | Accessibility conformance evaluation of the web interface and clients, and a remediation plan for known gaps |
| Vendor and partner control | Hosting, support and integration partners must work under written terms that restrict their access, require breach notice and return or destroy data at exit. Keep administrative access inside the institution's accounts wherever possible. | Signed partner agreements, privileged access register, and vendor access reviews |
What student data sits in shared folders and why it spreads
Student files rarely stay in one folder. In a university or school file share, coursework and drafts sit next to advising notes, disciplinary correspondence, financial aid documents, research datasets that contain student participant data, and staff personnel records. Each class carries a different legal weight under FERPA, and the mix changes the moment a file is synced to a laptop, linked from the learning management system or copied into a departmental share. Before you size storage or design roles, inventory which classes will land in the platform, which campus systems will push or pull them, and which departments will create their own shared spaces. Ask the platform owner to show where a single assignment file travels from upload to grade export, because that path defines your access and audit scope.
The FERPA school official exception is the reason control over administration matters as much as encryption. A contractor can receive education records only if it performs a service the institution would otherwise staff internally, is under the institution's direct control for the use and maintenance of those records, and follows the redisclosure limits in 34 CFR 99.33(a) (see 34 CFR Part 99). A partner that hosts or administers a Nextcloud instance is therefore inside that test, so the contract, the admin accounts, the support access paths and the change control must all show the institution holding the controls. Confirm in writing who holds the root and database credentials, who can open user files during support, and how the institution can revoke that access.
That control requirement shapes who administers the platform. Institution staff should own the identity and access decisions, including which school officials may see which records, and the partner should work under documented procedures and named accounts that the institution can audit. Under 34 CFR 99.31(a)(1)(ii), the institution must use reasonable access controls so that officials see only the records tied to their legitimate educational interest, which means group and folder permissions must be designed, not left to default sharing. Ask any implementation partner how administrator rights are split, how privileged sessions are logged, and whether the institution can run the platform alone after handover.
Which open-source platforms fit campus file sharing
Campus file sharing usually comes down to one file platform and one office editing layer, chosen against user counts, support expectations and the office suite staff already use. The cards below compare the candidates on the decisions that matter most for universities and schools, and they name what to confirm with each vendor before a shortlist is set.
Nextcloud Server as the file platform
Nextcloud Server is licensed under AGPL-3.0 and is the broadest option for campuses that want sync clients, external sharing, directory login and app-based extensions on infrastructure the institution controls. The community edition carries the feature set, while Nextcloud Enterprise is sold alongside it for enterprise, public sector and education users. Check which features your campus needs in each edition, and plan upgrades carefully because Nextcloud does not allow skipping major releases.
Nextcloud Enterprise support tiers
Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum, so the tier decision is a campus-size question as well as a support question. Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years and clustered instance support, and Ultimate adds support up to 24/7. Ask each vendor which tier covers your student count, your term-start peak and your maintenance window, and confirm whether clustering is in scope for your topology.
Seafile for sync-heavy storage
Seafile server is released under GPLv2 with an additional permission to link with OpenSSL, and it is built around library-based sync and file storage. It suits campuses whose main need is reliable large-file sync for research groups and departments, with fewer collaboration apps to manage. Compare its admin tooling, directory integration, LMS connectors and sharing controls against your list, because the surrounding ecosystem is narrower than Nextcloud's and the choice affects what your team will build or buy around it.
ONLYOFFICE Docs for Office fidelity
ONLYOFFICE Docs is a browser-based office suite for documents, spreadsheets, presentations, forms and PDF, compatible with Office Open XML formats and licensed under AGPL-3.0. Campuses with heavy Word, Excel and PowerPoint use, or with coursework that depends on exact layout, usually find it the closer match. Test complex spreadsheets, tracked changes and macro-free templates with your staff and faculty before committing, and confirm the document server sizing for concurrent editing during peak periods.
Collabora Online for lighter editing
Collabora Online source code is licensed under the Mozilla Public License 2.0, which many campus IT teams find easier to reason about when they bundle components. It is a good match where the office standard is LibreOffice or OpenDocument-heavy, and where students mostly need to edit and comment rather than produce complex layouts. Confirm the Office format fidelity your faculty depend on, the supported Nextcloud integration path, and whether the support level you need is available from the vendor or a partner.
Matching the stack to campus size
Small colleges and single schools can often run one Nextcloud instance with an office editor and a directory connection, while large universities usually need clustered servers, separate environments for test and production, and a tested upgrade calendar. Map your peak concurrent users at term start, the number of departments that need their own quotas, and who on staff will run upgrades. Ask partners to size the stack for both the steady state and the onboarding peak in writing.
How deployment differs for a single campus, a district and a shared consortium
A single university with a central IT team usually runs one Nextcloud instance for the whole institution, with one directory, one set of storage policies and one change calendar. The main design work is connecting that instance to the existing campus identity provider and campus storage without creating a second source of truth for accounts.
- Identity layering: Plan for the campus directory as the authoritative source, with LDAP or Active Directory users appearing in Nextcloud through the LDAP app, and document whether OpenID Connect or SAML is used for federated login.
- Quota and tenant separation: Use group-based quotas for departments, research groups and students, and decide whether separation is by group folder or by separate instance. One instance keeps administration simple but puts all units under one configuration.
- Upgrade coordination: Nextcloud does not allow skipping major releases, so the team must step through one major version at a time, back up before each upgrade and hold third-party apps until they are confirmed compatible. Schedule this around the academic calendar.
- Administrative rights: Keep a small set of named administrators with separate accounts for daily work, and restrict the server administration role to the central team.
Ask the implementation partner how the campus directory will be mapped to Nextcloud groups and which quota rules will apply to each unit before any user is onboarded.
A school district with many small sites and limited staff usually cannot staff a separate platform team for each school. The design goal is one central platform that schools use with little local administration, so that student accounts, sharing rules and storage limits are set once and enforced everywhere.
- Identity layering: Student and staff accounts should come from the district directory so that accounts are created and removed when enrollment or employment changes. Confirm how account deprovisioning is handled at the end of each school year.
- Quota and tenant separation: Set default quotas by role, and use group folders for each school so that one site's files are not visible to another site. Keep student storage limits conservative and review them with the district's privacy office.
- Upgrade coordination: Few staff means upgrades must be planned as a single district task. Use the published maintenance schedule to plan one major upgrade at a time and assign one person to own the backup and rollback steps.
- Administrative rights: Limit administrative rights to two or three district staff. Site staff should hold only group-level management roles, not server or user-creation rights across the district.
Ask the partner how a small team will be trained, what runbooks will be handed over and how an administrator leaving the district will be covered.
A consortium or state system sharing one platform across member institutions combines several legal entities, possibly several FERPA-covered institutions, on one installation. The central team operates the platform, but each member keeps control over its own users, data and retention. Governance agreements matter as much as technical design.
- Identity layering: Each member should keep its own directory, connected to the shared platform through federated login. Decide which member is the identity provider of record for shared accounts, and document how a user from one member can be granted access to another member's files.
- Quota and tenant separation: Give each member its own tenant boundary, using separate group folders, storage quotas and sharing policies. Confirm that one member's files, search results and audit records cannot be seen by another member's administrators.
- Upgrade coordination: A single upgrade affects every member, so the consortium needs a shared change calendar, a test instance and a written process for members that need to delay an upgrade for their own academic calendar.
- Administrative rights: Define a central platform operator role, separate member administrator roles for each institution, and a written rule for who may grant platform-wide rights. Audit these roles on a regular schedule.
Ask the partner how tenant boundaries will be tested, how member data will be exported when a school leaves and how the consortium agreement assigns responsibility for FERPA requests.
How a campus file sharing rollout is phased
The sequence moves from records and identity decisions to a small pilot, then to staged onboarding and integrations, so each wave of students and staff joins a platform whose access, quotas and retention rules are already settled. Each phase ends with a written output the university can review before the next one starts.
Inventory requirements and education records
Start by listing the existing campus storage, departmental file shares, LMS file areas and any cloud drives in use, along with who uses each one and what kinds of records they hold. Identify which data counts as education records under FERPA and which data is protected by other rules, such as GLBA obligations for financial aid data or COPPA where users under 13 are involved. The output is a requirements register that names the data classes, user populations, expected peaks and the owner who signs off on each rule. The step is complete when the registry has been reviewed by the registrar, the privacy office and campus IT.
Design identity and group structure
Map the directory sources that will authenticate users, such as Active Directory or LDAP, and decide whether federated login through SAML or OpenID Connect is the primary path. Define groups that mirror enrollment, faculty, staff and department membership, because these groups drive quotas, sharing permissions and access to restricted folders. The output is a documented identity model showing which attributes come from which source, how guest and alumni accounts are handled, and how a departing user loses access. Confirm the design with the identity team before any configuration is built.
Run a pilot with a small cohort
Select a limited group of users from a few departments that represent different roles, such as a research lab, an administrative office and a course team. Test sign-in through the chosen identity path, sync client behavior on managed and personal devices, sharing to external collaborators and restore from versions and trash. Collect issues in a log and record the decisions taken on each one. The pilot is complete when the open issues are classified as fixed, accepted or deferred, and the support team has written answers to the questions the pilot users asked.
Set quota and retention policies
Using the pilot data, define default and group-based storage quotas, file version and trash retention periods, and rules for deleting accounts and their content. Where COPPA applies, document the retention and deletion timeframe for children's personal information. Ask the records office to confirm which retention rules must align with institutional schedules. The output is an approved policy document and matching configuration, with a test showing that quotas and deletion behave as written.
Onboard users in planned waves
Divide the remaining population into onboarding waves and schedule each one away from registration, term start and grade release, when sign-in demand is highest. Each wave is preceded by a readiness check of capacity, identity mappings and help desk materials. Staff and faculty usually move first so that course content is available before students arrive. The output for each wave is a sign-off record showing the number of accounts activated, the sign-in results and any incidents. Specific dates depend on the agreed scope and the academic calendar, so confirm them with the registrar and the service desk.
Integrate with the LMS and campus storage
Connect the file platform to the learning management system so course files can be attached or linked, and mount existing campus storage as external storage where content must stay in place for now. Confirm that LMS integration uses the same identity source and that permissions on mounted storage match the source system. Test a course lifecycle from creation to archive, including a file added by an instructor and a student submission. The output is a tested integration with a list of supported workflows and known limits, which the LMS administrator must confirm in writing.
Hand over with an upgrade calendar
Deliver runbooks for backup and restore, monitoring, user support, incident response and account lifecycle, and train the operations team on each. Set an upgrade calendar that follows the vendor's major release cadence and the rule that major versions are upgraded one at a time, with a backup before each change and third-party apps checked for compatibility. Document the support tier and who is responsible for patching. The handover is complete when the operations team runs a restore test from the runbook without assistance and signs the calendar.
What an auditor or records office will ask to see
This table lists the evidence a campus auditor, records office or federal program reviewer is likely to request for a self-hosted file sharing service, the component that produces each item and what to confirm before the request arrives. Your compliance team decides which items satisfy its auditors, so treat the right-hand column as a list of questions to settle early rather than a checklist of passed controls.
| Evidence item | Produced by | What to confirm with compliance |
|---|---|---|
| FERPA disclosure log for access and disclosures | Nextcloud audit logging app, plus the institution's records process for logging requests outside the platform | Whether the log captures the parties and legitimate interest that 34 CFR 99.32 requires, and how long entries are kept |
| School official access group configuration | Nextcloud groups and sharing settings, synced from the directory through the LDAP app or an OpenID Connect or SAML backend | Which groups hold legitimate educational interest, and how access is restricted to those records under 34 CFR 99.31(a)(1)(ii) |
| Multi-factor authentication settings | Identity provider configuration and Nextcloud two-factor authentication settings | Whether MFA is enforced for every account that can reach student data, including staff, contractors and administrators |
| Administrator and file activity audit logs | Nextcloud server logs and the audit log application, forwarded to the campus logging system | Retention period, who can read the logs, and whether logs are protected from edits by the administrators they record |
| Retention and deletion policy records | Written policy from the institution, enforced through Nextcloud retention settings, trash bin and version limits | Whether deletion timeframes cover student files, backups and departed-user data, and how deletion is evidenced |
| Contractor data processing terms | Signed agreement with the implementation partner and any hosting or support provider | Whether the contract places the contractor under direct institutional control and restricts redisclosure, as 34 CFR 99.31(a)(1)(i)(B) requires |
| Parent and student access request handling | Records office workflow, with file search and export from Nextcloud as the source data | Whether responses can be produced within the 45-day window in 34 CFR 99.10(b) and who performs the search |
| Upgrade and patch records | Change tickets, Nextcloud release notes, pre-upgrade backup records and maintenance logs kept by the operator | Whether the institution's change process accepts one-major-version-at-a-time upgrades and which release lines it has approved |
| Written information security program and risk assessment | Institution policy documents, with risk assessment outputs from the operator | Whether the program covers the Safeguards Rule elements that apply to the institution's federal aid obligations |
What education buyers ask before hiring a file sharing partner
What drives the cost of self-hosted file sharing for a campus of a given size?
The biggest cost drivers are user count, storage volume, the number of sites or data centers, identity integration complexity and how much support the institution buys. Costs split into one-time items (design, installation, identity integration, migration of existing shares, testing and staff training) and recurring items (storage capacity, servers or cloud hosting, backups, software subscriptions, support and administration time). Storage growth usually dominates the recurring line over time. Ask any partner for a quote built from your user count, expected storage per user, number of environments (production, test, disaster recovery) and the support hours you need, so the proposal can be compared line by line.
How long does an initial file sharing rollout take at a university?
Duration depends mainly on scope and identity complexity, not on the software install itself. A single directory with clean groups and a small pilot moves much faster than a federated or multi-directory setup with legacy campus storage to map. The phases that usually set the calendar are requirements and data classification, identity and single sign-on design, migration of existing shares or cloud drives, pilot with faculty and research groups, and the onboarding wave before the academic term. Scope is agreed in writing before work starts, so ask the partner to show which phases are fixed, which depend on your identity team's availability, and which depend on the vendor's release schedule.
What staff does the institution have to provide for a file sharing project?
The institution must supply decision owners and subject experts, even when a partner does the build. Typically this includes an identity or directory administrator who can approve LDAP or single sign-on changes, a storage or virtualization administrator, a database owner, a privacy or records officer who signs off on data classes and retention, a security contact for vulnerability and incident processes, and a service owner who sets quotas and onboarding rules. Research computing and the LMS team are needed when those systems connect. Ask the partner to list these roles in the statement of work with the hours expected from each, so the project does not stall waiting for people nobody assigned.
Can our internal IT team run a self-hosted Nextcloud campus service alone?
Some teams can, especially those with experience in Linux, PHP-based web applications, database administration and backup restores. The work that tends to strain small teams is recurring: applying Nextcloud's monthly maintenance releases, planning each major upgrade, testing apps before enabling them, watching security advisories, restoring backups on a schedule and supporting users during term-start peaks. A common model is for the institution to keep day-to-day administration in house and buy retainer support for upgrades, testing and out-of-hours response. Ask any partner to separate build, run and support responsibilities in writing, and to state who holds the admin credentials and the backup keys at the end of the engagement.
How do one-major-version-at-a-time upgrades affect the academic calendar?
Nextcloud does not allow skipping major releases, so an upgrade path must move through each major version in order, with a backup before every step and third-party apps disabled until confirmed compatible. The supported windows are published: Nextcloud 35 was released on 16 September 2026 with end of life in September 2027, and Nextcloud 36 is scheduled for 17 February 2027. Plan upgrades outside enrollment, exam and grading periods, and budget test time in a staging copy for each step. Ask the partner how many major steps lie between your current version and the target, and which windows they propose to avoid the term-start peak.
What does Nextcloud Enterprise cost per user for a campus?
Nextcloud's published list prices start at 71.29 euros per user per year for the Standard tier, 104.99 euros for Premium and 204.75 euros for Ultimate, for 100 or more users, according to Nextcloud's pricing page. Standard includes one year of maintenance, Premium adds a lifecycle of five or more years, extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. The subscription has a 100-user minimum, and lower rates apply from 200 users. Discounts for education and volume are negotiated, so treat list prices as a starting point and request a written quote for your headcount, tier and term.
Does the community edition or the Enterprise edition fit a university better?
The community edition is free software under AGPL-3.0 and suits teams that can handle their own support and testing. Enterprise adds a paid support contract, maintenance lifecycles and clustering support, which matter when a campus needs response commitments and longer security windows before a major upgrade is forced. Nextcloud GmbH positions Enterprise for enterprise, public sector and education users. Decide based on the support model you need, the number of users and whether leadership expects a contracted service level, then confirm the entitlements and response times against the vendor's current terms before purchase.
Which FERPA duties should the file sharing design answer before go-live?
FERPA applies to educational institutions that receive funds from programs run by the US Secretary of Education, and it governs how personally identifiable information from student education records is disclosed. Three design questions come first: whether a hosting partner qualifies as a school official under the institution's direct control, whether access is limited to staff with a legitimate educational interest through technical access controls, and whether the institution can log each disclosure and keep that record for as long as the records are kept. The regulation text is at 34 CFR Part 99. Ask the partner to show how these controls map to your access model and audit logs, and confirm the answers with your registrar and counsel.
Questions to ask an implementation partner for a university
Start with the legal role. Ask the partner to state in writing how it acts as a school official under 34 CFR 99.31(a)(1)(i)(B): which services it performs that the institution would otherwise staff internally, how the institution keeps direct control over the use and maintenance of education records, and how the partner's own staff are bound by the redisclosure limits in 99.33(a). Ask who at the university can suspend the partner's administrative access and how quickly that change takes effect. A partner that cannot answer these questions in writing has not thought through the engagement as a FERPA matter. Next, ask how access is limited to the right school officials. Request the group-to-folder mapping, the rule set that enforces it (group folders, sharing restrictions, and any access control rules by group), and a test plan that shows a registrar's staff member cannot open a faculty or advising folder. Ask how the partner produces the disclosure record that 34 CFR 99.32 requires for each request and disclosure of personally identifiable information, and which fields that record carries, such as the party, the date and the legitimate interest. Confirm whether the audit log is retained for as long as the records it covers are kept, and whether it can be exported for a records request.
Ask how the platform is sized for seasonal peaks, such as enrollment week or course registration. The partner should show its assumptions for concurrent sync clients, login bursts, storage growth per term and database connections, and explain how capacity is added without a full rebuild. Request a load test against those assumptions, run in your environment, and ask what is pre-provisioned versus scaled on demand. Require a written list of what you must supply, such as storage, identity provider capacity and network bandwidth, and what the partner will test before each peak. Finally, test the identity path before go-live. Ask the partner to demonstrate LDAP or Active Directory bind, federated login through your SAML or OpenID Connect provider, and the fallback when the identity provider is down, using test accounts that mirror student, staff and guest populations. Ask how upgrades are scheduled: Nextcloud requires one major version at a time with a backup before each step and third-party apps disabled until confirmed, so ask for the upgrade calendar relative to the current Nextcloud release train and who signs off. Ask which support tier is included, the response times, the hours covered and whether the maintenance lifecycle matches your planned major versions, then confirm each point in the written scope.
How DeployOpen scopes and supports campus file sharing
This sequence turns a campus file sharing idea into a written, fixed-scope plan that the institution's own staff and assessors can verify. It covers who does the work, where it runs, and what evidence is handed over at each stage.
Confirm the institution's scope and records obligations
DeployOpen starts by mapping which user groups, departments and data classes the platform will serve, including students, staff, researchers and alumni, and which records fall under FERPA, GLBA or local policy. The institution's privacy office and registrar confirm the obligations, and DeployOpen records them in a scope document. The step closes when the institution signs off on that scope in writing, which becomes the basis for every later deliverable.
Assess existing campus storage and identity
DeployOpen inventories the current network shares, learning management system file areas, cloud drives used by staff and the directory that holds student and employee accounts. The team documents which sources will be mounted as external storage, which will be migrated, and which will stay where they are. The output is a written inventory with owners named by the institution, and the step is complete when those owners have confirmed it.
Design the architecture in the institution's infrastructure
DeployOpen drafts the deployment inside the institution's data center or cloud accounts, covering the application servers, database, caching, object or file storage, backup targets, and the directory and single sign-on connections. The design also records how federated login is handled and how storage quotas are set by user group. The design document is reviewed with the institution's infrastructure team, and the step closes when they approve the design and the supported software versions.
Implement, integrate and harden the platform
DeployOpen installs the chosen Nextcloud edition, connects directory and single sign-on, configures storage quotas, sharing rules and audit logging, and integrates the LMS and existing storage where they were agreed. The team applies hardening settings and tests access controls for each group. The step is complete when test results for each agreed control are delivered and the institution's administrators have run the same checks.
Set up backup, restore and upgrade procedures
DeployOpen configures backups for the database and file data, tests a restore to a separate environment, and writes the procedure for upgrades, which must move one major version at a time with a backup taken before each upgrade. The team also records how third-party apps are checked before an upgrade. The step closes when a restore test has been witnessed by the institution and the runbook has been handed over.
Prepare compliance evidence for institutional assessors
DeployOpen compiles the configuration records, access control settings, audit log samples, retention and deletion procedures, and the written information security documentation that the institution's auditors or compliance staff need. The package maps each control to the requirement it supports, but DeployOpen does not issue audit reports, attestations or certifications. The step is complete when the institution's compliance lead confirms the evidence set is sufficient for its own assessment.
Train administrators and hand over operations
DeployOpen runs administrator and help desk training on user provisioning, quota changes, sharing controls, log review and the incident steps agreed in the runbook. The team delivers the final documentation set and a list of open items. The step closes when the institution's staff complete the training and the handover checklist is signed by both parties.
Agree ongoing support as a retainer
After handover, the institution can choose a retainer for upgrades, monitoring, security testing and support hours, which is priced from a separate written scope. Retainers cover routine maintenance and the planned upgrade path, so the campus does not have to schedule each release itself. The step is complete when the retainer scope and service levels are agreed in writing, or when the institution decides to operate the platform alone with the handed-over documentation.
