How to migrate Moodle from Oracle or SQL Server to PostgreSQL
Moving Moodle from Oracle or SQL Server to PostgreSQL uses the Database transfer tool in Moodle core, and the cutover runs inside a planned maintenance window. Effort depends mainly on three things: the size of the site, the plugins it runs and the Moodle version you move to. Those inputs are not known until someone inventories them, so the answer on effort comes from a written scope that lists each one. Teams in this position often need PostgreSQL for licensing, hosting or skills reasons, and the migration decision should be tied to a target version first, because that version sets the database engine you must provide. The Moodle release notes state the Oracle transfer requirement for Moodle 5.0, so confirm the exact cutoff there before you plan.
The target Moodle version matters because each release sets its own minimum database and PHP levels. Moodle 5.1 requires PostgreSQL 15 or later, Microsoft SQL Server 2017 or later and 64-bit PHP 8.2 or later, and sites must already be on Moodle 4.2.3 or later to upgrade. Moodle 5.3 raises those floors to PostgreSQL 17, SQL Server 2019 or later and PHP 8.3 or later, and requires Moodle 4.4 or later for the upgrade path. If you target 5.3, choose a PostgreSQL major version from 17 onward that is still inside its support window: 17 is supported to November 8, 2029, and 18 to November 14, 2030. Confirm each requirement in the release notes for the exact version you plan to run.
Run the transfer on a copy of production before the window, and time each step on that copy so the cutover plan rests on observed behavior. After the run, compare row counts on the largest tables and check a sample of courses, grades, files and user records. Inventory anything that touches the old engine directly, including custom reports or blocks with hand-written SQL, external database authentication or enrolment connections, scheduled reports and third-party tools that query the Moodle database. These do not move on their own and need rework or repointing. Keep the source database and a full backup of the moodledata directory until acceptance is signed off, so rollback stays possible. Confirm in the Moodle documentation for your version what the transfer tool covers and what it leaves to you.
Ask for a written scope that answers five questions: which plugins are installed, their versions, and whether each has a release for the target Moodle version; the size of the database and file store measured on the live site; which external systems read from or write to the database; the maintenance window the business will accept and who signs the go or no-go decision; and what rollback looks like if acceptance fails. A quote should separate one-time work, such as assessment, rehearsal, cutover support and post-migration checks, from recurring costs. The recurring costs are mostly the PostgreSQL and Moodle operations you carry after the move, including backups, patching and minor releases. Ask which items the quote includes and which depend on decisions you have not yet made.
What maps cleanly and what needs rework when moving Moodle to PostgreSQL
This table compares the main Moodle data areas on an Oracle or SQL Server site with their PostgreSQL equivalent and notes what to check after the move. Read the middle column as what the source site holds and the last column as what the transfer carries across and what needs a planned review. The main takeaway is that core schema data generally moves through the transfer tool, while plugin tables, raw SQL and engine-specific reports need review before cutover.
| Area | Source site on Oracle or SQL Server | PostgreSQL equivalent and migration notes |
|---|---|---|
| Core course and user data | Course, user, enrolment and activity records in core tables | Standard Moodle schema on PostgreSQL. Maps cleanly through the core transfer tool. Confirm record counts and sample course access after cutover. |
| Grades and question banks | Gradebook items, grades, question categories, questions and quiz attempts | Standard schema that maps cleanly. Check grade calculations, letter boundaries and quiz attempt timings on a test copy. |
| Files | File metadata in the database and file content in the moodledata file store | Metadata moves with the database. The file store is separate and must be copied and checked against the file records. |
| Plugin tables | Tables created by third-party plugins, with their own install and upgrade code | Needs review. Confirm each plugin supports PostgreSQL and that its upgrade code runs cleanly on the target database. |
| Raw SQL in custom code | Queries that use Oracle or SQL Server functions, identifiers, quoting or hints | Needs rework. Replace engine-specific syntax and run the queries through Moodle's database API before go-live. |
| Custom reports | Reports written for Oracle or SQL Server date, paging or string functions | Needs rework. Rewrite each report for PostgreSQL and compare its output with the source report on the same data. |
| Database-backed authentication and enrolment | External database connections that read users or enrolments from an Oracle or SQL Server source | The external database is outside the transfer. Reconfigure the connection and queries for the new engine and test logins and enrolments. |
| Scheduled tasks and site configuration | Cron-driven tasks and site settings stored in the database | Settings carry over with the database. Check the cron schedule and any custom task that calls engine-specific code. |
| PostgreSQL version | Moodle release sets the minimum engine version | Moodle 5.1 lists PostgreSQL 15 or later. Moodle 5.3 requires PostgreSQL 17. Confirm the version against your target release. |
Documented tools and paths for the database transfer
Moodle's core Database transfer tool is the documented starting point for moving a site to PostgreSQL. The supporting paths are the moodledata directory, configuration updates and the upgrade procedure on the target version, with PostgreSQL's own tools covering the target side.
Core database transfer tool
Moodle core includes a Database transfer tool, reached from site administration, that moves site data from the current database engine to a new one. Before you open it, confirm in the Moodle documentation for your exact version which engines and versions it accepts, what the target database must look like, and whether the site must be in maintenance mode during the run. Treat the documented steps as the reference, and rehearse them on a copy of the production database before the cutover window.
Target PostgreSQL version
The target must meet the requirements of the Moodle release you run after the move. Moodle 5.1 requires PostgreSQL 15 or later, and Moodle 5.3 requires PostgreSQL 17. PostgreSQL 14 is supported only until 12 November 2026, so a version chosen now should match the Moodle release you plan to reach. Check the release notes for your target Moodle version before fixing the PostgreSQL version.
Moodledata file directory
The transfer covers database content, while the moodledata directory holds course files, user uploads and caches. That directory must stay accessible to the upgraded site, and its ownership and permissions must match the web server user on the new host. Copy it alongside the database, then verify file counts and a sample of course files after cutover. Confirm in the documentation how the directory path is referenced after the move.
Configuration file updates
The config.php file records the database type, host, port, name and credentials that Moodle uses at startup. After the move, update these values to the new engine and host, and confirm the database user holds the privileges the installation needs. From Moodle 5.1, the web server document root must point to the new public directory, otherwise the site may show directory listings or errors. Keep a copy of the original file so you can roll back.
Upgrade on the target version
Once the data and configuration are in place, run the Moodle upgrade procedure on the target version so the schema and plugins match the code. The site must already run a supported starting version: Moodle 5.1 requires Moodle 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. If your site is further behind, confirm whether an intermediate upgrade is needed, since that adds a planned step to the window. Check the starting version and upgrade order in the release notes.
PostgreSQL tools and authentication
On the PostgreSQL side, pg_dump and the matching restore tools handle loading and checking the data, and the client authentication settings decide how Moodle's database user connects. Use SCRAM password authentication, because MD5 password authentication is deprecated in PostgreSQL 18. Test the connection from every web and cron host before cutover. Confirm the current transfer tool steps in the Moodle documentation for your version, since those steps drive the migration.
How the Moodle database transfer works step by step
The core transfer begins by placing the Moodle site in maintenance mode, so that no user, cron task or background process writes to the source database while the copy runs. A transfer against a live site produces a target that disagrees with the source as soon as someone saves a quiz attempt. Before enabling maintenance mode, take a full backup of the source database and the moodledata directory, and confirm that the Database transfer tool appears in the administration menu of your exact release. The tool reads each table from the source engine, Oracle or Microsoft SQL Server, and writes it into a PostgreSQL database that Moodle has not yet installed into. Rehearse the whole sequence on a copy of the site first, because the run time depends on your data volume and hardware, and those figures should come from your own rehearsal.
The target database has to exist before the copy starts, and its settings matter. Create it with the encoding and collation that Moodle's database requirements for your release specify, and confirm those values in the Moodle installation documentation instead of relying on package defaults. Create a dedicated login role that owns only this database, and set a strong password. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so configure the server to store passwords with SCRAM-SHA-256 and set the host-based authentication rules to require it for the Moodle connection. PostgreSQL 18 is the newest supported major version, but the version you choose must appear on the supported list for your Moodle release. Moodle 5.1 lists PostgreSQL 15, and Moodle 5.3 lists PostgreSQL 17, so confirm the exact list for your target release before you install.
With the target ready, the tool copies the data table by table. Each table's structure, indexes and rows move from the source engine into PostgreSQL, and text, binary and date fields need checking afterwards because the two engines handle them differently. Read the tool's output for errors on every table, and keep the log with your change record. A completed run does not prove success on its own. Compare row counts for key tables such as users, courses, enrolments, grades and logs against the source, and spot-check a sample of file attachments and quiz attempts. Stop and investigate any table that reports an error or a mismatch before you continue, because fixing a problem after users return is harder and riskier.
Once the data is in place, update config.php so that the database type, host, port, database name, role, password and table prefix point to PostgreSQL. Record the source settings in your change log so the rollback path stays clear. Bring the site out of maintenance mode only after you have signed in as an administrator, opened several courses, checked gradebook values, confirmed that cron runs against the new database, and reviewed the administration notifications page. Keep the source database intact and read-only until the business owner signs off, because it remains the fallback if a defect appears after users return. Agree in writing who decides on rollback and how long the source stays available.
Sequence for a parallel run and cutover to PostgreSQL
This sequence moves a Moodle database from Oracle or SQL Server to PostgreSQL in stages, and each stage ends with a verified backup and a defined rollback point. The production cutover happens only after the rehearsal, pilot and parallel run have checked the PostgreSQL copy against the source.
Inventory plugins, custom SQL and integrations
Site administrators and DeployOpen list every installed plugin with its version, local code changes, custom SQL in reports and blocks, and each external system that reads or writes the database, including any external database authentication or enrolment. Each item is marked as compatible with the target release, needing an update, or to be removed. Before any change, the current code, data directory and database are backed up and recorded as the first rollback point. The step is complete when the inventory is signed off and the backup has been restored successfully to a test location.
Fix the target version and server build
Confirm the target Moodle release and check its requirements for PHP, PostgreSQL, web server and starting version in the release notes, since requirements change between releases. For example, Moodle 5.1 requires PostgreSQL 15 or later and points the web server document root at the public directory, while Moodle 5.3 requires PostgreSQL 17 and an upgrade from 4.4 or later. Choose a PostgreSQL major version that the release supports and that is still in its support window under the PostgreSQL versioning policy. Build the staging server from a documented configuration. The output is a server build record and a snapshot of the empty build, kept as a rollback point.
Rehearse the transfer on a production copy
DeployOpen restores a recent production backup to an isolated environment and runs the core Database transfer tool from the source engine to PostgreSQL. The team then checks the transferred site for errors in the logs, scheduled tasks, file permissions, and the web server configuration, and compares row counts for key tables such as users, enrolments, grades and logs. Issues are fixed in the build and the rehearsal is repeated until a run completes with no unresolved errors. The output is a rehearsal log and a list of fixes applied. Production is not touched at this stage, so the rollback point is simply the untouched source system.
Run a pilot with a test group
A defined test group of staff and learners signs in to the PostgreSQL copy and works with real course content, covering quizzes, assignments, grading, file uploads, the integrations from the inventory and scheduled tasks. The team records each defect with its reproduction steps and classifies it as blocking or non-blocking. The pilot confirms behavior that a rehearsal cannot show, such as how users actually navigate the site. Before the pilot, the team confirms with the client how pilot data will be handled, because test writes on the copy are normally discarded or re-transferred rather than carried into production. The output is a signed-off defect list and a backup taken at the end of the pilot.
Compare the copy against the source in parallel
The source stays in service while the PostgreSQL copy is kept running next to it and compared on a fixed schedule. The team checks row counts, checksums of key tables, grade totals, course file inventories and sample course pages against the source. The parallel run has a structural limit: a write made to the source after the copy was taken does not reach the copy unless the team has an approved method to keep the two consistent. Without that method, the run can compare results and exercise read paths, but it cannot serve live users from the copy. Each difference is explained or fixed. The output is a comparison report, and the source remains the rollback point throughout.
Cut over in the agreed maintenance window
Inside the maintenance window agreed with the client, the site is put into maintenance mode, a final backup of the source is taken, and the last transfer runs against the current data. The team then repoints the web server and any integration endpoints, runs the checks from the rehearsal and a short set of smoke tests, and reopens the site only if the agreed go or no-go criteria are met. The criteria and the cut-off time for choosing rollback are fixed before the window opens. If the site must be reverted, the untouched source system is brought back. The output is a cutover record with the backup identifiers, check results and the time the site reopened.
Decommission the old database after retention
The source database, its backups and the transfer logs are kept for a retention period that the client sets with its records, compliance and legal owners. During that period the source is made read-only and is not used for production. After the retention period and written sign-off, the client archives what it must keep, and the source database and its copies are removed. The team records each step and the evidence of removal. The output is a decommission record that the client keeps with its migration file, and the migration is closed only after that record is signed.
What drives the cost and duration of the transfer
This table lists the factors that change how much work the transfer takes and which costs repeat after cutover. Read each row against your own environment, because the same Moodle version can need very different effort depending on plugins, custom SQL and integrations. The main takeaway is that most effort usually sits in plugin and SQL review and testing, not in the data copy itself.
| Driver | Effect on effort | How to keep it down or what to confirm |
|---|---|---|
| Active plugins and database footprint | Each plugin adds tables and may use Oracle or SQL Server specific SQL. Plugins without PostgreSQL support need rework, replacement or removal. | Export the plugin list from each environment. Confirm PostgreSQL support with each plugin maintainer and remove unused plugins before the rehearsal. |
| Custom SQL and reports | Hand-written queries, custom reports and stored routines often use engine-specific syntax and must be rewritten and retested. | Ask for an inventory of custom queries, their owners and how often each one runs. Retire reports nobody uses. |
| Database size and data directory size | Larger databases lengthen the copy, index rebuild and validation steps. The moodledata directory is handled separately and adds its own copy time. | Measure both sizes in a test restore. Use the measured figures to plan the cutover copy window. |
| Number and type of integrations | SSO, HR sync, LTI and external database authentication each need configuration checks and retesting after the engine change. | List every integration with its owner and test account. External database authentication points at another database, so confirm its settings separately. |
| Target Moodle version and upgrade need | Moodle 5.1 requires PostgreSQL 15 or later and Moodle 5.3 requires PostgreSQL 17. Sites on older releases add a separate upgrade project. | Confirm the current Moodle version against the minimum for the upgrade path. Schedule the upgrade and the engine move as separate, tested steps where possible. |
| Number of environments | Development, test and production each need a transfer run, configuration alignment and sign-off. More environments multiply rehearsal and verification work. | Rehearse the full sequence on the test environment first. Keep configuration in version control so environments stay aligned. |
| Available maintenance window | The length of the agreed outage determines whether the final data sync runs in one pass or needs incremental passes beforehand. | Confirm the window with the business owners before scheduling rehearsals. Measure rehearsal timings against it. |
| Testing depth | Scope ranges from login and course smoke tests to full grade, report and integration reconciliation. Deeper testing adds time but reduces post-cutover rework. | Agree the test cases and acceptance criteria in writing before the first rehearsal. |
| One-time and recurring costs | One-time: rehearsals, SQL and plugin rework, documentation. Recurring: Moodle patch releases, PostgreSQL minor releases at least every three months, backups and restore tests. | Ask the quote to separate one-time transfer work from the ongoing support and backup scope. Confirm the PostgreSQL major version support end date for your target. |
Risks that usually break a Moodle PostgreSQL transfer
Most failed transfers trace back to a short list of causes. Each card pairs one cause with the check that prevents it, and most checks depend on a rehearsal against a copy of the production database. Work through the inventory and server checklist first, then schedule the maintenance window only after the rehearsal runs clean.
Plugins without tested PostgreSQL support
Plugins are a common blocker. Some third-party plugins were written and tested only against MySQL, MariaDB or SQL Server, and their install files, custom queries or upgrade steps can fail on PostgreSQL. Inventory every plugin on the Plugins overview page, record its version and listed Moodle compatibility, and confirm PostgreSQL support with the maintainer before the rehearsal. Remove plugins nobody uses, and test the rest on a copy of the database running the target Moodle version.
Custom SQL with engine-specific functions
Reports, custom blocks and local plugins often contain raw SQL that uses functions or syntax specific to Oracle, SQL Server or MySQL, such as vendor date arithmetic, string concatenation or case-sensitivity assumptions. PostgreSQL is stricter about data types and quoting, so these queries can fail in a report or during upgrade. Search custom code for hard-coded SQL, run each query against the target database during the rehearsal, and rewrite queries that depend on the source engine's behavior using the Moodle database API.
Data held outside the database
A database transfer moves rows only, so the rest of the site must be copied separately. The moodledata directory holds uploaded files, backups and caches, and it must be copied with checksums and kept at a matching path or configured to match. Database connection settings in config.php, cron schedules, and any external cache or session store also stay behind on the source server. Build a written inventory of these locations and check on the target that a sample of uploaded files opens after cutover.
Target server versions and limits
The target must meet the server requirements of the Moodle release you will run. Moodle 5.1 requires 64-bit PHP 8.2 or later and PostgreSQL 15 or later, and Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17 or later. PostgreSQL 14 support ends on 12 November 2026, so choose a supported major version. Size max_connections against the PHP-FPM worker count and cron processes, and consider PgBouncer when the pool needs tighter control. Confirm each setting on a written checklist before scheduling the window.
Writes during cutover
Any write made after the final copy is lost when the site switches engines. Cron tasks, scheduled reports, course backups, queued messages and users still signed in on the old site can all write during the copy. Plan a maintenance mode window, stop cron and web access to the source, pause integrations that push data into Moodle, and compare row counts on key tables before pointing the site at PostgreSQL. Rehearse the full sequence, including the stop, so the timing reflects measured data volume.
Authentication settings after the engine change
Logins often break after the move because the database user, password method and client access rules are rebuilt on the new server. Check pg_hba.conf for the Moodle application host and database user, and confirm that password authentication uses SCRAM, since PostgreSQL 18 deprecates MD5 passwords. Confirm that external authentication plugins such as LDAP, external database, Shibboleth or OAuth 2 still reach their servers with stored credentials. Test each login method with a test account on the target before cutover.
Configuration and operations after the transfer
The transfer is not finished when the data copies across. Once Moodle runs against PostgreSQL, the first job is to confirm that the web server serves the right code and that the site itself behaves. From Moodle 5.1 onward, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site can show directory listings or errors. Check this in the web server configuration before anything else, then open the site administration notifications page and run the built-in checks. Resolve every error and review each warning, because a database-engine change can surface settings that were quietly tolerated on Oracle or SQL Server.
Next, confirm that the scheduled cron task runs under the web server or service account you intend to keep, and that it completes without errors in the task logs. Cron drives messaging, enrolment sync, reports and many plugins, so a silent failure here can look like a database problem for days. Then test plugin behavior and integrations one by one. Exercise each authentication source, enrolment sync, file storage connector, video or Microsoft 365 link and any AI or payment plugin your site uses. Compare results against the pre-transfer baseline you recorded, and check that plugins are on versions that support the target Moodle release and PostgreSQL version.
Review database access before the site opens to users. In PostgreSQL, the client authentication rules in pg_hba.conf decide which hosts, roles and methods may connect. Prefer SCRAM password authentication over MD5, which PostgreSQL 18 deprecates, and restrict the Moodle role to the database it needs. Where the network path is untrusted, enable TLS for client connections and confirm that Moodle connects with encryption enforced. Ask your PostgreSQL platform owner which methods they support for your environment, since options such as certificate or directory-backed authentication depend on infrastructure you already run.
Backups need the same attention as the transfer. Set up continuous archiving with a base backup and WAL archive so you can perform point-in-time recovery to a moment before an error, not only to the last nightly dump. Then restore the backup into a separate environment, start Moodle against it, and run the site checks. A backup that has never been restored is a hypothesis. Record the measured restore time and the data loss window, and share both with the people who own the recovery objectives.
High availability is an option, not a default. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a failed primary or promote a standby on its own. Automatic failover therefore needs external tooling, and that tooling, its fencing rules and its runbook become part of your operations. Also decide whether you need a connection pooler such as PgBouncer. Moodle opens many connections, so a pooler can reduce overhead, but it changes session behavior and must be confirmed against your Moodle version and the features your site uses before rollout.
Questions buyers ask before moving Moodle to PostgreSQL
How much does it cost to move Moodle from Oracle or SQL Server to PostgreSQL?
No single figure applies to every site, because cost follows the written scope. Who is paid for what: the partner's time covers discovery of the current database and plugins, transfer rehearsals, the production transfer in the maintenance window, testing, configuration and documentation. Your team's time covers named owners, test users and sign-off. One-time versus recurring: the transfer itself is one-time, while PostgreSQL hosting, backups and later Moodle upgrades recur. What drives the cost: database size, the number of custom or unmaintained plugins, the number of environments to rehearse in, and the number of test cycles. Ask for a quote that separates these components and states the Moodle and PostgreSQL versions in scope. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does a Moodle database migration to PostgreSQL take?
The duration depends on scope, not on a fixed template. The main inputs are the size of the database and file store, how many plugins need review or rebuilding, how many rehearsal runs your testing requires, and how much time your institution can give for the final maintenance window. Teams that skip rehearsals or leave plugin review until late usually find the schedule moves. Ask for a timeline in the written scope that lists each phase, the rehearsal count, the testing window and the date of the production transfer. Confirm with your own change calendar and academic term dates before you commit to a window, because those constraints often set the schedule more than the technical work does.
What does our side need to provide for a Moodle to PostgreSQL move?
The engagement needs five things from your organization. Named owners: an executive sponsor, a Moodle administrator, a database administrator, the infrastructure owner and someone who signs off on functional results. Database access: read access to the source database and administrative access to the new PostgreSQL server in your environment. A maintenance window: agreed in advance and long enough for the final copy, validation and rollback decision. Test users: staff and student accounts that represent real roles, courses and grading patterns. Sign-off: a written acceptance step for each rehearsal and for the production cutover. Confirm these owners and dates in the scope before work starts, since delays in any of them usually delay the whole project.
Can our internal team migrate Moodle to PostgreSQL without an outside partner?
Yes, if your team has the skills and the time. The work sits across Moodle administration, PostgreSQL administration, plugin knowledge and testing. Before deciding, check whether your team has completed a Moodle upgrade in the past, understands cron and the data directory, can restore and validate a database backup, and can review plugin code for database-specific queries. Also check capacity, because rehearsals and testing take staff time away from daily support. An outside partner is most useful for planning the rehearsal sequence, reviewing plugins and running the cutover, while your team keeps ownership of the platform afterward. Assess these gaps with your own engineers before choosing either path.
Is moving Moodle to PostgreSQL required before upgrading to a newer release?
It depends on the target release and the database engine your site runs today. Check the requirements section of the release notes for your exact target version, because each release lists the supported database engines and minimum versions. For example, the Moodle 5.1 release notes list PostgreSQL 15, MySQL 8.4, MariaDB 10.11 and Microsoft SQL Server 2017 or later, and require sites to be on Moodle 4.2.3 or later to upgrade. The Moodle 5.3 release notes list PostgreSQL 17 and SQL Server 2019 or later, and require Moodle 4.4 or later. If your current engine is not on the target list, the transfer becomes part of the upgrade path. Confirm the requirement against the release notes for the version you plan to install.
What happens to Moodle plugins that do not support PostgreSQL?
A plugin without PostgreSQL support is a risk that must be resolved before cutover, not after. Some plugins contain queries or schema definitions written for one engine, and some are no longer maintained. Build a full inventory of core modifications and installed plugins, then check each plugin's declared database support, its last release and its compatibility with your target Moodle version. For each plugin, decide whether to upgrade it, replace it, rebuild it or remove it, and test the decision on a rehearsal copy. Do not assume a plugin works because the core migration succeeds. Ask the plugin maintainer to confirm PostgreSQL support in writing when the plugin is business critical.
How does DeployOpen price a Moodle to PostgreSQL migration?
DeployOpen prices most engagements as fixed scope. The scope, deliverables and timeline are agreed in writing before work starts, and the quote follows from that written scope. DeployOpen does not publish a price list. To get an accurate quote, provide the current Moodle version and target version, the source engine and version, the database size, the list of installed plugins and custom code, the number of environments to rehearse in, and the maintenance window you can offer. Ask the quote to show each phase separately. If you need ongoing support after the transfer, such as upgrades, monitoring or continuous testing, those are available as retainers and can be quoted separately from the migration.
How does the core Moodle database transfer tool move data between engines?
Moodle core includes a database transfer tool that moves the site's schema and data from one supported engine to another, which is the usual starting point for this kind of migration. The tool runs against a site that is in maintenance mode, so no users write data during the copy. Engineers should confirm the documented steps for the Moodle version in use, the configuration changes needed in the Moodle configuration file afterward, and the validation to run before users return. Validation should compare table and row counts, check file references and test grading, course backup and restore, and cron tasks. Treat the tool as one step in a tested runbook, and rehearse the full sequence on a copy of production before the cutover.
How DeployOpen scopes, delivers and supports the database move
DeployOpen scopes the move as fixed-scope work, starting from your current Moodle version, database engine and plugin list. Each step is rehearsed on a copy of your database, then handed over with a runbook your own team can run again. Ongoing support after go-live is available as a retainer.
How we scope
- The written scope names your source Moodle version, your Oracle or SQL Server database and your target PostgreSQL version.
- Scope lists plugins, custom code and integrations that read the database, so each one gets a test and a named owner.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- Rehearse the core Database transfer tool on a copy of your production database and record every error and manual fix.
- Check the PostgreSQL version against the Moodle release target, such as PostgreSQL 17 for Moodle 5.3, before choosing hosts.
- Test grades, question banks, file access and scheduled tasks on the copy before agreeing the cutover window.
How we hand over
- A written runbook covers cutover steps, the rollback point, configuration changes and the document root for Moodle 5.1 or later.
- Test evidence includes before-and-after row counts for key tables, so your team can confirm the move matched the source.
- Administrators are trained on PostgreSQL backups, the restore procedure and the connection settings the Moodle site uses.
How we support
- Plan a PostgreSQL backup and point-in-time recovery approach, then test a restore before go-live.
- Agree a retainer covering Moodle point releases and PostgreSQL minor releases, which ship at least once every three months.
- Review each Moodle upgrade against the PostgreSQL version it requires before the upgrade is scheduled.
