You know what I love? The back-up camera on my car. Once considered a luxury you may not have even imagined, these cameras have become a standard safety feature, helping drivers (like me) avoid multitudes of injuries and harm. Moving to the latest release of Epic is a little like that, offering safety features and efficiencies you may not even realize are possible. Whether you’ve been on Epic for decades or a couple of months, you know that the latest version will allow you to be more effective and improve care.
When approaching your first upgrade, you’ll likely have many questions, with the main one being “How can I ensure that my upgrade goes smoothly?” This post will give you an overview of upgrades, the general structure of an upgrade project, and then five critical steps that, if included in your project, will help you upgrade as smoothly as possible. Let’s dig in.
Upgrades Defined
An upgrade is, in simple terms, a move from one version of Epic to a newer one. Because of the complexity of most hospital systems (hardware, software, interfaces, number of sites and end users, etc.), an upgrade requires a substantial amount of resources, effort, and time. The typical Epic upgrade takes anywhere from 6-9 months, depending on if it's an upgrade to the next release or an upgrade more than one release forward from your current release (example: version 2014 to 2015, or 2014 to 2016).
Your first upgrade? There's good news
For Epic clients undertaking their first upgrade, the good news is that Epic continually improves its upgrade documentation, support, and tools, and with a strong project manager (preferably with upgrade experience), an upgrade is very manageable. Epic has an upgrade project plan, and a great deal of Galaxy documentation regarding upgrades is available on the Epic UserWeb.
Structure of an upgrade
The structure of an upgrade is very similar to a normal implementation, and for many Epic clients, it can feel like one as well, with the finish being similar to a go-live. Here’s a summary of the phases of an upgrade:
- Planning: Scope, timelines, documentation, stakeholder and leadership commitment, kickoff
- Preparation: Reading those thousands upon thousands of release notes in Nova (yes, you have to read them all!), updating test scripts, communication planning, training preparation, and non-production upgrades (POC environment)
- Build: Turning all those release notes into new or modified workflows and training materials, hardware upgrades, simple practice upgrades, and more non-production upgrades (TST environment)
- Testing & Training: A few rounds of integrated testing (2-3 rounds across 4-6 weeks is very common), user acceptance testing, super user/end-user training, more extensive practice upgrades, status checks and go/no-go meetings, and more non-production upgrades depending on your environment structure (e.g., MST environment)
- Final Production Preparation & Upgrade: Logistics for the night of the upgrade, cutover activities, and various success checks such as reviewing your detailed downtime plan with Epic and verifying your build migration plans are complete
- Optimization & Additional Features Rollout: This varies greatly by organization and can last anywhere from two months until the next upgrade
5 critical steps within a successful Epic upgrade project
So for you first timers out there, what does all this mean for you? Where should you focus? And what can you do to stay in good shape throughout the project?
1. Assign a strong project manager
A strong project manager is critical for an upgrade. A lot of the work is communication and planning, but with the number of resources involved in an upgrade, you really need someone who’s organized and structured. A typical week for the PM involves a large number of touch-base meetings with key team members (environment manager, hardware team, server team, client systems team, reporting team, training team, testing team, application team managers, SMEs, stakeholders, leadership team, etc.), and a decent number of hours nose-deep in upgrade project plan files. For those short on resources, an upgrade PM can also serve as your testing coordinator and potentially other roles.
The areas of an upgrade where clients struggle tend to center around testing scripts (and, as a result, testing), hardware (specifically printing), and not getting training involved early and often enough.
2. Create detailed test scripts
Test scripts tend to not be detailed enough, and not in great shape at the start. They also tend to consume more time to update than people plan for early on. The largest, most common workflows get a lot of attention, but some important, smaller workflows can be overlooked. Also, as the project progresses and decisions are made regarding release notes and new functionality or workflows, not all of these decisions are incorporated into the test scripts. This, of course, has a cascading effect in regards to overall testing and can create issues in testing sessions. A heavy focus on the quality of test scripts pays large dividends later in the project.
3. Plan for comprehensive testing, including printing and reports
Speaking of testing, it’s important to not only test all the new stuff coming with the upgrade, but also all current-state workflows. Sometimes the addition of A in a system can have an unforeseen impact on a seemingly unrelated existing B, and by testing existing workflows you can address any issues.
Similarly, and this is not common to just upgrades, clients often struggle with printing issues. I highly recommend creating a few test scripts that incorporate printing various common forms and printouts from your larger workflows. Additionally, taking your top 10 or 20 most common reports and doing some sample printing during integrated testing sessions is helpful.
4. Bring training into the project early
Training is one of the most important keys to a project's long-term success, so bring training into the project early. Keep the trainers in the loop on all major decisions with the upgrade. The release notes in Nova also allow you to add information for the training team. Training is sometimes seen as a ‘later in the project’ area, and I’ve seen it overlooked too many times with upgrades. This can cause major issues shortly before the upgrade occurs, putting success in jeopardy. Too much communication with the training team, or with any group or person in general with upgrades, is not something I’ve ever seen. When in doubt, over communicate.
5. Thoroughly plan for support during the night of the upgrade
So, you’ve reached the night of the upgrade, what’s that look like for support? Remote support by your technical services representatives is common and will be used in some format. However, it’s not uncommon for some staff from Epic to come support onsite, depending on the size 
and complexity of the upgrade, the organization’s experience with upgrades, budget, and a few other considerations. Having the Epic technical coordinator onsite is always a good option. This person is the counterpart to your upgrade PM and an excellent resource if any issues arise. Expect the best, but plan for the worst. From
the organization, you’ll have your data migrators who are moving system build from one environment to another, your testers (if it’s not the same people) to make sure everything is working after the move, your technical team members (data courier staff, server and client teams, environment manager, etc.), project sponsor/stakeholder/leadership representation, your upgrade PM, and several other people. Epic does a good job of helping you plan for who should be present during the upgrade. Don’t forget some on-the-floor support for those end-users working the night/morning of the upgrade (training team is a good choice for this).
After the upgrade, the approach varies for continued support. Some roll right over to a normal after-hours support structure, while some have a command center through the hours/day after the upgrade and then shift to normal helpdesk and maintenance support after stabilizing.
In closing
Overall, Epic upgrades are a great opportunity to incorporate the latest and greatest Epic has to offer. Ensuring you include these five critical steps will give your upgrade project the greatest shot at success. Good luck! If you want to talk more about your upgrade, please reach out.
Austin Hundley is a senior Nordic consultant and project manager with experience leading organizations through Epic implementations, upgrades, and post-live. With over 15 Epic certifications and 12 years of Epic experience, Austin has a thorough understanding of the integrated Epic system and specializes in upgrades, optimization, enterprise testing, reporting, mentoring, and coaching.