When OpenMRS upgrades and support need a planned owner
Most OpenMRS operators who stall on an upgrade or cannot name who applies patches still run the work in-house, usually because the clinical IT team or a national program's technical lead has been carrying it informally. A partner becomes the practical choice once that informal arrangement breaks down, and the first question to settle is who is accountable for each upgrade and each patch, whichever way the work is staffed. The reason ownership falls to the operator is structural. OpenMRS Inc. is a 501(c)(3) nonprofit that provides the fiscal, legal and infrastructure foundation for the project, and the volunteer community and implementer organizations build and deploy the software. There is no vendor with a support contract that issues patches to a named customer and tracks their installation. OpenMRS has no paid edition, so the deployment team has to watch release channels, read release notes and decide when to act.
Four kinds of events usually trigger upgrade work. A new OpenMRS Platform or O3 release arrives. A module that your site depends on publishes an update, sometimes one that changes configuration or database structure. A security patch is released for the core or a module. Staff turnover removes the person who knew why the site was configured the way it is. Each trigger needs a named decision owner, a review step and a way to test before production, or the site drifts onto an unsupported combination of versions.
Planning cannot wait for a convenient moment. The latest OpenMRS Platform is 2.8.1, released October 7, 2025, and the latest O3 Reference Application is 3.7.1, released July 13, 2026. Sites on older builds have a growing gap to close, and the longer the gap, the more module versions, database changes and configuration differences the upgrade must cover at once. Ask your team to confirm which Platform or O3 version each site runs today, which modules are installed and at what versions, and which release channel each site is subscribed to.
Before anyone signs a scope, write down the ownership model in four lines: who receives release and security notices, who decides whether a patch or upgrade is applied, who tests it against a copy of the site database, and who signs off the production change. If your organization can fill all four roles, in-house support is a reasonable choice. If one or more roles has no realistic owner, that gap is the scope a partner should be asked to cover, and it should appear in the written proposal as named responsibilities rather than as general support hours.
What OpenMRS upgrades and support include
An OpenMRS upgrade touches the core Platform or O3 Reference Application, every installed module and the database, and the work is sequenced so that each step produces evidence the next step depends on. The cards below cover the work packages in order, followed by the deliverables you receive and the boundaries that sit outside this service.
Current version and module assessment
We record the running Platform or O3 Reference Application version, the database engine and version, the Tomcat or Jetty runtime, and every installed module with its version and source. This sets the upgrade baseline. Check whether any module is custom-built, forked or no longer maintained upstream, because those modules set the upgrade effort more than the core does.
Upgrade plan and target versions
The plan names the target Platform or O3 release, the path between versions, and the order of changes to the core, modules and database. It states which items are blocked by a dependency and which need a decision from your clinical or informatics lead. Ask the team to confirm the target release against the official download page on the day the plan is approved, since current versions change.
Test environment build
We build a non-production environment that matches production in server layout, runtime, database engine, module set and configuration. A test environment that differs from production in any of these will hide the failures you most need to find. Confirm who owns the environment after the engagement ends, and whether it holds a copy of patient data and how that copy is protected.
Module compatibility testing
Each installed module is tested against the target core, including custom forms, FHIR2 and SMART on FHIR modules, and any authentication module such as OAuth2 Login. Results are logged per module with pass or fail and the steps used. Modules without an upstream release for the target version are flagged early, because they decide whether the upgrade can proceed or needs a replacement.
Database schema change review and backup verification
We review the schema changes the upgrade applies, including any changes made by modules, and confirm the database engine version is supported by the target release. A full backup is taken and restored into the test environment before any production change, so the restore path is proven. Ask who signs off on the schema review and where the backup is stored during the cutover window.
Staged cutover and post-upgrade checks
Production is upgraded in a planned window using the runbook, with a go or no-go checkpoint before the change starts. Post-upgrade checks cover login, record search, form entry, FHIR endpoints, scheduled tasks and the gateway and TLS configuration. Ask whether your site needs a read-only period, and who on your side confirms that clinical workflows work before the window closes.
Ongoing support tiers
After cutover, support covers triage of incidents, module patching, and planned upgrades on the agreed cycle. Support tiers differ in response expectations, hours covered and what is included, so compare written terms rather than general descriptions. Confirm the response times and escalation path in the support agreement before signing.
What drives OpenMRS upgrade cost and duration
This table lists the factors that most change the effort of an OpenMRS upgrade, why each one matters and what to do to keep it contained. Use it to see which parts of your estate will push a quote up and which decisions you can make before work starts. The main takeaway is that module divergence, the gap between versions and clinical testing usually matter more than server size.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom and community modules | Each module built against an older platform API may need code changes, rebuilds and its own regression checks. Heavily forked modules add the most work. | Inventory every module with its version and fork status. Upstream changes where possible and retire modules the current release already covers. |
| Gap between current and target version | A jump across several platform releases can change APIs, database schema and module compatibility at once, so the work compounds. | Plan stepwise upgrades where the release notes call for them, and confirm the target release line before scoping. |
| Deployment stack | A WAR on Tomcat with MySQL or MariaDB, a PostgreSQL setup, the O3 Docker Compose stack and a custom distribution each have different build, packaging and rollback steps. | Standardize on one deployment method across sites and document the exact build and configuration baseline. |
| Number of sites and environments | Each site, plus development, test and staging copies, multiplies configuration checks, deployment runs and data validation. | Build one scripted deployment pipeline and promote the same artifact through every environment. |
| Volume and age of data affected by schema changes | Large or long-lived databases take longer to migrate, need more rehearsal and carry more risk if a migration fails partway. | Measure database size before scoping, rehearse migrations on a recent restored copy and confirm backup and restore timings. |
| Integrations, including FHIR2 and SMART on FHIR | Interfaces to laboratory, pharmacy, identity providers and FHIR2 or SMART on FHIR apps depend on API behavior that can change between releases. | Inventory each integration and its consumers, then add contract tests for the FHIR endpoints and app launch flows you rely on. |
| Clinical testing hours | Clinical staff must verify workflows, forms and reports against the new version, and that time is often the longest item on the plan. | Agree a risk-based test script early, reuse scenarios from earlier cycles and ask clinical leads to commit reviewers before the schedule is fixed. |
| Form and metadata changes | Custom forms, concept dictionary changes and any move to the O3 form schema need conversion, review and retesting. | Freeze metadata for the upgrade window and confirm which forms will be converted, rewritten or retired. |
How an OpenMRS upgrade moves from assessment to cutover
The sequence takes an OpenMRS deployment from a known inventory of modules, data and users to a verified production system, with a written output at each phase so the client can confirm progress before the next one starts. Each phase is a gate, and a failed gate sends work back rather than forward.
Assess the current system and inventory every module
DeployOpen reviews the running OpenMRS version, the Platform or 2.x distribution in use, every installed module and its version, custom forms, concept and metadata customizations, database engine and size, integrations, and the hosting setup. The output is a written inventory that lists each module as kept, replaced, upgraded or retired, with the owner of each decision. The step is done when the client has signed off the inventory, because every later phase depends on it. Ask the team that maintains local customizations to confirm the list is complete, since undocumented changes are the most common source of surprises.
Choose the target version: Platform or O3
The client and DeployOpen decide whether the target is an upgraded OpenMRS Platform (the current release is 2.8.1, released October 7, 2025) or the O3 Reference Application (the current release is 3.7.1, released July 13, 2026). The choice depends on whether the site uses custom HTML forms, which modules have O3 equivalents, and how much user retraining the clinics can absorb. The output is a short decision record that names the target version, the modules that must be confirmed for it, and the reasons. Confirm module compatibility against each module's own repository before this record is signed, since release dates alone do not establish compatibility.
Rebuild the environment from a copy of production data
DeployOpen builds a non-production environment that matches the production hosting, database engine (MySQL, MariaDB or PostgreSQL), servlet container and network path, then loads a copy of production data that has been handled under the client's data protection rules. The output is a running staging system with a recorded build procedure, so the production cutover repeats steps that have already been executed. Time spent on this phase depends mainly on the size of the database, how many customizations must be reproduced by hand, and how quickly the client can approve the data copy. Confirm where the copy is stored and who can access it before any data is moved.
Test modules, database changes and migrations
The team applies the upgrade to the staging copy and runs schema and data migrations, then checks each module for startup errors, failed migrations and changed behavior in forms, concepts and reports. Database changes are checked against row counts and sample records before and after migration. The output is a defect log in which every item is either fixed, accepted with a named owner, or scheduled for a later release. This phase ends when the migration runs cleanly from start to finish on a fresh copy of the data, not only on the first attempt.
Run clinical acceptance testing with named users
Clinicians, data clerks and the people who run reports work through the scripted scenarios that matter at their sites, such as registering a patient, recording an encounter, ordering a test, and pulling a monthly report. Each scenario has a named tester and an expected result agreed in advance. The output is a signed acceptance record listing each scenario, the tester, the result and any open issues with a clinical risk rating. Acceptance is not complete while a scenario that affects patient care remains failing. Ask the client to confirm who has authority to sign for clinical acceptance before testing begins.
Rehearse the cutover runbook end to end
The full production cutover is rehearsed on the staging environment using the written runbook: the sequence of backups, service stops, migrations, configuration changes, smoke tests and the rollback path. Timings are recorded during the rehearsal, which gives the team a realistic window for the real event. The output is a runbook revised from the rehearsal, with each step marked with its expected result and the person responsible for it. A rehearsal that required improvised steps is not complete, and the runbook is revised and rehearsed again.
Perform the production cutover
On the agreed date, the team takes a verified backup, stops the application, runs the tested migration, applies the configuration, and starts the new version. Smoke tests confirm login, record access, form submission and report generation before users are told the system is available. The output is a cutover log with start and end times, the backup identifier, and a signed record that the smoke tests passed. If a smoke test fails, the rollback path in the runbook is used and the reason is recorded. The duration of the outage window is set by the migration size and the number of manual checks, so the client should ask for it to be stated in the quote and confirmed in the rehearsal results.
Support the system through hypercare
For an agreed period after cutover, DeployOpen monitors logs, watches for errors reported by clinics, fixes defects and tracks support tickets against the defect log. The length of hypercare is set in the written scope, and the client should ask how it ends. The output is a closure report listing defects resolved, defects carried forward, and the handover to the ongoing support arrangement, whether retainer or internal. Hypercare closes only when the client's named support owner accepts the handover in writing.
What goes wrong in OpenMRS upgrades and how to prevent it
Most OpenMRS upgrade failures come from software that was never tested against the exact target version, data that cannot be restored, or ownership that ends at go-live. Each card below names one pattern, the prevention step, and the evidence to request before a change goes near patient data.
Module with no target-version release
Many OpenMRS deployments depend on community or implementer modules. A module may have no build for the platform or Reference Application version you plan to move to, so the upgrade stalls or runs without it. Before scoping, list every module in use, its current version, and whether a release exists for the target. Ask for the module's release notes and a passing build against that exact target.
Custom code on changed internal APIs
Custom modules and extensions often call internal OpenMRS classes or services that a newer release has removed or changed in behavior. The code may compile yet fail at runtime in a clinical workflow. Prevention means a code review against the release notes for each version crossed, plus a regression run of every custom feature in a staging copy. Ask the implementer which internal APIs the code touches and where each one is documented as changed.
Database changes without tested rollback
Schema and data migrations in OpenMRS can be hard to reverse once patient records are written under the new structure. A change applied without a tested rollback leaves little recovery path if validation fails. Take a full database backup immediately before the change, restore it to a separate environment, and rehearse the rollback there. Ask for the restore log, the time the restore took, and the signed record of who approved the cutover.
Forms and O3 changes that surprise clinicians
Moving to the O3 frontend changes navigation, layouts and form behavior, and forms built for legacy HTML may not render or save as expected. Clinicians who lose a field or a shortcut during a shift lose time and may enter data incorrectly. Build a form inventory, convert and test each form against realistic encounter scenarios, and run short sessions with the clinical staff who will use them. Ask for a form-by-form test log with sign-off from a named clinical lead.
FHIR and SMART integrations that stop working
Integrations that read or write through the FHIR2 module or launch apps through the SMART on FHIR module depend on exact module versions, authorization settings and identity provider configuration. An upgrade can change resource mappings or break token flows without any visible error on the OpenMRS side. Keep a list of every connected system, test each read, write and app launch after the upgrade, and confirm the authorization server configuration. Ask for the endpoint test results and the version pairings used.
No named owner after go-live
OpenMRS has no vendor support contract to fall back on, so when an upgrade is finished and the implementer leaves, nobody may own patching, module updates or incident response. Problems then surface months later with no one assigned to diagnose them. Before go-live, name an owner for platform, modules, database and integrations, and agree how they will receive security notices and release announcements. Ask for a written support handover with contact roles, escalation steps and the schedule for the next upgrade review.
Which parts of an upgrade your team keeps and which a partner takes
This table shows who usually owns each part of an OpenMRS upgrade and which skills each part requires. Read it as a starting point for dividing work between your team and a partner, then confirm the split against your own staff and contracts. The main takeaway is that clinical and data decisions stay with your organization, while build, testing and triage work is often the easiest to hand to a partner.
| Work part | Usual owner | Skills needed |
|---|---|---|
| Clinical sign-off | In-house | Clinical leads who can confirm forms, workflows and care pathways still work after the upgrade |
| Data owner decisions | In-house | Data owners who decide retention, data cleanup, concept mapping changes and who may access records |
| Module inventory and compatibility testing | Partner, or in-house with Java and Maven skills | Java and Maven builds, module version checks against the target Platform or O3 release |
| Database schema review and backup testing | Partner with DBA support | Database administration for MySQL, MariaDB or PostgreSQL, and restore testing on copies of production data |
| Environment build and deployment automation | Partner | Tomcat or Jetty configuration, container setup, scripted deployment and rollback steps |
| Cutover support | Shared | Partner runs the technical cutover while in-house staff coordinate sites, users and downtime communication |
| Ongoing triage across community channels | Partner under retainer | Experience reading community issue trackers and forums, and judging whether a fix applies to your version and modules |
Who answers for OpenMRS when there is no vendor
OpenMRS has no vendor that sells a supported edition, so the operator has to decide who does the work a vendor would normally own. OpenMRS Inc. is a 501(c)(3) nonprofit that provides the fiscal and legal foundation and shared infrastructure for the project, and the OpenMRS platform is released under the MPL 2.0 with a Healthcare Disclaimer. The nonprofit does not sign a support contract for your deployment. The code is maintained by a volunteer community, and the deployments are run by implementer organizations and partners. OpenMRS has no paid edition, so no one is contractually obligated to answer your ticket by default. Before the first upgrade, write down who is accountable for each function below.
Four roles need a named owner. The first is triage: someone must decide whether a defect is in OpenMRS core, in a community module, in your concept dictionary or metadata, or in your own configuration, and then decide where it goes. The second is module release testing: each module you run (for example, the FHIR2 module, the SMART on FHIR module or the OAuth2 Login module) has its own release cycle, and someone must test the combination against your Platform or O3 version before it reaches production. The third is server access: who holds the Tomcat or container host credentials, the MySQL, MariaDB or PostgreSQL administrator account, the Nginx gateway configuration and the TLS certificates. The fourth is patch sign-off: a named clinical or operational lead should approve each change to a system that holds patient records, with the technical owner recorded alongside.
A retainer with a partner is the usual way to cover these roles without a vendor. In general terms, a retainer can include scheduled reviews of new OpenMRS Platform and O3 releases and module updates, monitoring of the application, database and host, and defined channels for reporting incidents with an agreed route to the partner's engineers. The retainer should state what the partner does during regular hours, what happens out of hours, which events count as urgent, and who on your side can authorize a change. Response times must be written into the agreement and confirmed with the partner. Do not assume a community forum post, a chat message or an informal email counts as a response commitment, because none of those is a contractual obligation.
When you request a quote, ask the partner to map each role in this section to a named person or team on both sides, and to attach that map to the scope. Ask how the partner tests module combinations before applying them to your environment, how it keeps a rollback path for database changes, and where backups are stored and tested. Confirm which versions the partner will support and how long it will keep supporting an older release while your team plans an upgrade. Illustrative example: if a fix lands in a community module that your site uses for patient lookup, the agreement should say who checks the fix in a staging copy, who approves it, and who has the authority to hold the rollout if the fix breaks a form.
How the upgrade path changes by OpenMRS deployment type
Standalone deployments usually run the OpenMRS Platform as a WAR file on Apache Tomcat, connected to an existing MySQL database. The upgrade centers on replacing the WAR, applying database changes that the new core version requires, and reconciling the module set with what the new platform version supports. Because the application server and database are often hosted by a local IT team, the first task is to confirm exactly which versions are running today.
- Inventory the running WAR, Tomcat and MySQL versions and the full list of loaded modules, including any custom modules built for this site.
- Confirm module compatibility with the target Platform release before touching the WAR, since modules are not guaranteed to load on a newer core.
- Take a verified database backup and test a restore on a separate server so rollback is known to work.
- Run the upgrade in a staging copy with a production-sized database to observe how long schema changes take and whether any fail.
- Confirm Tomcat and Java requirements for the target release with the OpenMRS documentation, and check the Tomcat configuration for any settings the new version changes.
Partners working on this type need read access to the server configuration, a copy of the database for staging, the module list, and a maintenance window agreed with the clinical sites that use the system.
The O3 Reference Application runs from a Docker Compose setup with four services: a MariaDB database, the OpenMRS backend, an Nginx frontend serving the 3.x modules, and an Nginx gateway. A Certbot service for SSL certificates is optional. Upgrades touch the images and configuration for several services at once, so the path is a coordinated change across the stack rather than a single component swap.
- Pin the current image tags and the Compose file so the running state can be restored exactly if the upgrade fails.
- Test the gateway on upgrade. Routing rules, headers and upstream paths between the frontend, backend and gateway can change between versions, and failures often show up as blank pages or login loops.
- Test the Certbot renewal path if it is in use. Confirm that certificates still renew and are picked up by the gateway after the containers are recreated.
- Back up the MariaDB volume and the backend configuration and verify the restore in a separate environment.
- Check the micro-frontend module versions against the distribution release notes, since the frontend and backend must match.
Partners need access to the Docker host or orchestration platform, the Compose and environment files with secrets handled through the client's own store, the TLS certificate setup, and a staging environment that mirrors the gateway's public address.
National programs and implementer-built distributions, such as KenyaEMR-type builds, package OpenMRS with their own modules, forms, metadata and configuration. The upgrade is governed by the distribution owner's release cycle as well as the OpenMRS Platform release, so the first question is which version the distribution targets and whether the distribution maintainer has published an upgrade for it. Custom code can make the upgrade path longer than the core platform change alone.
- Identify the distribution version and its base Platform version, and check whether the distribution maintainer has released a supported upgrade.
- Map every custom module and forked component and confirm each one builds and loads against the target version.
- Review metadata and form definitions for changes that need migration, since concept and form changes can break data entry.
- Agree on who owns the distribution code and whether the national or program team must approve the target release before deployment.
- Run a regression pass on clinical workflows such as registration, encounters and reporting, not only startup checks.
Partners need access to the distribution source repository, build pipeline, custom module code, the metadata and form configuration, and a named contact on the distribution team who can approve decisions that affect national reporting.
What you provide before an OpenMRS upgrade starts
Access comes first. Before any upgrade work begins, the team needs administrative access to every server or cloud account that runs OpenMRS, including the Apache Tomcat hosts that serve the WAR file and the Docker hosts that run the O3 Reference Application Compose stack. Ask for the database account with rights to dump and restore, the MariaDB, MySQL or PostgreSQL instance behind the application, and the gateway configuration that terminates TLS in front of the frontend. Confirm who holds root or sudo credentials and whether they can be issued for the length of the project. If access arrives late, the early weeks go to locating hosts and credentials instead of testing the upgrade path.
A recent, complete backup is the rollback plan, so confirm when it was taken and that it covers the application database and any file storage the deployment writes to. Ask the client to show that a restore has been tested on a separate host, because an unverified backup gives no rollback option. Test environments also need data that behaves like production, which means copying patient records. The client must approve that copy under its own privacy rules, and the approval should state who may access the copy, whether identifiers are masked, where the copy is stored and how it is destroyed after testing. Without that approval, testers work on sanitized or synthetic records and miss the problems that appear with historical data and long-running concept usage.
Modules usually break an upgrade before core does. Provide a complete inventory of installed modules with their versions and sources, the distribution or reference application version in use, and every forms or metadata package that has been loaded. Mark any modules built in-house. If the FHIR2, SMART on FHIR or OAuth2 Login modules are in use, list them explicitly, since they depend on each other and on identity configuration. State the target platform version the client wants, then confirm whether each module has a release compatible with it. A module without a compatible release becomes a decision to replace, rebuild or remove, and that decision needs an owner before the test cycle starts. Missing inventory means these gaps surface during the change window.
Custom code and integrations need the same level of detail. List every custom module, patch, SQL script and Tomcat or container configuration change, and name the person who maintains each one and can answer questions during testing. For integrations, provide each endpoint with its address, the authentication method, the expected message or payload format and a named contact on the receiving side who can run a test. This may include laboratory, pharmacy, national registry or payment systems. If a partner system cannot be reached from the test environment, the test will pass without exercising that interface, so ask the client to confirm test access for each endpoint in writing.
Clinical testing and decisions need named people. Ask for clinical testers who can sign off workflows such as registration, encounters, orders, results and dispensing, and confirm that they will have time in the schedule. Name a decision owner with the authority to approve or stop the go-live, and agree the go or no-go criteria in writing before the change window opens. Finally, confirm the change window itself: the date, the hours, how sites will be notified, when configuration changes freeze and the latest time a rollback decision can be made. If clinic hours or a national program calendar constrain the window, record those limits now so they do not shorten the testing period later.
How much do OpenMRS upgrades cost and how long do they take?
What determines the cost of an OpenMRS upgrade?
The cost depends mainly on how much of the system changes, not on the license, because OpenMRS has no license fee. The main drivers are:
- Module count: every installed module must be checked for compatibility with the target version.
- Version gap: moving across several platform releases usually means more deprecated code and configuration to review.
- Integrations: interfaces with laboratory, pharmacy, FHIR consumers or identity providers each need their own regression testing.
- Environments: development, test, staging and production each require a deployment and a verification pass.
- Testing hours: clinical sign-off time is often the largest and least predictable component.
Ask any partner for a quote built from a written scope that lists these items individually.
Can our own team upgrade OpenMRS without an outside partner?
Yes, if your team has the skills the platform requires. The OpenMRS core is written in Java and built with Maven, runs on Tomcat or Jetty, and uses MySQL, MariaDB or PostgreSQL. Your team needs:
- Java and Maven experience to build and patch the WAR file or module set.
- Database skills to back up, run schema changes and verify data after the upgrade.
- Clinical testers who can confirm that forms, orders and reports still work for real workflows.
- Someone who can read module release notes and decide which modules to update, replace or remove.
If one of these is missing, a partner can cover that part of the work while your staff keep ownership of the system.
What does our organization need to provide for an upgrade?
Most of the client input is access and decisions, not engineering time. Expect to provide:
- Access: accounts for the cloud, data center or air-gapped environment, plus database and Tomcat administration rights.
- Data decisions: choices about which records, concepts, forms and metadata must be preserved, retired or migrated.
- Testers: named clinical and operational staff with time booked for scripted test rounds and sign-off.
- Change windows: agreed maintenance periods for each environment and a rollback owner.
The written scope should name these inputs and who provides each one, so that delays are visible before work starts.
What does an OpenMRS support retainer cover?
A retainer is an ongoing agreement for work that happens after go-live, rather than a one-time upgrade project. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask each provider to state in writing:
- Which platform and module versions are covered.
- How security patches and module updates are reviewed, tested and deployed.
- How backups are verified and how incidents are triaged and escalated.
- What is excluded, such as new feature development or on-site visits.
- How hours are counted and what happens when they run out.
A retainer is recurring, while the initial upgrade is one-time, so compare both costs over the period you plan to run the system.
How should we compare OpenMRS upgrade quotes from different partners?
Compare the scopes first, then the prices, because quotes that look far apart often cover different work. Check each quote for the same items: the target version, the list of modules, the environments included, the testing approach, the data migration tasks, the client inputs assumed and the handover documentation. Also confirm:
- Whether the quote is fixed-scope with written deliverables and timelines.
- Who performs clinical testing and whether it is included.
- What happens if the module count or version gap changes after signing.
- Whether the partner can produce a rollback plan and a post-upgrade verification checklist.
A quote that leaves these points open is harder to hold to account than one that names them.
What if no vendor exists to upgrade our OpenMRS system?
OpenMRS has no vendor in the commercial sense. It is released under the MPL 2.0 with a Healthcare Disclaimer, and OpenMRS Inc., a 501(c)(3) nonprofit, provides fiscal, legal and infrastructure support alongside a volunteer community and implementer organizations. Because there is no paid edition, support comes from the community and from the partners and implementers who deploy the software. In practice this means:
- Your upgrade plan relies on public release notes, the community and your chosen implementer.
- You remain responsible for choosing versions and for testing them in your own environment.
- A written support agreement with a named implementer replaces the vendor commitment that a commercial product would normally provide.
Confirm these responsibilities in writing before any upgrade starts.
Which OpenMRS versions should we target when planning an upgrade?
Choose the target based on your current architecture, then confirm the version with the release notes on the day you plan. At the time of writing, the latest OpenMRS 3.x Reference Application is 3.7.1, released July 13, 2026, and the latest OpenMRS Platform is 2.8.1, released October 7, 2025. Before you pick a target, confirm:
- Whether you run the Platform as a WAR file on Tomcat with MySQL, or the O3 frontend in its Docker Compose stack.
- Whether your modules have releases compatible with the target version.
- Whether your custom forms need conversion to the O3 form schema.
Ask your partner to document the version choice and its reasons in the scope.
How DeployOpen scopes, delivers and supports OpenMRS upgrades
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For OpenMRS, that means a written scope for each Platform or O3 Reference Application upgrade, tested module and database changes, and a documented support arrangement for software maintained by a nonprofit community. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Written scope names the OpenMRS component, the current version and the target version being upgraded.
- Scope lists installed modules, custom forms, metadata and the database engine (MySQL, MariaDB or PostgreSQL) to carry through.
- A fixed-scope agreement sets deliverables, acceptance tests and timelines in writing before any upgrade work starts.
How we build
- Upgrades run first in a staging copy of production, built on the same Tomcat or Docker Compose layout.
- Module compatibility is tested one module at a time, including FHIR2, SMART on FHIR and OAuth2 Login where in use.
- Database changes are reviewed and rehearsed, with a verified backup taken beforehand and a tested rollback path.
How we hand over
- Deliverables include an updated build runbook, a module inventory and a record of every configuration change made.
- Operators are trained on the Docker Compose services or Tomcat deployment they will maintain after handover.
- Upgrade test results and the cutover checklist stay with the client, in its own infrastructure and repositories.
How we support
- Ongoing support is available as a retainer covering patching, module updates and planning for new OpenMRS releases.
- Support includes tracking openmrs-core and module release notes, with any resulting changes scoped and quoted before work starts.
- Ask whether the retainer covers the database, reverse proxy certificates and backups, and who answers incidents.
