Why a course platform for EU data sovereignty changes the build
An organization selling courses to EU learners that wants to stop routing learner records through US course marketplaces usually ends up with a self-hosted Open edX or Moodle platform on EU-controlled hosting. The decisive work is not course authoring, which both platforms handle well out of the box. It sits in hosting, identity, payments and analytics, because each of those can quietly move personal data to a third country. The scenario is defined by transfer rules rather than by features, so the platform choice matters less than where every component runs and who can reach it.
Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. The EDPB Guidelines 05/2021 treat remote access from a third country, even just displaying data on a screen for support, as a transfer, and so storage in a cloud outside the EEA. That means the support vendor, the managed backup provider, the video host, the email relay and the analytics tool all need to be mapped, not only the primary database. Ask each provider where administrators log in from and where backups and logs are stored, and record the answers before choosing a hosting arrangement.
Short answer on platforms: Open edX suits learner experiences built around courses, cohorts and paid programs, and Moodle suits organizations that need broad plugin coverage and a familiar admin model. Both are licensed for self-hosting. Confirm the hosting provider's own legal exposure before signing, because the EDPB notes that complying with a third-country authority request would itself be a transfer. Confirm the current status of the EU-US Data Privacy Framework with counsel, since its appeal is pending as Case C-703/25 P, and do not assume it will remain available as a transfer basis.
Which GDPR transfer, accessibility and portability rules shape the course platform
This table maps each legal requirement that bears on a self-hosted course platform to what it means for hosting location, support access, vendor selection and contracts. Read each row as a question to answer before choosing a host, an identity provider or a payment or analytics vendor. The main takeaway is that where the platform runs and who can reach the data matter as much as where the data is stored.
| Requirement | What it means for the course platform | What to confirm or ask for |
|---|---|---|
| GDPR Article 44 and Article 83(5)(c) fines | Every transfer of learner personal data to a third country, including onward transfers, must meet Chapter V conditions. Infringements of Articles 44 to 49 can reach EUR 20 million or 4% of worldwide annual turnover. | Map every sub-processor, backup location and support location for the learner database, video and analytics before launch. |
| EDPB Guidelines 05/2021 on remote access and cloud storage | Remote access from a third country, even only displaying data for support, and storage in a cloud outside the EEA both count as transfers. Support engineers abroad are therefore in scope. | Ask the implementation partner where administrators sit, how remote sessions are logged, and whether access is limited to EEA staff. |
| Schrems II and the Data Privacy Framework (Case C-703/25 P pending) | Standard contractual clauses remained valid after Schrems II, but the Data Privacy Framework adequacy finding applies only to US organizations on the DPF List and its appeal is pending. A US-controlled vendor relying on DPF may need a fallback transfer tool. | Ask counsel whether the chosen vendor is on the DPF List and whether a standard contractual clauses fallback is in the contract. |
| EDPB Recommendations 01/2020 on supplementary measures | Where a provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB states it cannot envision an effective technical supplementary measure. Encryption alone does not solve a US-controlled host with clear-text access. | Document the transfer assessment and ask whether the host can run without clear-text access by any third-country party. |
| CLOUD Act reach under 18 U.S.C. 2713 | US providers must preserve or disclose data in their possession, custody or control whether it sits inside or outside the United States. A US parent company can therefore reach EU-hosted learner data. | Ask every vendor in the stack for its parent company, its legal-process policy and whether customer-managed keys are held in the EU. |
| GDPR Article 48 on third-country orders | A third-country court judgment or administrative decision demanding disclosure is recognized or enforceable only if it rests on an international agreement, such as a mutual legal assistance treaty. Requests outside such agreements remain a risk to assess. | Include in the contract a commitment to notify the controller and to challenge requests that lack an international agreement basis. |
| Data Act Article 32 and non-personal data | Providers of data processing services must take measures to prevent third-country governmental access to non-personal data held in the Union where this would conflict with Union or national law. This covers course analytics aggregates, course content and operational logs that are not personal data. | Ask hosting providers for their Article 32 measures in writing and for the locations of non-personal operational data. |
| Data Act switching rights (Articles 25, 29 and 50) | Customers may switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027, so exit terms in hosting and SaaS contracts should not impose them. | Write exit assistance, data export formats and transition timing into the contract, and confirm how the Data Act applies to your provider. |
| European Accessibility Act scope for e-commerce and e-books | No supplied fact confirms how the European Accessibility Act applies to course sales pages, checkout and e-book materials sold with courses. Accessibility duties for the learner interface should be scoped with counsel before the build is priced. | Ask counsel whether the course storefront and digital course materials fall within scope and which accessibility standard the contract must reference. |
Which learner, payment and analytics data leaves the platform
The first decision is to map every data flow in the course business, because sovereignty is decided per flow, not per platform. Learner accounts and enrolments are created in the LMS (Open edX LMS or Moodle core) and stored in the database on your own infrastructure. Progress and assessment records are written by the same platform, so they stay in EU hosting as long as the database, backups and logs do too. Payment and invoice data is different: it is created at checkout by a payment provider or a storefront plugin, and the provider keeps its own copy. Video hosting and analytics events are the two flows most often missed, because a video CDN receives requests from every learner's browser and an analytics script can send events to a SaaS endpoint without anyone changing the platform code. For each flow, write down four things: where the record is created, where it is stored, which processors hold a copy, and which parties can see it during remote support. The EDPB guidelines treat remote access from a third country, even only displaying data on a screen, as a transfer under GDPR Chapter V, so a support contractor or vendor engineer outside the EEA with access to the admin console is part of the map. Ask your implementation partner and each vendor to confirm in writing where support sessions run and whether any support tool sends data outside the EEA. The practical check is to list every third-party script, plugin and endpoint on the course site and the checkout page, then block or remove any that send learner identifiers to a non-EEA host. Use browser developer tools on a test enrolment to confirm the requests. Treat any analytics or session tool that is not self-hosted as a separate decision with its own record of processing, and confirm with your legal team whether the provider's contract and transfer tools fit the data it receives.
Which open-source platform fits EU-only learner data
The course engine sets the release obligations, identity options and hosting footprint you will carry for years. Each card below covers one decision that affects where learner records sit and who can reach them. Check each option against your own data map before you choose.
Open edX as the course engine
Open edX is licensed under AGPL-3.0 and runs on Python and Django, with Studio for authoring and the LMS for learners. Its supported model is narrow: only the latest named release receives support, and Verawood, published on July 30, 2026, is the current one. Plan an upgrade path to Willow and Xylon as they arrive, and confirm who in your team or partner team owns that cycle.
Moodle as the course engine
Moodle is licensed under GPL-3.0 and is maintained by Moodle HQ, so you can self-host it entirely inside EU infrastructure. Moodle 5.3 is the next long-term support release, with security fixes until October 1, 2029, which gives a longer patching window than a rolling named release. Confirm the database and PHP versions your hosting provider supports before you select a platform build.
Canvas LMS as the course engine
Canvas LMS by Instructure is licensed under AGPL-3.0, the same family as Open edX, so the copyleft obligations on modified network-served code are similar. The decision here is less about the licence and more about support: confirm who provides security patches, upgrade tooling and EU-hosted operations for the open-source build. Ask for the upgrade cadence in writing before you commit to it.
Identity options that keep accounts in-house
Moodle core ships LDAP, Shibboleth, OAuth 2 and LTI authentication, so learner logins can authenticate against a directory in your EU data center. Open edX supports SAML 2.0, Shibboleth, LTI and OAuth2 providers, with CAS and SSL client certificates only as older provisional support. Map each learner population to one provider, and confirm that the identity provider itself is hosted in the EU.
Storefront and payments as an integration decision
Course sales need a storefront, and WooCommerce or Moodle enrolment on payment are the usual options to evaluate. Neither choice keeps payment data in the EU by default, so confirm the payment provider's data residency and whether it processes card data from outside the EEA. Every personal data flow that leaves the EU must be listed and assessed under the GDPR transfer rules before go-live.
Learner analytics kept in the EU
Open edX Aspects captures tracking logs as xAPI statements, stores them in ClickHouse, and displays them in Superset, so the whole analytics chain can run on your servers. Moodle analytics depend on the reporting and logging you enable and on any external tools you connect. Decide where each log type is stored, how long it is retained, and which vendor tags or scripts are allowed to load in learner browsers.
How hosting and operations pattern changes with the sovereignty constraint
In this model, the organization holds the cloud account and deploys Open edX, Moodle or the commerce and marketing stack into EU regions it selects. The provider runs the physical infrastructure, but the organization controls the tenancy, the keys and the configuration. The sovereignty question shifts from where servers stand to who can reach the account and the data from outside the EEA.
- Administrative access: Confirm which provider staff can reach the control plane, whether that access is logged, and whether any administrative path runs through a non-EU support team.
- Support access: Ask whether support engineers from third countries can view data on screen, since the EDPB treats remote display as a transfer.
- Backups and logs: Specify the storage region for snapshots, object storage replicas and centralized logs, including disaster recovery copies.
- Keys: Decide who holds encryption keys and whether they can be held in an EU key store that the organization administers.
- Switching: Keep infrastructure as code and container images in the organization's own repositories so the deployment can move to another provider or on-premises under the Data Act.
Before signing, ask the provider for its jurisdiction, its parent company's legal exposure to third-country authorities and a written list of sub-processor locations.
Self-hosting in the organization's own data center removes the third-party hosting provider from the chain. The organization owns the hardware, the network and the operating staff, so the transfer analysis is simpler. The trade-off is that the organization carries the operational burden of patching, capacity, failover and recovery that a cloud provider would otherwise share.
- Administrative access: Limit privileged access to named internal staff, and confirm that any vendor remote session is time-limited, recorded and performed from inside the EEA.
- Support access: Written support contracts with an implementation partner should state where support engineers connect from and whether they can see learner records.
- Backups and logs: Keep backup copies in a second EU site under the organization's control, and send logs to an internal store rather than a hosted log service outside the EEA.
- Operations: Plan for database and cache maintenance, Moodle or Open edX version upgrades, and security patching on a fixed schedule.
- Switching: Because the deployment already runs on the organization's hardware, the Data Act's on-premises switching right is the natural fallback, but the organization still needs documented exports of course content, enrolments and completion data.
When the platform leans on vendor-managed licenses or appliances, ask the vendor to confirm where any telemetry or license checks are sent.
A managed EU partner hosts and operates the platform on the organization's behalf, usually inside an EU cloud or data center the partner selects. This model shifts day-to-day operations to the partner, which can be attractive for teams without a platform operations function. Sovereignty depends on the partner's own ownership, staffing and sub-processor chain, which need to be verified rather than assumed.
- Administrative access: Ask which partner staff hold root or database access, where they are located and whether the organization can revoke access and review session logs.
- Sub-processors: Request the full chain, including the cloud provider, email delivery, video hosting, payment and analytics services, each with its location.
- Backups and logs: Confirm backup and log locations in the contract, the retention period and whether the organization receives a copy it can restore elsewhere.
- Exit terms: Write the switching process into the contract, including export formats, a two-month notice period and a 30-day transition, consistent with the Data Act's switching rules.
- Charges: Ask whether switching charges apply, noting that the Data Act bans them from 12 January 2027.
Ask the partner for written confirmation of provider jurisdiction and sub-processor locations, and check whether any of its own upstream providers are subject to third-country access requests.
How to roll out a sovereign course platform in phases
The sequence moves from legal scoping to a tested, operated platform, with each phase ending in a named artifact that counsel, security and the course team can sign off before the next phase starts. The order matters because the data map decides the hosting, and the hosting decides which identity, payment and analytics tools can sit inside the boundary.
Map jurisdiction and personal data with counsel
Counsel and the data protection lead list every personal data flow the course business creates: enrollment, payment, certificates, video views, support tickets and marketing consent. For each flow, they record where the data is stored, which processors touch it, and whether any administrator, vendor or support engineer outside the EEA can view it. The output is a data map and a jurisdiction register that names every processor and sub-processor. The step is done when counsel signs the register and every row has a hosting location and an access location.
Assess transfers and processor exposure
Using the data map, counsel and the security lead document each third-country transfer, including remote access for support, backups held outside the EEA and onward transfers by subprocessors. For any EU processor that is subject to non-EU law with extraterritorial reach, they assess how it would respond to a foreign authority request before signing. The output is a transfer assessment and a list of contract clauses to request. The step closes when every transfer either has a documented legal basis or is removed from the design.
Choose the platform and EU hosting
The team selects Open edX or Moodle based on course model, authoring needs and operating capacity, then selects a hosting provider and region that the transfer assessment accepts. Open edX is typically run through Tutor or a service provider, while Moodle has its own supported database and PHP versions that must be fixed in the design. The output is an architecture decision record and a hosting bill of materials covering compute, database, object storage, cache and backups, all located in the agreed region. The step is done when the record lists the exit path for data and the upgrade policy.
Integrate identity and payments inside the boundary
The implementation partner configures sign-in through the organization's own identity provider, using the protocols the chosen platform supports, and checks that authentication logs and session data stay in the EU. Payment providers are selected and connected so that card data is handled by a tokenizing provider and the platform receives only order and payment status. Each integration is tested for data flow, not just success. The output is a configured tenant with a list of every external call the platform makes. The step is done when a test learner can register, pay and sign in with no unlisted outbound connection.
Configure analytics and set retention
The team decides which learner events are collected, such as progress, quiz results and video engagement, and states why each one is needed. Analytics stores and dashboards are placed on EU infrastructure, and no third-party tracking script is loaded without a documented basis and consent where required. The data protection lead sets retention periods for each event type and configures deletion or anonymization jobs. The output is a signed retention schedule and a tested deletion run. The step closes when the team can show that expired records are removed from the analytics store and backups.
Test accessibility against the applicable standard
Before launch, an accessibility specialist tests the learner journey, storefront, checkout, course player and certificate pages against the standard that applies to the organization and its product. Testing combines automated scans with manual checks using screen readers and keyboard-only navigation, and covers themes and custom plugins as well as core. Findings are logged by page and by severity, and the owner fixes and retests. The output is an accessibility report with a remediation log. The step is done when the report is signed and open issues have owners and dates. Confirm the applicable requirements with counsel, since the European Accessibility Act duties for e-commerce and e-books are a separate question from the platform's technical conformance.
Rehearse the migration and launch
The team runs a full launch rehearsal in a staging copy of the production environment, including a sample migration of any existing learners, courses and certificates. They load-test the expected enrollment spike, check backup restoration into the same EU region, and walk through the incident and access-request procedures with the operations staff. Defects found in the rehearsal are fixed and retested before the go-live date is set. The output is a rehearsal log, a tested restore record and a go/no-go checklist. The step closes when the go/no-go checklist is signed by the business owner, security and counsel.
Hand over to operations with evidence
The implementation partner transfers the platform to the operating team, or to an ongoing support provider, with a runbook covering upgrades, patching, backup and restore, access control and the processor register. Operators are trained on the procedures for handling access requests and data deletion, and on the process for reviewing each named release before adopting it. The output is a handover pack containing the data map, transfer assessment, configuration record, retention schedule, accessibility report and rehearsal log. The step is done when the operating team has run one routine change through the runbook without help.
What evidence auditors and regulators ask for on a course platform
This table lists the records a data protection authority or auditor is likely to request for an EU-hosted course platform, and the platform component that produces each one. Use it to see where evidence has to be designed in from the start, since logs and records that were never configured usually cannot be recreated later. DeployOpen prepares these artifacts for assessment but does not issue audit reports or certifications.
| Evidence item | Platform component that produces it | What the assessor checks |
|---|---|---|
| Records of processing | Data map covering the LMS, storefront, payment and analytics services, maintained by the controller with DeployOpen | Every learner data category, purpose, recipient and storage location is listed and matches the running system |
| Transfer impact assessments | Hosting and processor inventory, plus a documented review of third-country law exposure for each processor | Whether any remote access, backup copy or support session reaches a third country, and how the assessment was reasoned |
| Processor contracts and sub-processor lists | Contract register for hosting, email, video, payment and analytics vendors | Current sub-processor list, notice of changes and the location of each sub-processor |
| Administrative and remote support access logs | Operating system and database audit logs, VPN or bastion session records, and Moodle or Open edX admin event logs | Who accessed the platform from where, when, and whether support sessions were approved and recorded |
| Key management records | Key management service or hardware security module, with rotation and access policies for database, backup and TLS keys | Who holds keys, where they are stored, and whether the EU operator can decrypt data without a third party |
| Backup and disaster recovery locations | Backup tooling and storage target configuration, with restore test logs | Every copy, replica and snapshot is in an approved location and restores have been tested |
| Accessibility conformance records | Accessibility test reports for the storefront, course player and e-book outputs, plus remediation tickets | Coverage against the European Accessibility Act duties for e-commerce and e-books, and evidence that defects were tracked to closure |
| Data subject request and retention records | LMS and storefront deletion or export procedures, and retention schedules for enrolment, certificate and payment records | Requests were handled within the required timeframes and records are deleted or retained on a documented schedule |
What buyers ask before hiring help for an EU sovereign course platform
What drives the cost of an EU sovereign course platform project?
Scope drives cost more than any single product choice. The main components are discovery and data mapping, hosting in the organization's own EU cloud account or data center, installation and configuration of Open edX or Moodle, payment and tax setup, theming, integrations with identity and analytics, testing, and handover. Some of this is one-time work, while hosting, backups, security patching, and upgrades recur every year. Costs rise with the number of sales channels, languages, identity sources, and video volume. DeployOpen does not publish a price list, so ask for a quote built from a written scope that lists each component, who pays for it, and which items recur.
How long does it take to launch a sovereign course platform?
The timeline depends on the agreed scope. DeployOpen works through fixed-scope engagements where scope, deliverables, and timelines are agreed in writing before work starts, so ask for a dated plan tied to specific deliverables. The biggest variables are how quickly the organization supplies its data map, legal sign-off on transfers, and identity source details, and how many integrations and payment providers are in scope. Ask the partner which milestones depend on your inputs and which depend on their own work.
Can our own team operate the platform after launch?
Yes, if the team is given the runbooks, configuration records, and skills to do so, and if the staffing model is agreed up front. Open edX and Moodle both need regular patching, backups, database maintenance, and upgrades to named releases, and Open edX supports only its latest named release. Ask whether the handover includes documentation and training, whether a support retainer covers upgrades and continuous testing, and who is on call for incidents. Confirm the internal skills you already have in Linux, Docker or Kubernetes, PostgreSQL or MySQL, and identity administration before you commit.
Can we use US-based SaaS course tools with EU learner data?
Using US-based SaaS tools is possible, but each one that receives learner personal data is a transfer under GDPR Chapter V and needs its own assessment. EDPB Guidelines 05/2021 treat remote access from a third country and storage in a cloud outside the EEA as transfers. The US CLOUD Act can also require US providers to disclose data in their control regardless of location, and GDPR Article 48 limits how foreign disclosure orders are enforced. Ask legal counsel to review each vendor, and ask the partner to list which tools are self-hosted in the EU and which would be exceptions.
What does our organization need to provide before work starts?
Three inputs are needed early: a data map that lists every personal data flow from enrollment, payment, video, analytics, and support tools, legal input on lawful basis, retention, and any transfer decisions, and the identity source details, such as an existing directory, SAML 2.0 identity provider, or OAuth2 provider. Also provide the EU hosting account or data center access, named business owners for courses and payments, and a decision on who signs off accessibility conformance. Ask the partner to produce a written input list with owners and due dates.
Is Open edX or Moodle easier to keep inside EU hosting?
Neither is inherently easier, because both can run entirely in EU infrastructure. Moodle is GPL-3.0 with a long history of self-hosting, and its 5.3 release lists PostgreSQL 17, MySQL 8.4, or MariaDB 11.4 among supported databases with PHP 8.3 or later. Open edX is AGPL-3.0, its maintainers recommend production use through a service provider or Tutor, and its analytics stack (Aspects) adds ClickHouse and Superset components to host. Choose based on whether you need a marketplace-style sales flow, Moodle's core PayPal enrollment, or Open edX's authoring and micro-frontend model. Confirm each component's data location in the design.
How do we move the platform later under Data Act switching rights?
The EU Data Act gives customers the right to switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Because the platform runs on open-source code in your own accounts, the main migration work is exporting course content, learner records, certificates, and configuration, then validating the target. Ask the partner to document export paths for each component and to test a restore. Confirm your contract terms with counsel, since the Data Act rules apply to the service provider relationship.
Questions to ask an implementation partner about EU hosting
Start by asking the partner to map every component to a named location: the LMS, Studio or the Moodle web root, the database, the cache, object storage for video and uploads, backups, logs and the mail relay. Ask for the country and cloud region of each, and for the legal entity that operates the account. For an Open edX deployment, the list should cover the LMS, Studio, the MySQL and MongoDB stores, Memcached or Redis, and the analytics path if Aspects is in scope. For Moodle, it should cover the PHP application, PostgreSQL or MySQL, the file store and the cron host. A partner who answers with a single region for the whole stack has not done the mapping. Ask for the diagram in writing and keep it as part of the contract.
Then ask who holds administrative and support access, from which countries, and through which accounts. The EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer, so an engineer working from outside the EEA during an incident is part of your transfer analysis. Ask whether support sessions are recorded, how a session is approved before it starts, who can revoke it, and how the partner logs each action taken on production data. Ask for a sample of the access log and the approval record for a past incident, with personal data removed. Confirm the answers with your data protection officer before signing, because they determine whether the hosting is actually EU-only in operation.
Ask for the full list of sub-processors, including managed database, backup, monitoring, email and video providers, and the country where each one stores or accesses data. Ask whether any of them is a US-headquartered company subject to the CLOUD Act, which applies to providers regardless of where data is stored under 18 U.S.C. 2713. Ask how the partner handles a third-country authority request: whether it commits to challenge the request, notify you where the law allows, and provide only the minimum data. Under GDPR Article 48, such an order is enforceable in the EU only if it rests on an international agreement, and that point belongs in your contract language. Ask also how payment and analytics are kept inside the boundary, since a checkout or tag manager that sends data to a US endpoint undoes the hosting decision.
How DeployOpen scopes and supports an EU sovereign course platform
The sequence moves from a written scope to a platform built inside your own infrastructure, with compliance evidence prepared for independent assessors and ongoing support agreed through a retainer. DeployOpen delivers the controls and records, while attestations and certifications come from independent bodies.
Agree the written scope and data map
Before any build work starts, DeployOpen and your team agree the scope in writing: which platform (Open edX, Moodle or another option you have chosen), which learner data flows exist, which sales, payment and analytics services are in or out, and which EU hosting location and cloud account, data center or air-gapped network will run it. Your team should expect the scope to name every third-country touchpoint, including remote support access and any backup or monitoring service. The output is a signed scope document and a data flow inventory that the rest of the engagement is measured against.
Confirm the platform and supplier chain
Using the agreed scope, DeployOpen checks each open-source component against your requirements, including licence terms, the supported release line and the hosting and database versions the release requires. For each vendor or sub-processor that could reach learner data, your legal and privacy team should review jurisdiction, contract terms and any third-country law that could compel disclosure, reflecting the EDPB position that such exposure must be assessed before engagement. The output is a supplier register and a short written decision record for each platform choice.
Deploy inside your EU infrastructure
DeployOpen installs the chosen platform inside your own cloud account, data center or air-gapped network, with storage, backups, logs and administrative access kept within the agreed EU location. Installation follows the platform maintainers' production guidance, so for Open edX this typically means a service-provider or Tutor-based deployment rather than a bare-metal build, and for Moodle it means a web root that points to the /public directory. The output is a running staging environment and a documented production environment, both reviewed against the data flow inventory.
Configure identity, payments and analytics in house
DeployOpen connects single sign-on through the identity provider you already run, configures the payment gateway and storefront so card handling and invoice data stay within your agreed scope, and sets up learner analytics on infrastructure you control. Each connection is tested with test accounts and test transactions, and any service that cannot be kept in house is documented as an exception with its transfer basis. The output is a configuration baseline and a test report covering login, enrolment, payment and analytics events.
Prepare accessibility and compliance evidence
DeployOpen collects the evidence that independent assessors and your own compliance function will ask for: records of processing and transfer assessments, access control settings, backup and restore procedures, logging configuration, accessibility test results against the standards your scope names, and the change log for theme and plugin work. DeployOpen prepares and organizes this material, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. The output is an evidence pack indexed to your requirements, with gaps listed for your decision.
Hand over, document and train operators
DeployOpen documents the architecture, runbooks, configuration decisions and the upgrade path, then trains the staff who will operate the platform. The handover includes a test restore from backup and a walkthrough of how the platform moves to the next named or long-term support release. The output is signed acceptance of the handover package against the written scope, with open items recorded in writing.
Run ongoing support and upgrades on a retainer
After handover, ongoing support, security patching, platform upgrades and continuous testing can be covered by a retainer agreed in writing. Your team should confirm which release line is supported at the time, since Open edX supports only its latest named release and Moodle publishes distinct support windows for each release. The output is a recurring service schedule, a log of changes and an updated evidence pack after each upgrade. Retainer terms, response expectations and fees are set in the quote, which DeployOpen issues from the written scope rather than from a published price list.
