on click brings up contact window
Best PracticesCernereCWEHREpicNextGen

How to Successfully Catch Up on Overdue EHR New Version Upgrades

Shana Tachikawa and MacKenzie Gonnelly

August 19, 2026

Healthcare organizations continue to balance competing priorities, including EHR optimization, AI adoption, cybersecurity initiatives, workforce challenges, and operational efficiency efforts. As a result, many have delayed planned EHR version upgrades, now facing the challenge of completing multiple-version jumps to remain current.

Staying up to date on EHR releases is about more than gaining access to new features. Modern upgrades often include important security enhancements and interoperability improvements that support organizational performance and compliance requirements. Additionally, added AI-driven functionality can support faster documentation and enhance workflows that allow clinicians to spend more time focused on patient care.

Whether upgrading an internally hosted EHR or coordinating with a community-based platform, healthcare organizations may need to perform double or triple-version upgrades to catch up. This blog explores how to effectively manage overdue EHR system new version upgrades without sacrificing operational success, quality testing or vendor compliance.

Best practices for performing double/triple version EHR upgrades

There are several considerations when planning a multi-jump EHR version upgrade. The first is understanding how many upgrade items will be within the scope of the project. It’s crucial to determine which upgrade items the vendor automatically turned “on” versus those that internal IT teams must fully activate to deploy.

Then, to smooth the processes involved in planning and making multi-jumps, adopt these best practices for multi-version upgrades:

  • Maintain an internal software functionality testing team. Preview the upgrade documentation early on–during planning–to identify which members of your upgrade team you need for the release’s testing and approval. Non-IT staff should be involved from the start of upgrade planning, too, so they understand the upgrades’ scope and how much testing they will need to do.The team should include IT analysts and top end users to ensure the upgrade addresses both technical and “workability” needs. While analysts can do simple testing on the system, key non-IT department staff should be responsible for testing. Their working knowledge of the applications’ daily operations is critical. Plus, not only can a blended team help the IT department gain traction during the upgrade rollout, but it can also build cross-organizational support for future IT initiatives.
  • Map out and test the impact on coordinating systems and applications. When the upgrade item scope list is complete for each version, the next step can be initiated. For each item on your scope list, upgrade teams will need at least four testing scenarios. These include:
    • Simple forward testing to ensure the item works as expected according to the upgrade documentation.
    • Simple backward regression testing to ensure the item doesn’t cause an unintended result or consequence.
    • End-to-end testing within the application (no interfaces) to ensure the logic of the item is fully maintained, and it works within that functional pathway.
    • End-to-end testing with interface messaging to respective downstream system targets. This test scenario ensures that necessary downstream applications receive the appropriate information, while downstream applications that should not receive an interface message do not receive one. This is especially important when interface messaging traffic is controlled by logic within the interface engine rules and/or where table values are used to determine messaging targets. (Note that if a single test scenario cannot be developed for this step, interface validation will require multiple scenarios.)
  • Designate responsibilities. Pre-event planning is particularly beneficial for applications that cross multiple departments. When end users know what to expect, ticket counts stay low. So, outline a deliberate communication schedule utilizing multiple communication channels to deploy at least two weeks before the go-live date. For example, system notifications, email communications, collaboration platforms, staff meetings, and targeted end-user training can ease communication and keep others informed of the go-live event date and time.Key players’ responsibilities also should be determined well ahead of the date. Consider designating an event leader once testing is complete. The leader should be very familiar with IT protocol and the application itself. This will be quite valuable if something unexpected happens that needs a quick decision.
  • Schedule the go-live timeframe carefully. Timing of the actual upgrades’ go-live event requires special contemplation. It’s useful to set a tentative target date before initiating testing. The date can then be reviewed midway through testing and moved if needed. When scheduling a go live, focus on the fact that successful testing takes time, and that testing success is more critical than achieving a pre-selected go-live date.If the application is mission-critical, selecting a go-live date and timeframe compels healthcare leaders to think about which departments rely on the application for patient care. HIT leaders must account for shift changes, as well as routine department activities (e.g., end-of-month reporting) that might be impacted. They should also consider other IT initiatives, including planned maintenance windows, security updates, regulatory deadlines, and organizational cybersecurity projects that could affect timing or resource availability.End-user usage times can help select the least disruptive go-live timeframe. Healthcare leaders also should press the EHR vendor for a solid idea of how long the downtime will last. The go-live date should be planned and coordinated with the health system’s EHR vendor support staff. If the application is hosted within the vendor’s data center, the vendor team will need to be heavily involved in the date selection process. Healthcare organizations that host their application locally still should have vendor support staff ready in case something arises during the go live that requires their assistance.Four Best Practices for Coordinating EHR Vendor Relationships and Software System Upgrades
  • Keep up the communication and centralize user support. Staff for the upgrade event should include participants from the vendor, IT staff who support the application, at least one member from the interface team, and non-IT staff from crucial departments who will perform the final live scenario. At least two days before the event, go-live leaders should hold one last planning call to answer any outstanding questions from participants.During go live, run a bridge conference line to keep those involved both aware and working in unison. Have a small team of critical end users perform a few operational testing scenarios before releasing the environment to all end users. This last-stage testing usually is 100% successful when teams have done adequate preparation and planning.

Successfully navigate go-live demands with a dedicated Go-Live Command Center designed to absorb surges in end-user support requests and training needs. By rapidly scaling support during critical transition periods, a Go-Live Command Center minimizes operational disruption, improves user adoption, maintains productivity, and relieves pressure on your internal IT team. Immediate access to these experienced healthcare IT resources helps keep issues from escalating, enabling a smoother go-live and faster realization of value from your new system or upgrade.

Ultimately, the goal of any multi-version upgrade is to validate new functionality without compromising existing operations. Although vendors thoroughly test each release prior to deployment, only your healthcare organization can evaluate how changes will impact your day-to-day workflows, integrations, and end-user experiences. A disciplined testing strategy that includes clinical, operational, and technical stakeholders is critical for reducing risk.

Using these best practices, healthcare leaders can achieve the ultimate success: a multi-version new upgrade event praised by end users as a “non-event.” The most successful upgrade initiatives balance technical execution with strong communication, organizational alignment, and stakeholder engagement. By working collaboratively across clinical, operational, and IT teams, HIT leaders can maximize the value of their EHR investments while positioning their organizations to take advantage of future innovations.

To learn more about EHR new version upgrade Go-Live Call Command or training support, contact the MTS team.