How to use this course platform requirements checklist
This checklist turns course platform requirements into verifiable checks for Open edX or Moodle, so a team can test each need against a named platform rather than a general idea of what an online course system should do. Start by listing what your organization must do: whether courses are sold or delivered free, which payment and tax rules apply, who authors content, what learners receive on completion, and what your leadership expects to see in learner analytics. Then score each requirement as must-have, should-have or out of scope before any vendor or partner conversation. A must-have is a condition the platform cannot launch without, such as a payment flow your finance team has approved or a login method your learners already use. A should-have improves the service but can wait for a later release. Out of scope items stay visible so nobody pays for them by accident.
The rest of this page groups requirements by type: commerce and payments, authoring and certificates, analytics and branding, video and the marketing site, accessibility, and the operations needed to keep either platform running. Work through each group with the people who own it. Finance owns tax and refund rules, the registrar or program owner owns credit and certificate standards, and the security team owns identity, data location and access control. For each must-have, write down the evidence that would prove it works, such as a test enrollment that completes a paid purchase, or a certificate that a third party can verify. Confirm version-specific details with the vendor or your partner, because Open edX and Moodle publish different supported releases and upgrade paths that change which features and hosting prerequisites apply.
Functional requirements every course platform checklist should include
This table lists the functional requirements a course platform must meet, why each one matters, and a concrete check to run before launch. Use the verification column as a acceptance test list for Open edX or Moodle, and note the platform differences as a starting point for your own evaluation rather than a feature verdict.
| Requirement | Why it matters | Verification step | Open edX and Moodle at a high level |
|---|---|---|---|
| Selling or free delivery model | Decides whether enrolment is open, invitation-only or gated by payment, which drives the rest of the build. | Write the enrolment rules for each course in one document and walk a test learner through free and paid paths. | Both platforms support open and gated enrolment, but confirm the exact paid enrolment setup with your partner for your chosen version. |
| Enrolment and payment flow | Payment failures, duplicate enrolments and refunds create support load and disputes if not designed up front. | Run test purchases, a declined card, a refund and a coupon, then confirm the learner access state after each step. | Moodle includes enrolment on payment through core and plugin gateways. Confirm how Open edX connects to your payment provider and storefront. |
| Tax and invoicing | Sales tax, VAT or GST rules depend on learner location, and invoices must match what was charged. | Review a sample invoice for a domestic and a cross-border learner against your tax advisor's rules. | Neither platform should be assumed to handle tax calculation alone. Confirm whether the tax engine sits in the storefront or the payment provider. |
| Course authoring | Content teams need a repeatable way to build, review and publish courses without developer help for every change. | Have a non-developer author build a sample course with a quiz, video and a publish approval step. | Open edX authors in Studio, and Moodle authors in its course editor. Test the workflow your content team actually uses. |
| Certificates and completion records | Certificates are often the proof a learner or regulator relies on, so issuing and retrieving them must be reliable. | Complete a course as a test learner, verify the certificate renders correctly, and confirm it can be retrieved after logout. | Confirm the certificate template, verification approach and badge support for your chosen platform version before committing. |
| Learner analytics | Completion, drop-off and assessment data inform revenue and quality decisions and may feed other systems. | Define five reports the business needs, then confirm each can be produced from test data before launch. | Open edX Aspects uses xAPI statements, ClickHouse and Superset. Moodle reporting depends on its reports and plugins. Confirm both against your list. |
| Branding per program | Multiple programs or sponsors often need distinct visual identity without forking the platform. | Check two programs side by side on desktop and mobile, including logos, colors, emails and certificates. | Both platforms support theming, but the depth of per-program branding varies. Confirm the approach with a sample build. |
| Marketing site and content rights | Public catalog pages and marketing content need their own publishing path and clear rights to course media. | Confirm who owns each course asset, where the marketing site is hosted, and how catalog data stays in sync with the LMS. | Both platforms can sit behind a separate marketing site. Confirm the catalog integration method during scoping. |
| Accessibility conformance | Public and government buyers often require WCAG conformance, and course media must be captioned and navigable. | Run an automated scan plus a keyboard-only and screen reader walkthrough of enrolment, a lesson and a quiz. | Accessibility depends on theme, plugins and course content as much as on the core platform. Test your actual theme and courses. |
Which requirements point to Open edX and which to Moodle
Open edX is the stronger starting point when the requirement is a MOOC-style catalog of open or paid courses, with a studio for course authoring and a learner-facing LMS built for that delivery model. Its codebase is licensed under AGPL-3.0, which carries copyleft obligations that your legal team should review if you plan to modify and distribute the platform. Open edX also states that only the latest named release is supported, so your upgrade cadence has to follow the release train rather than a long-lived version.
- Named release model: Verawood is the current named release, published on 30 July 2026, and the next releases, Willow and Xylon, are listed for December 2026 and June 2027.
- Authoring and catalog: Studio is the authoring service and the LMS serves learners, so confirm the course structure, instructor workflow and catalog features you need in the current release notes.
- Identity options: Third-party authentication covers OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates.
- Analytics path: Aspects captures tracking logs as xAPI statements and presents them in Superset dashboards, which requires its own data services to be planned.
- Operating stack: Development requires Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached, and multi-node deployments need a shared cache such as Redis or Memcached.
Confirm each capability against the Open edX documentation for your target release before you commit.
Moodle fits organizations that need a broad core of learning features, a large plugin ecosystem and a familiar administrator and teacher experience, including formal courses, assessment and institutional reporting. Its code is licensed under GPL-3.0, and it can be self-hosted or run as managed hosting through MoodleCloud or Moodle Partners. Moodle ships major releases every six months and designates long-term support releases, so you can plan upgrades around a support window.
- LTS planning: Moodle 5.3, released on 5 October 2026, is the next LTS with general support until 4 October 2027 and security support until 1 October 2029; Moodle 4.5 has security support until 4 October 2027.
- Database and PHP requirements: Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must run Moodle 4.4 or later to upgrade.
- Public document root: From Moodle 5.1 the web server must point to the
/publicdirectory, so check your web server configuration during deployment. - Core authentication: Core ships plugins for manual accounts, email self-registration, LDAP, LTI, OAuth 2, Shibboleth and web services, with SAML 2 available as a marketplace plugin.
- Plugin dependency: Many commerce, reporting and integration features come from plugins, so review each plugin's maintenance status and compatibility with your target release.
Confirm specific features and plugin versions with the Moodle plugin documentation before you assume they are available.
The practical split depends on which requirement dominates your project. If the core need is a scalable open catalog with a studio-led authoring model, Open edX is the natural fit. If the need is broad institutional learning, many assessment types and a wide plugin base, Moodle is usually the better match. Both platforms can take on payments and certificates through configuration or plugins, so the decision should rest on catalog model, authoring workflow and team skills rather than on a single feature.
- Catalog model: Open catalogs and MOOC-style delivery point toward Open edX, while formal course structures and institutional programs point toward Moodle.
- Upgrade rhythm: Open edX supports only its latest named release, while Moodle supports LTS releases over a defined window.
- Team skills: Open edX uses Python, Django and React, while Moodle uses PHP and a plugin model, which affects hiring and support.
- Infrastructure: Compare database, cache and PHP or Python requirements against your existing platform standards.
- Licensing review: AGPL-3.0 and GPL-3.0 carry different obligations for modified distributions, which your counsel should assess.
Write your top three requirements, then test each platform against them in a short proof of concept.
Before choosing a platform, each candidate needs a documented check against the features your business depends on. Capabilities can change between releases and plugin versions, so a claim from a summary page is not enough for a procurement decision. The useful exercise is to map each requirement to a specific documented feature, a release and a test case in a non-production environment.
- Payments and taxes: Confirm which payment gateways, tax handling and invoicing options are supported in your target release or through plugins.
- Certificates and badges: Confirm certificate templates, badge criteria and verification options in the release documentation.
- Learner analytics: Confirm which reports exist out of the box and which need separate data services.
- Video and accessibility: Confirm video hosting options and accessibility conformance of the theme and components you plan to use.
- Operations: Confirm the support window, upgrade path and database versions for the release you select.
Record each check with the version tested so the decision can be revisited when the next release arrives.
Security requirements that separate course platforms
Course platforms hold learner identities, enrollment and payment records, and certificates that employers or regulators may rely on. The cards below cover the controls that most often decide whether an Open edX or Moodle deployment is safe to operate, and who should check each one before go-live.
Single sign-on and identity brokering
Decide which identity source is authoritative for learners and staff, then confirm each protocol path end to end. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with CAS and SSL client certificates only as older provisional support. Moodle core adds LDAP, external database and web services authentication. Verify that deprovisioned users lose access, that session lifetimes match policy, and that the identity team, not the course team, owns the trust configuration. The security engineer should test this with a removed test account.
Learner data protection
Learner records include names, email addresses, assessment results, and often age, employer or country. Map every field the platform stores, where analytics events go, and which backups hold copies. Confirm encryption in transit and at rest, role-based access to gradebooks and personal data, and a documented process for data access and deletion requests. The compliance lead should sign off on the data map, and the platform team should prove the deletion workflow runs against a test learner.
Payment scope and card data
Whether the course platform touches card numbers determines how much of the environment falls under PCI DSS. A hosted payment page or a redirect to a provider keeps card data off your servers, while a custom checkout that posts card fields through your platform widens scope. Confirm which payment path each product uses, whether any plugin stores card data, and which party holds the attestation of compliance. The payment provider and the QSA or internal assessor should agree the scope diagram before the first sale.
Administrator access and logging
Platform administrators can change grades, impersonate learners and alter certificates, so their actions need strong authentication and an audit trail. Require named admin accounts, separate from everyday instructor roles, with multi-factor sign-in at the identity provider. Forward LMS and Studio audit logs and server access logs to a store the operations team cannot edit. The security operations lead should test that an admin grade change or role grant produces a log entry that someone reviews.
Secrets and backups
Database credentials, OAuth client secrets, payment keys and SAML signing keys must live in a secrets manager, not in configuration files checked into source control. Backups must cover the relational database, media and course assets, and the keys needed to decrypt them, and they must be restored on a schedule. Ask the operator for a restore test record that names the date, the scope and the recovery time observed. The platform owner should review the results, not just the backup job status.
Patching cadence tied to release windows
Open edX supports only its latest named release, so an older deployment may have no vendor fixes at all. Moodle publishes long-term support releases with separate bug-fix and security-fix end dates. Moodle 5.3 has security support until 1 October 2029, while Moodle 5.1 security support ends on 19 April 2027. Write down which release you run, when its support ends, and the upgrade budget for the next window. The platform owner should own the calendar, and the security team should confirm each patch is applied to every environment, including staging.
How accessibility deadlines shape the checklist
This sequence turns accessibility obligations into specific checklist items, test scope and evidence that the course platform team, the implementation partner and the accessibility reviewer can each verify before launch.
Confirm your legal status under ADA Title II
Legal or compliance counsel confirms whether your organization is a state or local government entity, or a special district, covered by the Department of Justice ADA Title II web rule. Private universities, companies and training providers that are not public entities should document that conclusion separately, because the rule does not apply to them in the same way. The step is done when the decision, and the reasoning behind it, is recorded in the project file and signed off by the accountable owner.
Record the interim final rule compliance dates
Using the ADA.gov interim final rule published April 20, 2026, the project lead notes the compliance dates that apply to your entity: April 26, 2027 for entities with 50,000 or more people, and April 26, 2028 for smaller entities and special districts. The project lead also confirms the population basis with counsel, since that determines which date applies. The output is a dated compliance line in the requirements register that the launch plan references.
Set the WCAG 2.1 Level AA target
The accessibility lead states in writing that the course platform, including course content, learner pages, video players, quizzes, certificates and checkout, will be tested against WCAG 2.1 Level AA, the standard named in the ADA Title II rule. Any part of the platform excluded from scope, such as a third-party payment page, is listed with its owner. The output is a scope statement that the implementation partner must test against, not a general promise of accessibility.
Map scope to course content and theme
The implementation team inventories every template and content type the platform will publish, including Open edX Studio components or Moodle activities, custom theme pages, uploaded documents and embedded video. Each item is tagged to a checklist requirement, such as captions, transcripts, keyboard operation, color contrast and form labels. The output is a traceable inventory that shows which items each test covers and which items need authoring guidance for course teams.
Test learner paths, players and checkout
The partner runs accessibility testing on the paths learners actually use: registration and sign-in, course navigation, video playback with captions, graded assessments, certificate download and the purchase flow. Testing combines automated checks with manual keyboard and screen reader review. Failures are logged with the WCAG success criterion involved, a severity and an owner. The output is a defect log with retest results for every critical path before launch.
Write a named accessibility test plan
Before testing starts, the partner and the accessibility lead agree on a named test plan that lists the pages, tools, assistive technologies, browsers, test roles and pass criteria. The plan identifies who signs off on exceptions and how retests are recorded. The output is a plan document with a version number and named reviewers, which you can request from any implementation partner in a proposal.
Assemble evidence for the compliance file
The partner delivers the test plan, scope inventory, defect log, retest results and the list of known exceptions with remediation dates to your team. DeployOpen prepares this evidence as part of a readiness engagement, but it does not issue audit reports, attestations or certifications. Where a conformance statement or independent review is required, your counsel or an accredited assessor performs it. The output is a compliance file your reviewers can inspect and an explicit record of who issues any formal conclusion.
Plan the ongoing accessibility review
Because new courses, plugins and Open edX or Moodle upgrades change the learner experience, the operations owner schedules accessibility checks for each release, new course template and new player or payment integration. The European Accessibility Act has its own duties for some e-commerce and e-book activity, covered in the EU data sovereignty course platform topic, and should not be treated as a substitute for this process. The output is a recurring review entry in the operations runbook with a named owner.
Operational requirements and how to verify them
This table compares the operational requirements for a self-hosted Open edX or Moodle platform and the evidence that proves each one works. Read each row as a question to put to your team or partner, with the verification step as the proof you should expect. The main takeaway is that hosting, backups and upgrades are only real once they have been rehearsed, not just designed.
| Requirement | What it needs to cover | How to verify it |
|---|---|---|
| Hosting model | Choose cloud accounts, a data center or a managed Kubernetes setup. Open edX production runs through a service provider or Tutor, since bare-metal installs are complex and get limited community support. | Obtain a written architecture diagram and confirm who holds the cloud or data center accounts and keys. |
| Environments | Separate development, staging and production. Development needs Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached for Open edX, and staging should match production versions. | Deploy the same release to staging first and confirm configuration differences are documented and reviewed. |
| Backups and restore tests | Back up the learner database, course content, media files and any search or analytics stores. Backups have no value until a restore is proven. | Run a timed restore into a separate environment and check that enrollments, certificates and course content are intact. |
| Upgrade path | Open edX supports only the latest named release, currently Verawood, with Willow planned for December 2026. Moodle 5.3 is the next LTS, and sites must run Moodle 4.4 or later to upgrade. | Rehearse the upgrade on a copy of production, record the steps and confirm your plugins and themes still work. |
| Database and cache capacity | Multi-node Open edX needs a shared Django cache such as Redis or Memcached. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. | Ask for the sizing basis, connection limits and a failover test for the database and cache tier. |
| Load testing before cohort launches | Enrollment spikes, exam submissions and video streams place peak load on the LMS and database. Plan tests against expected launch traffic. | Run a load test against staging before each launch and keep the results with the go-live approval. |
| Monitoring and incident response | Track uptime, error rates, database health and queue backlogs. Define who is alerted, how incidents are classified and how learners are told. | Trigger a simulated outage and confirm alerts arrive, the runbook is followed and the incident record is complete. |
| Operating team after launch | Name the owner for patching, upgrades, plugin updates, support tickets and on-call cover. Clarify what your staff run and what a partner runs under a retainer. | Obtain a written responsibility matrix, and confirm the support hours and escalation path in the signed scope. |
What do buyers ask before hiring help for a course platform?
How much effort and cost does a requirements review and build involve?
The cost depends on the written scope, which is the first thing to agree before any work starts. The main drivers are the number of integrations (identity, payments, CRM, student information systems), how much theming and branding is needed, whether video is hosted in-house or delivered through a third-party service, how analytics are set up, and whether you need custom course types or certificate workflows. Some costs are one-time, such as discovery, configuration and migration, while hosting, licenses for third-party services, and upgrades recur. DeployOpen does not publish a price list and quotes from the written scope. When you request a quote, ask it to separate discovery, build, hosting, support and any retainer, and to state what is excluded.
How long does a course platform implementation take?
Timing depends on scope, integrations and how quickly decisions are made internally, so no general duration applies. A platform with standard authentication, one storefront and a default theme usually takes less time than one that needs several identity providers, custom payment flows and a reworked marketing site. Ask any partner for a written plan with phases, milestones, the decisions each phase depends on, and the dependencies on your own teams, such as account approvals for payment providers or access to your identity system. A plan that cannot name the dependencies is a warning sign.
What must our team provide before the build starts?
Your team must make policy decisions and supply accounts and content before the build can move forward. Typical inputs include:
- Named stakeholders in marketing, learning design, finance, legal and IT who can approve decisions within agreed timeframes
- Policy decisions on free versus paid access, refunds, tax handling, certificate criteria, learner data retention and who can see learner records
- Course content, branding assets, and accessibility responsibilities for media and documents
- Accounts with identity providers, payment gateways, video services and any email or CRM tools, with administrator access arranged in advance
Can our team run Open edX or Moodle without an implementation partner?
Yes, a capable internal team can run either platform, but the effort and risk should be assessed honestly. The Open edX maintainers recommend running production through a service provider or with Tutor, because bare-metal installation is complex and receives limited community support. Tutor is the official Docker-based distribution and supports Kubernetes deployments and plugins. Moodle can be self-hosted using its own documentation and has a published list of supported database and PHP versions for each release. The trade-offs are staff time, on-call coverage, security patching, backups, and the skills needed to customize themes and plugins without breaking upgrades. Confirm your team can cover those responsibilities for the life of the platform, not only at launch.
How are upgrades to named releases handled?
Upgrades follow the release model of each platform, so the plan must be built around it. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. Open edX Verawood is the current named release, with Willow planned for December 2026 and Xylon for June 2027. Moodle ships major releases every six months and designates long-term support releases; Moodle 5.3 is the next LTS, with security support until 1 October 2029. Each upgrade should be tested on a staging copy, with custom themes, plugins and integrations checked before production. Ask any partner how upgrades are scheduled, whether they are priced in a retainer or a fixed-scope project, and who handles rollback.
How should we compare implementation partner proposals?
Compare proposals on the same written scope rather than on headline totals. Check whether each proposal lists discovery, configuration, integrations, theming, data migration, testing, security hardening, documentation, training and handover. Ask how each partner handles upgrades, backups, monitoring and incident response after launch, and whether support is a retainer or included. Request references you can verify through your own process, and ask who will do the work, not only who sells it. Confirm which exclusions apply, such as payment provider fees, video streaming charges or third-party license costs, and whether the partner prepares evidence for compliance assessments without issuing any audit report, since independent auditors and certification bodies do that.
What does a course platform partner own after launch?
After launch, ownership should be written down for hosting, patching, upgrades, backups, content support and the platform administrator role. DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and ongoing support is available as a retainer. Confirm which tasks your staff keep, which go to the partner, how incidents are escalated, and what documentation you receive. Ask for the handover plan and the list of credentials and access rights transferred to you at the end of the engagement.
Which requirements change by industry and scenario
The base checklist changes most when the platform sells courses, when it awards university credit, when government login is involved, when healthcare learner records are in scope, or when learner data must stay in the EU. Selling changes the scope more than any other factor. Once learners pay, the platform needs a payment path, tax and invoice handling, refunds, and a clear answer on where card data is processed. Moodle's enrolment on payment and plugin gateways, and storefronts such as WooCommerce connected to Open edX, are different build paths with different payment compliance consequences. Free delivery removes that layer but still needs enrolment rules, an identity source and a support process. Confirm with your payment provider and assessor how card handling affects PCI DSS scope before you choose the design.
University credit, government identity and healthcare records each add a separate layer of decisions. Credit and certificate rules depend on the institution's policies, so confirm who approves completion criteria and what transcript data must flow to the student information system before you finalize the course model. For government deployments, check which identity protocols the agency's login service supports. Open edX third-party authentication covers OAuth2, SAML 2.0, Shibboleth and LTI, and Moodle core covers LDAP, LTI, OAuth 2, Shibboleth and web services, with the SAML2 Single sign on plugin as an option. Confirm the protocol and attribute mapping early, because it sets account provisioning and offboarding. Healthcare programs need learner records kept apart from patient data, so specify which fields the course platform stores and which identifiers it never receives.
EU data location is a hosting decision, not only a configuration setting. Learner profiles, progress, analytics events and video assets each need a stated location, and the analytics stack must be placed in the same jurisdiction. For Open edX Aspects, tracking logs flow through event routing into ClickHouse and Superset, so each component's hosting must be confirmed. Accessibility also varies: public bodies in the United States face the ADA Title II requirement to meet WCAG 2.1 Level AA, with compliance dates set in the interim final rule of April 20, 2026, while courses sold in the EU fall under different duties. Record which rules apply to your organization before you write the accessibility requirement. The sibling topics on university, government, healthcare and EU sovereignty cover these cases in depth.
How to run the checklist with vendors and partners
This sequence turns the requirements list into a short, evidenced shortlist of platform options and a fixed-scope statement of work that a partner can price. Each step leaves a written record that the buying team can check before committing budget.
Confirm scope and name the owners
Before any vendor call, the sponsor, the learning or business owner, the security lead and the operations lead agree which requirements are in scope for launch and which can wait. Each requirement gets one named owner who signs off its acceptance. The step is done when the scope list is dated, signed by the sponsor and shared with every shortlisted vendor or partner so that all of them answer the same questions.
Score each requirement against your priorities
The owners rate every requirement as must have, should have or later, and note whether it is a selling, free delivery, compliance or operations need. Scores are recorded against the platform you are evaluating (Open edX or Moodle) so gaps are visible rather than assumed. The step closes when every must-have has a score, a reason and a named owner, and the list of gaps that need custom work or a plugin is written down.
Run proof tests for the top items
Ask the vendor or partner to demonstrate, in a test environment you can inspect, the highest-risk items: enrolment with a payment in a sandbox gateway, certificate issuance with your branding, single sign-on login with a test identity provider, and a full restore of a backup to a separate server. The step is complete when each test has a pass or fail result, the evidence (screenshots, logs, restore time observed in the test) is stored, and any failure is linked to a requirement owner.
Request written answers to the comparison questions
Send the platform comparison questions in writing and ask for answers tied to named releases, supported versions and the environment you plan to use. Ask which Open edX or Moodle release is targeted, how upgrades to the next named release will be handled, who operates the platform after launch and what support is included. The step is done when every answer is in writing, dated and reviewed by the security and operations leads, and contradictions between answers are resolved before scoring is finalized.
Convert accepted requirements into a fixed-scope statement of work
Turn the accepted, scored requirements, the proof test results and the written answers into a statement of work with deliverables, acceptance criteria, exclusions and a named set of responsibilities for hosting, payments, video, analytics and handover. Confirm with the partner which costs are one-time (setup, theming, integrations) and which recur (hosting, support, upgrades, licenses or payment fees). The step closes when the sponsor signs a scope that a written quote can be checked against.
How DeployOpen scopes, delivers and supports course platform selection and implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For course platform requirements, we turn the checklist above into a written scope that decides between Open edX and Moodle, and then carry that decision through build, handover and ongoing support.
How we scope
- Review selling or free delivery, payment, tax and certificate requirements against the checklist before naming a platform
- Confirm the identity provider, student system and video hosting the platform must connect to
- Agree deliverables, timelines and exclusions in writing before any implementation work starts
How we build
- Deploy Open edX or Moodle in the cloud account, data center or air-gapped network you specify
- Configure branding, authoring workflows, accessibility checks and learner analytics against the agreed scope
- Run security testing on the deployed platform and document the results as part of delivery
How we hand over
- Provide runbooks for hosting, backups, upgrades and access control so your team can operate the platform
- Document configuration, integrations and compliance evidence in a form your auditors and assessors can review
- Walk your administrators through the release path for the named version you run
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after launch
- Plan upgrades around the named release and security support windows your version depends on
- Keep the platform, plugins and integrations current as your requirements change over time
