What an Open edX migration involves
An Open edX migration means moving course content, learner accounts, enrollments and historical records out of a previous system and into an Open edX platform, then proving the result works before anyone is switched over. Content is the simplest part to describe and often the largest part to deliver. Courses are either rebuilt in Studio, the authoring service, or imported into it, and each import needs a check that units, graded components, videos and file assets arrived intact.
Common triggers are leaving Moodle or another LMS, consolidating an older Open edX install onto Tutor, and a contract for an existing platform ending. The third trigger matters most for planning, because the migration deadline is set by someone else. Consolidating a native or Ansible-based deployment onto Tutor is a different job from a first-time move: the source data already has Open edX structures, so the team must confirm which database tables, course versions and media paths carry over and which must be rebuilt. Confirm the exact source version and its database engine with your current administrator before estimating anything.
Learner accounts and enrollments need a mapping decision before any data moves. Decide whether usernames, email addresses and external identifiers will be kept, how duplicate accounts are merged, and whether passwords are migrated or learners reset them. Map each historical record, such as grades, completion status and certificates, to a destination you can explain to an auditor. Records that cannot be mapped cleanly should be archived in read-only form rather than forced into the new schema. Ask any partner to state how each record type is handled and who signs off on exceptions.
Cutover should be rehearsed at least once on a copy of production data before users move. The rehearsal checks enrollment counts, grade totals, login paths, identity provider behavior and the content of a sample of courses, and it measures how long the data load takes. Teams usually run this in-house when they already operate Tutor and have staff who know Studio and the LMS data model. Most others engage a service provider for the mapping and rehearsal work, since the maintainers of edx-platform recommend production installs through a service provider or Tutor. Ask for the rehearsal results and a rollback plan in writing before approving the cutover.
What the work includes
A fixed-scope migration usually runs as six workstreams, each with a named deliverable. What the source system can export determines how much of the data mapping and history can move, so that check comes first.
Source inventory and content audit
We catalog every course, program, learner group, role assignment and integration in the source system, then classify each item as migrate, rebuild or retire. The client receives a source inventory register and a content audit report. Check early which content formats and export tools the source offers, because they determine what can be imported without rework.
Course export and import into Studio
Course content is exported from the source and imported into Open edX Studio through a repeatable script set, with each course logged for success, warnings and failures. Media links, quizzes and embedded tools often need manual rework. The client receives a migration script set and an import log per course. Confirm which course formats the source exports completely.
User, enrollment, role and grade mapping
Learner accounts, enrollments, instructor and staff roles, grades and certificates are mapped from source fields to Open edX models. Which of these move, and how completely, depends on what the source exports. Where grades or certificate records cannot be exported, the mapping sets out the fallback. The client receives a signed data mapping workbook.
Identity mapping to your SSO
Existing learner identities are matched to the identity provider you use, such as SAML 2.0, Shibboleth or an OAuth2 provider, so learners keep their accounts after cutover. The work covers matching keys, handling duplicate or shared emails and deciding how accounts are linked. The client receives an identity mapping specification. Confirm the identity provider's attributes and the source's username format before design begins.
Staging rehearsal and cutover runbook
The full migration runs in a staging environment at least once, and the results are compared against the mapping workbook. The cutover runbook records each step, owner, checkpoint and the rollback path, and it is tested during rehearsal. The client receives a rehearsal report and a signed-off cutover runbook. Ask which change window and freeze rules your organization requires.
Post-cutover reconciliation
After go-live, record counts, enrollments, grades and identities are reconciled against the source snapshot taken at cutover. Discrepancies are logged, classified and resolved before the source is retired. The client receives a reconciliation report with open items and their owners. Agree in advance how long the source stays available for lookups and who signs off the final count.
What drives cost and duration
This table lists the factors that change Open edX migration effort and timeline, why each one matters, and how to keep its impact down before the scope is agreed in writing.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of courses and content size | Every course needs export, import, link repair and review. Large media libraries also increase transfer and storage time. | Inventory courses by use. Archive or retire inactive courses before migration and move media in batches. |
| Content types (video, problem types, custom components) | Standard components map cleanly. Third-party or custom components with no Open edX equivalent need rebuilding as XBlocks or replacing. | Audit every component type early. Replace rarely used interactive content with supported Open edX components where the teaching goal allows. |
| Learner history and grades to carry over | Enrollments, progress and grades must map to Open edX records, and gradebook mismatches are costly to correct after launch. | Decide which history must move and which can stay in an archive. Agree the grade mapping rules with registrars and course owners. |
| Number of source systems | Each system adds its own export format, data quality issues and reconciliation work before records can be merged. | Name the system of record for each data set. Consolidate or exclude sources that hold duplicate or stale data. |
| Integrations (HR, SSO, payment) | Enrollment, identity and payment flows must work on day one. Each integration needs design, test accounts and sign-off from its owner. | List every integration with its owner and go-live need. Defer non-essential feeds to a later phase after cutover. |
| Target edition, hosting and customization | Tutor on one server, Kubernetes, or a service provider each carry different build and operations effort. Custom themes, plugins and XBlocks add build and test time. | Fix the hosting choice before the migration plan. Limit customization to what learners and course teams need at launch. |
| Environments and rehearsal runs | Each rehearsal repeats imports, checks and fixes. Fewer rehearsals usually mean more defects found during the cutover window. | Agree the number of full dry runs in the written scope. Use the same export and import scripts in every environment. |
| Compliance and records retention | Retention rules for grades, certificates and learner records can require audit trails, legal review and secure archives. | Confirm retention periods and evidence needs with compliance owners before mapping data. Keep archive formats documented. |
| Source platform and release (Moodle, other LMS, older Open edX) | Only the latest named Open edX release is supported, so an older Open edX source may need upgrade steps before or after the move. Moodle and other LMS exports need different mapping work. | Confirm the source platform and version first. Plan any upgrade stops with the team, and map source plugins to target equivalents early. |
Project phases and outputs
The migration moves through discovery, design, build, test, sign-off, rehearsal, cutover and hypercare, and each phase ends with a named output the client can review.
Audit the source platform and data
We inventory the source system, including courses, course structure, enrollments, grades, certificates, users and integrations, and identify what is in scope to move. The client receives a source audit report listing each data set, its owner, its volume, and the items we propose to exclude or archive. The phase closes when the client has approved that scope in writing.
Design the target Open edX environment
We design the target Tutor hosting approach, organization structure, course and program layout, and identity model, including how learner accounts will connect to your identity provider through third-party authentication. The client receives a target design document with decisions, open questions and the identity mapping rules. Your identity team signs off on the login design before build starts.
Build the data mapping and transformation
We map source fields to Open edX course structures, user records and enrollments, then write and version the transformation scripts and course import steps. The client receives a field-level mapping specification and a repeatable transformation package that runs the same way each time. Gaps that need a decision from your content owners are logged and closed before testing.
Run test migrations on staging
We run full test migrations into a staging environment built to match the target design, then compare record counts, course content, enrollments and grades against the source. The client receives a reconciliation report listing every discrepancy and its resolution. Each test run repeats until the reconciliation shows no unexplained differences.
Confirm user acceptance and content sign-off
Your content owners review migrated courses, learners and records in staging, and your administrators test logins, roles and reports against the agreed design. The client receives written sign-off for each course group and for the access model. Which content owners and identity staff take part in this phase must be confirmed with you at the start.
Rehearse the cutover
We run the full cutover sequence at least once in a rehearsal environment, timing each step, recording who performs it and what the rollback path is. The client receives a runbook and a rehearsal log that show the steps, owners and decision points. Any failed step is fixed and the rehearsal repeated before the production window is approved.
Cut over and hold through hypercare
We execute the approved cutover runbook in production, then monitor logins, enrollments, grade access and support tickets during hypercare. The client receives a cutover record, a final reconciliation against the source, and a hypercare exit report that lists open defects and their owners. Hypercare ends when the agreed exit criteria are met and signed off.
What to keep in-house and what to outsource
This table shows which migration activities usually stay with your team, which are commonly outsourced, and the skills each side needs, so you can judge where a partner adds the most value.
| Activity | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Content ownership | Deciding which courses, versions and learner groups move, and who owns each course after cutover | Listing source courses and flagging dependencies that need a decision | Course administration knowledge and an accountable owner for each course |
| Course accuracy sign-off | Subject matter experts reviewing imported units, quizzes and media before learners see them | Reporting structural differences found during import rehearsals | Subject expertise and familiarity with the original Moodle or LMS course |
| Learner data decisions | Choosing which learner records, grades and completions to keep, archive or drop, based on your records policy | Mapping agreed fields and producing counts for each data set | Records management and data protection knowledge |
| Identity administration | Owning the identity provider, account mapping rules and decisions on existing learner accounts | Configuring the SSO connection and testing login paths during rehearsal | Identity provider administration (SAML, OAuth2 or LDAP) and account lifecycle policy |
| Export and transformation scripts | Reviewing mapping rules and approving changes to how content is converted | Writing and maintaining the export and transformation scripts for source data | Python and Django for transformation code, plus knowledge of the source LMS data model |
| Tutor deployment | Hosting decisions, access approvals and change windows in your infrastructure | Installing and configuring Tutor, plugins and HTTPS on your servers or cluster | Docker and Kubernetes or Tutor operations, and Linux administration |
| Import rehearsals and reconciliation | Signing off rehearsal results and the go or no-go decision for cutover | Running repeated imports, comparing counts and building reconciliation reports | Scripting for data comparison and QA discipline for repeatable test runs |
What usually goes wrong
Most Open edX migrations fail at the edges: content that looks complete in the export, learners who do not match across systems, and cutovers that cannot be reversed. Each card names the failure, the prevention step and the check that shows the prevention worked.
Exported content that does not render
A course export can complete without errors and still show broken videos, missing assets, or quiz components that display as raw markup after import. Prevent this by importing a representative sample of courses into a staging instance running the target release, then rendering every component type. Check by comparing component counts and rendered pages against the source course, including media links and graded problems.
Third-party tools without a direct equivalent
Tools such as external quizzes, proctoring, labs or plagiarism checks rarely map one-to-one onto Open edX. Decide per tool whether it moves to LTI, a custom XBlock or is retired, and record that decision in the scope. Check by confirming each tool has a working launch and grade return path in staging before any course depends on it.
Learner identities that do not match
Duplicate accounts, missing accounts and changed email addresses are the most common identity problems when learners move between systems. Build a mapping key from a stable identifier where one exists, and define how email changes and duplicates are resolved before import. Check by reconciling the learner count and enrollment totals per course between source and target.
Passwords that cannot move in plain form
Source password hashes often use formats the target does not accept, so passwords cannot simply be copied across. Plan a forced reset with a clear message, or an SSO path through SAML 2.0, Shibboleth or OAuth2 where the organization already has an identity provider. Check by signing in as test learners through each path before the cutover date.
Grades and certificates that change meaning
If the target grading model, weighting or certificate criteria differ from the source, imported grades can describe something other than what learners earned. Document the grading rules on both sides, decide whether historical grades are imported, displayed or recalculated, and get sign-off from the academic owner. Check by recomputing a sample of learner grades and certificate eligibility in staging and comparing the results.
Cutover without a tested rollback
A migration that switches learners over with no proven way back leaves the organization stuck if data or access problems appear after go-live. Rehearse the full cutover, including the final data sync and DNS or routing change, and time each step against the agreed window. Check that the rollback runs end to end in the rehearsal and that the source system remains readable until the business accepts the target.
A target built on an unsupported release
Open edX supports only its latest named release, so a migration built on an older release starts with a platform that will need another upgrade soon after go-live. Confirm the target release against the Open edX release notes at the start of the project and plan the upgrade path into the support window. Check by recording the release and Tutor version in the scope and confirming both are current on the day of cutover.
How the work changes by starting point
Moodle courses are organized around activities and resources, while Open edX courses are built from sections, subsections, units and XBlocks in Studio. Mapping is a design exercise before it is a data exercise.
- Mapping: Match each Moodle activity type, such as quizzes, assignments, forums and third-party plugin activities, to a built-in XBlock, a custom XBlock or a retirement decision.
- Learner records: Plan how enrollments, completions and grades are carried over, and check which of them your Moodle administrators can export.
- Extra steps: Rebuild assessments in Studio, then compare attempt limits, grading rules and due dates against the source course.
- Confirm early: The Moodle version in production, which plugins hold business-critical content, and whether course backups can be exported in full.
Each source LMS has its own content and data model, so the first task is establishing what the source can hand over in a usable form. The mapping then runs from the source's course structure and learner records to Open edX courses, enrollments and grades.
- Course structure: Map source modules and lessons to Open edX sections, subsections and units, and decide which external resources stay as links.
- Identity: Map source accounts to learner identities, and decide how external IDs and credentials are handled through SSO.
- Extra steps: Normalize media, embedded scripts and third-party tool launches, and test each content type separately.
- Confirm early: Whether the source exports course content, learner data and grades, and whether its license terms allow that export.
A native or Ansible-based Open edX install is still Open edX, so course content often moves with fewer changes than content from another platform. The work shifts to the deployment layer, because the target runs on Tutor and the source's configuration and customizations need to be understood first.
- Release path: Confirm which named release the old install runs. Open edX supports only the latest named release, so plan the upgrade path from the source release to the current target, which is Verawood according to the release notes.
- Configuration: Rebuild settings, custom themes and Ansible overrides as Tutor configuration and plugins.
- Data: Confirm the MySQL and MongoDB content, media files and user records, then test restores before cutover.
- Confirm early: Installed custom XBlocks, theme changes and whether the source database can be backed up consistently.
Kubernetes and air-gapped targets change when data can move and how container images arrive. Tutor supports Kubernetes deployments, but the migration has to fit the cluster's storage, networking and image supply.
- Images: In an air-gapped network, mirror every container image the Tutor deployment needs into an internal registry before cutover.
- Transfer: Move course archives, database dumps and media through an approved path, with checksums, malware scanning and a named owner for each store.
- Storage and database: Decide between managed and in-cluster databases, size persistent volumes for media, and test restores inside the cluster.
- Confirm early: Which registries the target can reach or mirror, the approval process for data crossing the boundary, and who signs off on the transfer.
What you need to provide
The audit phase exists to find the gaps in these inputs before any data moves. Work on an Open edX migration cannot be scoped reliably until the team knows what the source system holds, who can approve content and which identity provider will sign learners in. Expect to supply the following before the audit starts: read access to the source LMS or export files from it, a representative sample of courses and learner records for profiling, and a written data protection decision on which records migrate and which are archived.
Several items are decisions rather than files. Name content owners who can sign off each imported course, since a course that imports cleanly but is wrong in content still fails review. Provide the identity provider details for SSO (protocol, metadata or endpoints, attribute names for email and student ID), so account linking can be designed against the third-party authentication options your organization actually uses. Confirm the cutover window with both business and technical owners, because learner access, enrollments and gradebook history will be frozen during it.
Infrastructure and naming inputs are equally important. Grant access to the target hosting environment, whether a cloud account, a data center or a private network, and confirm who owns DNS and TLS certificates for the new domain, since both are needed before the tested cutover. Name a single accountable owner on your side and a single owner on the DeployOpen side. Missing owners tend to surface late as blocked approvals, and an unnamed approver for data protection or content can move the schedule more than any technical issue.
Common questions about Open edX migration
How much does an Open edX migration cost?
The cost depends on the scope you agree in writing, so there is no standard figure. The main drivers are the source system (Moodle, another LMS, or a legacy Open edX install), the number of courses and the volume of media and learner records, the amount of data mapping, custom XBlocks or plugins to rebuild, and the number of test migrations and cutover rehearsals. A fixed-scope quote should itemize each migration stage, the data mappings and any custom work, testing and cutover support, what you provide, and what recurs after go-live, such as hosting and support. Ask whether the quote covers hosting setup on your infrastructure.
How long does an Open edX migration take?
Duration follows from the drivers and phases, so ask for a schedule tied to your written scope. The phases usually include discovery and inventory, data mapping, a target build, trial imports, testing with your course teams, cutover and post-cutover checks. Duration grows with the number of course formats to convert, the number of learner accounts, identity integration, and how many rehearsals you require. A legacy Open edX install may need upgrade steps first, because only the latest named release is supported and the current one is Verawood, published on 30 July 2026.
Can our in-house team migrate to Open edX themselves?
Yes, if your team already has the skills the migration needs. Those skills include Open edX and Tutor operations, Python and Django for import scripts, MySQL and MongoDB administration, Linux and container operations, identity integration, and course design knowledge for checking converted content. Be honest about gaps in each area before you start. Many teams take on the platform build and course content themselves and bring in a partner for the data mapping, cutover and testing. Your own team also carries upgrades and support after go-live, so plan that ownership before committing.
Can learner passwords and grades move into Open edX?
Learner accounts and grades can often move, but the method depends on your source system and the target configuration. Passwords are stored as hashes, and whether those hashes can be carried over depends on the hashing scheme in the source and what the target accepts. If they cannot move, learners reset passwords or sign in through a single sign-on provider. Open edX supports third-party authentication through OAuth2 providers, SAML 2.0, Shibboleth and LTI. Grades need a mapping from old graded items to course blocks, and any course restructuring can break that mapping. Confirm both points with a trial import before you commit to a plan.
What happens to our Moodle courses that depend on plugins?
Moodle plugins do not run in Open edX, so each plugin needs a decision. Plugins that only add a content type can often be replaced by an existing Open edX block or by a custom XBlock. Plugins that change grading, reporting or enrollment need a design that Open edX supports, which can mean a custom build, a Tutor plugin or a process change. Make a list of every plugin in use, the courses that depend on it, and the learner and reporting outcome each one provides. That inventory drives the scope, cost and test plan for the content migration.
What happens after cutover to Open edX?
After cutover, the platform needs ongoing operations: monitoring and backups, security updates, Tutor version upgrades, and testing of custom XBlocks, plugins and themes against each new named release. Your agreement should say who handles each of these after go-live, and whether support is a separate retainer. Plan a hypercare period with your course teams to catch missing content, grade mismatches and login problems. Keep the old system read-only for an agreed period so you can check records and reconcile any late changes.
How DeployOpen delivers Open edX migrations
DeployOpen plans, builds, documents and supports Open edX migrations inside infrastructure you control, moving courses, learners and records from Moodle, another LMS or a legacy Open edX install. Each stage is agreed in writing before the work starts.
How we scope
- Inventory source courses, learner records, enrollments, certificates and media, and agree which of them move.
- Map source data structures to Open edX course and user models, and record every field that will be transformed or dropped.
- Define the written scope, deliverables and cutover window before work starts, since engagements are fixed-scope.
How we build
- Build course import and export pipelines, then run test migrations on copies of the source data to surface mapping gaps.
- Load migrated content into a staging Open edX instance on Tutor or your chosen hosting, and verify course structure and grading.
- Rehearse the cutover end to end, including DNS, redirects, identity mapping and a documented rollback path.
How we hand over
- Document the mapping rules, import scripts, configuration and known exceptions so your team can rerun or audit the migration.
- Provide reconciliation reports comparing record counts and sample learner data between source and target systems.
- Walk your administrators and course teams through the new platform, with runbooks for common post-cutover tasks.
How we support
- Keep a post-cutover support window scoped in the written agreement to resolve migration defects and data discrepancies.
- Offer ongoing support, upgrades and continuous testing as a retainer once the platform is in regular operation.
- Confirm with us how migrated custom XBlocks, plugins and themes will be retested when the Open edX release changes.
