What an OpenEMR upgrade and support engagement covers
OpenEMR has no paid edition, so every upgrade, security patch and support task is work your organization either staffs internally or contracts to a partner. The engagement scope starts with an inventory of what is running now: the OpenEMR version, the PHP version, the database engine and version, and which modules are enabled. That inventory shows which upgrade path applies and how much of the work falls on your team. Several triggers push an install to act. The first is simple: any install still behind version 8. The OpenEMR project's home page told users to upgrade to version 8 by March 1, 2026 to maintain their system's active certification, so confirm that position with the project and your certification body before planning. Security releases matter as well. Version 8.3.0 (August 18, 2026) and 8.4.0 (September 13, 2026) fixed vulnerabilities in the FHIR APIs, patient portal, billing, the fax and SMS module and the fee sheet. Version 8.4.1 followed on September 20, 2026.
Platform requirements are the third trigger. Recent releases require PHP 8.3 or later and run on a MySQL- or MariaDB-compatible database. On an aging server, a PHP or database upgrade can be the largest task in the project, because extensions, the web server and the operating system may all need changes first. Ask for a written list of PHP extensions, database settings and custom code that the upgrade will touch, and record which items are tested in a staging copy before cutover. Teams usually keep this work in-house when one technical owner can read release notes, check PHP compatibility and maintain a tested staging copy that mirrors production. Bring in a partner when no one on staff can do that reliably, or when the install has fallen several major versions behind and the backlog needs a planned, sequenced path. Either way, ask the partner to state which fixed-scope deliverables and which retained support hours are included.
Confirm the current certification position directly with the OpenEMR project and with the certification body that holds your certification evidence. DeployOpen prepares systems, change records and upgrade evidence for that review, but it does not issue certifications or attestations, so the certification decision remains with those parties.
What the work includes and what you receive
Each work package is scoped in writing before work starts, and the quote follows from that scope. Ongoing support and upgrades can run as a retainer once the fixed-scope work closes.
Current-state inventory
We record the running OpenEMR version, PHP version, database engine and version, whether the install runs in Docker or on bare metal, and every custom code path, module, interface and FHIR client app that depends on it. This list sets the upgrade scope. Confirm that interface owners and FHIR app vendors are named, because their systems may need retesting after the move.
Upgrade plan and version path
The plan sets a stepwise version path from your current release to the target release and names each stop and what changes at it. Recent OpenEMR releases require PHP 8.3 or later, so the PHP move may need its own step. Confirm the target release against the current release notes before the plan is signed off.
Staging rebuild, test and restore check
The staging environment is rebuilt from the production configuration and a copy of the data, then each upgrade step is run and tested against your workflows, interfaces and FHIR apps. A backup restore is tested on the same copy, so the backup is proven before cutover depends on it. Ask how test data is de-identified and who signs off each test.
Production cutover and rollback plan
Cutover follows a written sequence: a freeze window, a final backup, the upgrade steps, smoke tests and a documented go or no-go decision. The rollback plan states the trigger conditions, the restore point and the steps to return to the prior version. Ask for the rollback to be rehearsed on staging and confirm who on your side can approve each decision.
Security patch runs and remediation
Security releases are applied in scheduled patch runs, each with a change record, a staging test and a rollback point. Alongside them, PHP and database versions are brought to the levels the running release requires, including extensions and settings that the upgrade changes. Confirm that the PHP and database versions you plan to host are still supported by the OpenEMR release you target.
Runbook, evidence and handover
Deliverables are an upgrade runbook, test evidence, a configuration record, hardening notes that point to the Securing OpenEMR guide, and a documented patch calendar. The handover passes these to your team or to a support vendor you select, with access details and escalation contacts. Ask that the hardening notes list which guide items were applied and which were deferred, with reasons.
What drives cost and duration
Each row names a factor that moves the effort of an OpenEMR upgrade or ongoing support, why it matters, and what to do to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Starting version | Each release between your install and version 8 can add intermediate upgrade steps and schema changes, and each step needs its own verification. | Document your current release from the install and database, then ask the partner to map the exact upgrade path before quoting. |
| PHP and database distance | Recent releases require PHP 8.3 or later and a MySQL or MariaDB compatible database, so an old operating system or server may need rebuilding, not just patching. | Inventory PHP, OS, web server and database versions now, and decide early whether to upgrade in place or rebuild on new hosts. |
| Custom code and forms | Local modifications, custom forms and templates may need to be re-tested or reapplied after each core change, and some may break silently. | Keep a list of every modified file, custom form and report, and prefer configuration over core edits so fewer items need reapplying. |
| Interfaces and FHIR apps | Lab, billing, imaging and third-party FHIR applications depend on API behavior, scopes and authentication, which can change between releases. | List every connected system with its endpoints, scopes and owner, then plan regression tests against each one. |
| Number of environments | Each environment such as staging, test, production and disaster recovery needs its own install, data copy, configuration and verification pass. | Limit environments to what the organization needs, automate builds, and reuse the same runbook for each environment. |
| Data volume and documents directory | Large databases and documents directories lengthen backups, migration rehearsals, restores and validation, and raise storage requirements. | Measure database size and the documents directory before planning, archive where policy allows, and test restore time on a copy. |
| User acceptance testing effort | Clinical, scheduling, billing and front-desk roles each need scripted test cases, and clinicians must confirm workflows still work before go-live. | Agree the workflows in scope in writing, assign named testers with time set aside, and reuse the same test scripts across releases. |
| Certification evidence | If the organization relies on ONC certification, it must keep records of the version in use, change history, test results and configuration that an assessor may ask to see. | Confirm with your certification body or auditor which evidence they expect, and capture it as part of each upgrade rather than afterward. |
Project phases and outputs
The sequence moves an OpenEMR install from inventory to a supported, verified version 8 with a handover the clinical and IT teams can run.
Inventory and assess the current install
We record the OpenEMR version, PHP and database versions, custom code, modules in use, interfaces, document storage and user roles. The output is an inventory register, and the step closes when the client's IT and clinical leads have reviewed and signed off the register.
Decide the target version and upgrade path
We compare the current version with the target release, check PHP and database requirements, and identify the upgrade steps and any custom code that needs changes. The output is a version path memo, which closes when the client approves the target version and the path in writing.
Build the staging environment
We build a staging copy in infrastructure the client controls, matching production's runtime, database engine, web server and interfaces as closely as the inventory allows. The step closes with a staging build record that lists versions, configuration differences and access controls.
Rehearse the upgrade with test data
We run the upgrade on staging using test data, log each step and each defect, and fix the plan where needed. Rehearsals repeat until the upgrade produces the same results on staging as the plan expects. The output is a rehearsal log that shows the final clean run.
Run user acceptance testing
Clinical and administrative users test scheduling, billing, forms, documents, interfaces and reports on the upgraded staging system against agreed test scripts. The step closes with a signed acceptance record, and the cutover window is agreed with clinical leads at this point.
Cut over to production
We follow the cutover checklist: backup, maintenance notice, upgrade, configuration checks, interface tests and a rollback decision point. The step closes when the cutover checklist is complete and the client confirms the system is live, with rollback steps still documented for the agreed period.
Verify, monitor and hand over to support
We check post-upgrade functions, logs, monitoring and backups, then transfer documentation to the client and the agreed support provider. The output is a support runbook and a handover record, and the step closes when the support model begins under the agreed responsibilities.
What teams keep in-house and what they outsource
This table shows who usually owns each part of an OpenEMR upgrade or support engagement and which skills each part requires, so you can split the work between your team and a partner.
| Work part | Usual owner | Skills required |
|---|---|---|
| Target version and certification position | Shared, led by the compliance lead | Compliance and clinical leadership, certification scope, reading OpenEMR release notes and project guidance |
| Inventory and assessment | Partner, with platform team input | Custom code, modules, interfaces, PHP and database versions, server inventory, data volumes |
| PHP and OS upgrade | Partner or platform team | Linux administration, PHP runtime and extension compatibility, change control, rollback planning |
| Database migration and backup testing | Platform engineering | MySQL or MariaDB administration, schema upgrade review, restore testing, backup retention |
| Custom code remediation | Partner or internal developer with PHP skills | PHP, OpenEMR code structure, custom forms and reports, plugin review, regression testing |
| User acceptance testing | Internal, with clinical and billing staff | Daily scheduling, charting and billing knowledge, test scripts, documented sign-off authority |
| Security release application | Internal owner, with partner support under a retainer | Release tracking, staging patch tests, server hardening checks, emergency change procedures |
| Support vendor selection | Procurement and compliance, starting from the OpenEMR wiki vendor list | Checking each vendor's stated scope and references, contract terms, data handling and BAA terms |
What usually goes wrong and how to prevent it
Most OpenEMR upgrade problems trace back to a few recurring gaps in planning, testing and ownership. Each card names the risk and the prevention step to put in place before the next release.
Upgrading production without a rehearsal
Running an upgrade for the first time on live patient data leaves no room to correct a failed migration or a broken module. Restore a recent production backup to a separate host, run the full upgrade path there, and test scheduling, billing, portal and interface flows before cutover. Record the steps and timings so the production run repeats the rehearsal.
Skipping a PHP version change
Recent OpenEMR releases require PHP 8.3 or later, so an install on an older PHP runtime cannot take the new code as-is. Custom modules, overrides and third-party libraries may fail under the new runtime even when standard pages load. Keep a version-path memo that lists each target release, its PHP and database requirements, and the test results for each step.
Delayed security releases after a published fix
OpenEMR 8.3.0 and 8.4.0 fixed security vulnerabilities in FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet. Once a fix is public, the flaw is documented in the release notes for anyone to read. Set a patch calendar that reviews each release on publication, sets a window for applying it, and records who approved any deferral.
Certification position assumed without checking
The OpenEMR website told users to upgrade to version 8 by March 1, 2026 to maintain active certification. Teams that assume their installation still counts as certified may discover the gap during a reporting cycle or an audit. Confirm your running version, the certification basis your program relies on, and the current guidance with the vendor and your certifying body before scheduling work.
Unmanaged local changes to core files
Edits made directly to OpenEMR core files conflict with each upgrade and must be reapplied or reconciled by hand. The longer they persist, the more each merge becomes a review of the whole application. Inventory every modified core file, move changes into custom modules or documented overlays where possible, and diff the result against the target release before the upgrade begins.
No named owner after handover
Upgrades and security releases stop when nobody is responsible for them after the implementation project closes. The handover should name who monitors releases, who approves an update window, who runs the rehearsal and who applies the change in production. Name owners for interfaces and FHIR app integrations too, since a core release can change the APIs those connections depend on.
How the work changes by starting point
An install on 6.x or 7.x moves through more than one release before it reaches version 8. Each step can change the database schema, configuration settings and the PHP version the release requires, so the scope grows with the number of steps and with the amount of local change on top of stock code.
- Installed version: Confirm the exact version from the admin interface and read the release notes for every version between it and the target.
- Schema changes: Plan for the database changes at each step and test them on a copy of production data.
- Runtime requirements: Check the PHP and MySQL or MariaDB versions each step needs. Recent releases require PHP 8.3 or later.
- Local changes: Inventory any edits to core files, since they must be reviewed or reapplied at each step.
- Rollback: Ask whether the quote includes a rollback point before each step and how each one is verified.
In a Docker deployment, the upgrade is mostly a change of image tags, volumes and database containers. The work is smaller than a rebuilt server when the data layout is clean, but it fails quickly if persistent data sits inside a container that gets replaced.
- Image tags: Confirm which tag the deployment pins, and whether it is managed in a compose file, an orchestration manifest or a script.
- Volumes: Confirm that the documents directory, site configuration and any uploaded files persist across container replacement.
- Database container: Decide whether the database is upgraded in place, replaced or moved to a managed external service, and take a verified backup first.
- Overrides: List environment variables, custom entry points and local configuration files that must carry over.
- Custom images: If local modules are baked into a custom image, ask how they are rebuilt and retested for each release.
A bare-metal or hand-built server often needs the operating system, PHP, the web server and the database layer rebuilt or brought current together. Because these components depend on each other, the work tends to be a parallel build and cutover rather than a simple package update.
- OS lifecycle: Confirm that the operating system is still supported through the planned service window and that it packages the PHP version the release needs.
- PHP and extensions: Inventory PHP extensions, php.ini changes and any modules compiled by hand.
- Web server: Review virtual host settings, TLS configuration and the rule set that blocks direct web access to the documents directory.
- Permissions and jobs: Record file ownership, permissions and scheduled jobs so they can be recreated on the new build.
- Cutover: Ask whether the quote includes a parallel server build, a data sync and a tested fallback to the original host.
An install with many custom forms, layouts or modules has more code to review than stock core, and each item may depend on internal APIs or database structures that change between releases. Effort rises with the number of items, with their clinical or billing impact and with how well they are documented.
- Inventory: Count custom forms, layouts, modules and report templates, and record who owns each one.
- Source control: Confirm whether custom code is in version control or only on the server, since untracked changes are the most common delay.
- Test cases: Ask whether each form or module has documented test cases for scheduling, billing and clinical workflows.
- Clinical and billing impact: Items that touch encounters, billing or patient data need more review time and sign-off.
- Ongoing ownership: Confirm who will maintain each custom item after the upgrade, whether that is your developers, an outside developer or the support vendor.
An air-gapped or restricted network changes how every package reaches the server. Upgrade files, container images, operating system packages and PHP packages must be moved in, verified and stored in an internal repository, which adds steps and approvals to each release.
- Transfer path: Confirm how packages enter the network, who approves each transfer and where the transfer is logged.
- Integrity checks: Verify each file against the checksums the project publishes, and record the results as evidence.
- Internal repositories: Mirror container images, OS packages and PHP packages into internal registries and repositories before the upgrade window.
- External calls: Identify features that contact outside services, such as update checks or single sign-on providers, and confirm how they behave offline.
- Release cadence: Ask how many transfers the support plan assumes per year and how urgent security releases are handled through the same path.
What you need to provide before work starts
Most of the schedule risk in an OpenEMR upgrade sits in inputs the client holds, not in the upgrade itself. Before scoping, provide a current system inventory that records the OpenEMR version, the PHP version and extensions, the database engine and version (MySQL or MariaDB-compatible), the operating system, and where the system is hosted, including whether it runs in Docker. The PHP and database requirements of the target release are the first thing we will compare against this inventory, so an accurate version list shortens the assessment.
Give DeployOpen read access to the application server, the web server configuration and the database, along with a restore target that can hold a full copy of production data. Confirm that backups have been restored successfully at least once, because a backup that has never been restored is not yet a recovery plan. A staging environment built to match production is also required. Plan for the staging copy to contain protected health information, and agree in advance how that data is handled, access-controlled and deleted.
Prepare a written list of local customizations, custom forms, reports, billing rules and every interface to laboratories, imaging, payers, fax or SMS services, and patient portal or FHIR API consumers. Name business owners for three decisions: who approves the schedule, who signs off billing and claims behavior, and who gives clinical sign-off after testing. Provide the maintenance window policy in writing, including which hours are acceptable and who can declare an emergency change.
Name the compliance owner who decides which certification and HIPAA evidence the organization needs. DeployOpen prepares systems, configuration records and evidence for assessments, but does not issue audit reports or certifications, and the ONC certification status of your installed version is a question for the OpenEMR project and the certifying body. Confirm the current certification position in writing before the upgrade target is set.
Frequently asked questions
Do we have to upgrade to OpenEMR 8 to keep ONC certification?
The project's stated position is yes. Its website says OpenEMR is ONC certified and tells users to upgrade to version 8 by March 1, 2026 to keep their system's certification active. Treat that as the project's statement, not a legal opinion. Confirm the requirement with your certification body before you schedule work, and ask whether the version you run today still counts. Also ask what evidence they expect after an upgrade, such as change records and retested functions.
How long does an OpenEMR upgrade take for a clinic?
No fixed duration applies, because the time depends on your starting version, how much you have customized, how many environments you run and how much testing your clinic needs. Expect the work to include a staging copy of production data, one or more rehearsed upgrades, a review of custom forms, reports and interfaces, and clinical sign-off before cutover. Ask any provider for a schedule built from your inventory of versions, custom code and environments, and check whether it includes rehearsal runs.
What does an OpenEMR upgrade cost and what affects the price?
DeployOpen does not publish a price list. A quote follows a written scope, and most of the cost is labor: inventory and planning, environment setup, upgrade rehearsals, fixes to custom code, clinical testing, cutover and documentation. Hosting, backups and any ongoing support are separate line items. Most of the upgrade effort is one-time, while support and security patching recur. Ask for the work broken into these phases, the assumptions about your starting version and customizations, and a list of exclusions.
Can our own team upgrade OpenEMR alone, and what must we provide?
Yes, if your team has the skills and time to do it safely. You need PHP and web server administration, database administration for a MySQL- or MariaDB-compatible database, and working knowledge of OpenEMR configuration and any custom code. Recent releases require PHP 8.3 or later, so check your runtime first. You will also need to provide a current backup, access to servers and the database, a list of customizations and interfaces, named clinical reviewers, a cutover window and a rollback plan.
How does OpenEMR handle security releases, and who applies them?
The project publishes releases on GitHub, and recent ones fixed security vulnerabilities. OpenEMR 8.3.0 and 8.4.0 addressed issues in FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet. Someone on your side must monitor releases, test them against your setup and schedule the update, whether that is your team or a support partner. Ask a provider how they review releases, how they test them against your customizations and how they report results to you.
Is an OpenEMR support retainer better than a one-off upgrade?
Neither is better in general. A one-off upgrade fits a defined move from one version to another, with a fixed scope and end point. A retainer fits ongoing needs such as applying security releases, reviewing changes to PHP and database requirements, handling support requests and planning the next upgrade. Ask each provider what the retainer includes, how release reviews and testing are scoped, how urgent security fixes are handled and how a one-off upgrade is priced if it falls under an existing retainer.
How DeployOpen scopes, delivers and supports OpenEMR upgrades
DeployOpen plans, performs and documents OpenEMR upgrades inside the client's own infrastructure, from scoping the move to version 8 through handover and ongoing support. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Inventory the current OpenEMR version, PHP version, database engine and hosting so the upgrade path is confirmed before work starts.
- Record the modules, custom forms, interfaces and third-party FHIR apps in use, since each one needs a compatibility check.
- Agree the written scope, deliverables and timeline with the client before any change is made to a production system.
How we build
- Stand up a staging copy of the production database and files, then run the upgrade there first to surface issues.
- Test scheduling, billing, patient portal, FHIR APIs and document handling against the client's own test scripts and data.
- Document each change, rollback step and configuration decision so the team can repeat the upgrade for later releases.
How we hand over
- Deliver a runbook covering the cutover sequence, verification checks, backup restore tests and rollback procedure.
- Provide configuration records and a list of open items, including any PHP or database requirements the client must confirm with its hosting team.
- Walk the client's administrators through the post-upgrade checks and the process for applying future security releases.
How we support
- Offer ongoing support as a retainer covering security release reviews, patch application and troubleshooting after go-live.
- Track the vendor's release notes and certification guidance so the client can plan each upgrade before a deadline applies.
- Confirm with the client which compliance evidence, such as change records and test results, its assessors will expect from each upgrade.
