Open edX upgrades and support

Ongoing support for an Open edX platform falls into three different kinds of work, and the difference matters when you decide what to buy. Incident response is unplanned work triggered when something breaks, such as the LMS returning errors to learners, Studio becoming unavailable to course teams, or a worker queue stalling. Routine maintenance is scheduled work that keeps the running platform healthy, such as patching, certificate renewal and backup checks. Planned upgrades are larger, scoped changes that move the platform to a newer Open edX named release or a newer Tutor version. Each has a different urgency, a different owner and a different price basis, so ask any partner to show how each is handled in writing.

Routine maintenance on a Tutor-based platform starts with monitoring. The scope should name the LMS, Studio and the background workers, with checks on process health, error rates, queue depth for asynchronous tasks, database and cache availability, and disk use on the media and log volumes. Ask who receives alerts, who is on call outside business hours, and what the platform owner is expected to do when an alert fires. Security patches are applied to the release you run, which is the only release that receives them, so the maintenance scope should state how patches are tested on a staging copy before they reach production and who approves each change.

Backup verification is one of the most overlooked parts of routine support. A backup that has never been restored is an assumption, not a recovery plan. The support scope should specify which databases and file stores are backed up, how often restores are tested, and who performs the restore test and records the result. Configuration changes are a separate category. A partner can advise on settings in the Tutor configuration, on the cache and database layout, or on logging, but the decision to change production configuration should stay with your change process, with the advice and the reasoning recorded.

Plugin breakage after a Tutor update deserves its own line in the scope. Tutor plugins, custom XBlocks and themes are the most likely components to fail when the underlying distribution moves forward. Support should cover diagnosing which component broke, repairing it within the agreed scope, and reporting what was changed. Support does not normally include rewriting a custom feature that the current release no longer accommodates, because that is development work. Ask whether a fix for a plugin break is covered by the retainer or quoted separately, and how the boundary is drawn.

DeployOpen offers ongoing support, upgrades and continuous testing as retainers. The scope, the response expectations and any service levels are agreed in writing before the retainer starts, and they should be checked against your own internal obligations before you sign. Ask for the written definition of what counts as an incident, what counts as routine work, what is excluded, and how additional work is requested and quoted. Service levels are not stated here because they depend on the agreed scope and on your environment.

Before any upgrade or support retainer starts, your team needs to hand over a defined set of access, artifacts and decisions. Without them, the first weeks of the engagement go to discovery instead of testing, and the change window slips. The list below is what we ask for at the start. Each item has one owner on your side, and each owner should be named in writing before work begins. Administrative access comes first. The implementer needs administrative access to the hosting environment (cloud accounts, data center hosts or the air-gapped network where the platform runs) and to the Tutor configuration, meaning the environment files, the list of enabled plugins and the settings that define your deployment. The owner is your platform or infrastructure lead. Ask them to confirm which accounts can grant access, how credentials are issued and whether any access must be logged or time-limited under your own policy.

Next, you provide a current backup and a copy of the deployment repository. The backup must be recent enough to restore the LMS and Studio databases, the MongoDB content store, media files and any object storage that holds course assets, and your team should test a restore of it before the engagement starts. The repository should hold the Tutor project and any local customization, with a record of the commit that is running in production. The owner is typically the platform lead, with the database administrator confirming restore steps. If no recent backup exists, the first task is to create one and verify it, and that adds time to the schedule.

You also supply an inventory of custom XBlocks, plugins, themes and integrations. This list is the basis of the compatibility assessment, so it should name each item, its source (in-house code, a vendor package or a community plugin), the version or commit in use, the person who last changed it and any external system it calls, such as an SSO provider, a payment gateway or an LTI tool. Gaps in this inventory are the most common reason an upgrade estimate changes after kickoff. The owner is usually the lead developer for the platform, with the business owner of each integration confirming it still matters. Items nobody can name should be flagged as a risk rather than dropped silently. Business owners approve test results, and this decision must sit with named people, not a shared mailbox. Assign one owner for learner-facing flows, one for course authoring and Studio, and one for each integration that carries grades, enrollments or identity. Each owner signs off on the test cases that cover their area and on the go-live recommendation. Agree in advance how long a sign-off takes and who decides if an owner is unavailable: a named deputy with equal authority should hold the decision, and if no deputy exists, the release waits rather than proceeding on silence.

Finally, you provide a test account set and sample courses, a change window agreed with the teaching calendar, and a decision on who receives alerts. Test accounts should cover each learner role, instructor, course team member and administrator, and should include enrollments in sample courses that use the XBlock types you rely on. The teaching calendar owner, usually an academic or program operations lead, decides which dates are closed to change, including exam periods and cohort starts. Alert recipients are owned by the operations lead, and you should confirm an escalation path for out-of-hours incidents. If the operations lead is unavailable during scheduling, the window should default to a period that the teaching calendar already marks as quiet, and that choice should be recorded before the retainer begins.