OCI Migration: What We Learned Being First

An Executive Summary by Brian Oliger

Founder & CEO — Hi-Res Consulting

Introduction: We Didn’t Move Servers, We Moved an Entire Ecosystem.

When we signed on to become one of the first health systems to migrate Cerner to OCI, there was no playbook, no roadmap, and no successful go-live to reference.

We weren’t just modernizing infrastructure, we were untangling years of technical debt, outdated workflows, fragmented ownership, and institutional fatigue.

Today, with the cutover behind us and the lessons still fresh, there are patterns every CIO should understand before they begin. OCI migration isn’t a technical project. It’s an organizational transformation, and the success of the migration is determined long before the first server is moved.

This document summarizes those lessons in plain language.

1. Organizational Alignment Is the #1 Success Factor

If you take nothing else from this document, take this:

OCI success is less about technology and more about alignment. When the organization moves together, the migration becomes manageable. When it doesn’t, things can get messy.

Alignment doesn’t mean everyone is happy, it means everyone understands the why, the order, and the tradeoffs.

Our approach:

• We repeated the same strategic narrative for 18 months.

• We reinforced the sequence: foundational upgrade → infrastructure → speed + innovation later.

• We said “no” more often than anyone liked — and we said it consistently.

• Eventually, even the loudest voices became champions once they understood how everything was interconnected.

Executives, clinicians, and operational leaders must understand that OCI unlocks future speed, not present convenience.

Without alignment, the migration becomes a negotiation.

With alignment, it becomes a mission.

2. Networking Will Consume More Time Than You Expect

Here has been the ongoing experience:

Networking was the slowest-moving part of an OCI EMR migration, both during implementation and after go-live.

Most health systems are likely to underestimate:

• The time it takes to coordinate with your telecom companies

• The volume of systems that require re-routing

• The change in process for submitting requests

• The turnaround time (weeks, not days)

• The need for extremely clear interface documentation

• The cultural adjustment to slower, security-heavy protocols

Most organizations will underestimate this part because networking has always been something you could fix quickly: add a rule, open a port, approve a connection, move on. OCI changes the entire rhythm. Nothing is “quick” anymore. Requests have to be submitted in a very specific format, with exact technical details, and any ambiguity will force the entire request back to the starting line.

If you don’t plan interface readiness early, you stall the entire program. For us, it became one of the highest-risk areas as our speed now depended on Oracle’s internal processes and their security reviews, not our own team’s capacity. If your organization isn’t prepared for that slowdown, people will get frustrated fast.

If you don’t call this out in the contract and push for SLAs around turnaround time, you can lose days or weeks across the project without anything technically being “wrong.”

3. Security Rules Everything and It Will Slow You Down

OCI defaults to maximum security posture, and that reality reshapes design:

• Legacy shortcuts disappear.

• Access becomes controlled and review-heavy.

• “Simple changes” now move through gating.

• Unique workflows require justification, not assumption.

Part of what impacted our timetable was that we brought workflows to Oracle that they had not seen before. When you have a unique workflow, you have to justify to them why it needs to occur for it to be allowed.

As an example, we had a link that launched from the EMR to a third party imaging system with the credentials embedded. Oracle identified that as a security threat and wouldn't allow it to launch inside their environment. This was a hiccup for us during go live, we ended up redirecting to our local browser as a fix.

4. ALVA & Cloud Onboarding Will Surprise You (And It Ate Weeks For Us)

Every EMR-dependent service must be cloud-approved, cloud-reprovisioned, and cloud-validated:

• CommonWell / Carequality

• Direct Messaging

• Surescripts (especially eRx)

• Smart on FHIR launch frames

• Third-party API bridges

• Imaging launch contexts

The risk isn’t failure so much as it’s timing.

We didn’t test eRx until two weeks before go-live because dependencies cascaded downstream.

You must plan onboarding sequencing as a first-order risk, not a late checklist item.

5. Testing Takes Less Time Than You Fear, If You Prepared Correctly

The most surprising lesson:

Testing wasn’t the monster we expected.

Front-end workflows don’t meaningfully change in OCI, so what you end up validating is that the back-end supports everything under load:

• Orders outbound correctly

• Docs file correctly

• Inbound interfaces post cleanly

• Imaging links route to the right destination

• Ancillary data doesn’t get trapped mid-flight

Testing only looks scary when everything else is messy. If you get the infra right up front, then testing becomes clean. If you miss that, it becomes a much bigger problem later and may force additional testing events, slipped schedules, etc.

OCI made the codebase faster and more stable than our older environment. The real work was upstream, and if you prepare appropriately you should be rewarded for the effort like we were.

6. Cutover Requires Military-Level Coordination

OCI cutover is not like a typical upgrade freeze.

Ours was a 16-hour downtime window with:

• Layered schedules

• Multiple shifts per engineers and support staff

• Parallel bridge lines for confirmation

• Sequenced interface timing

• Pre-cutover downtime to prevent accidental documentation

We prepared extensively for extended downtime scenarios and that preparation paid off.

Every health system should assume:

• Longer-than-expected downtime

• More coordination than a typical upgrade

• The need for extremely crisp communication across all teams

Rollback is theoretical until the first order is placed. After that, every decision is forward-only so plan like there is no reverse gear.

7. Governance Tightens and Most Clients Aren’t Ready

Post-OCI the rules change. Operations require clarity, documentation, and repeatable pathways. The informal workflows won’t scale, and that’s the point. It will probably feel restrictive, but it’s simply modern governance.

The key is expectation-setting:

• What used to take 10 minutes may take 10 hours

• What used to be a quick workaround may now require a ticket, a review, and sequencing

• People who “just did things” internally may now need approvals

Executives who understand this upfront and plan well should avoid most of the internal friction.

8. Domain Refreshes Take Longer. Much Longer.

This was a major surprise.

Domain refreshes that used to take days now take months.

We were still waiting on final refreshes six months after go-live.

Why? Two reasons:

• New OCI replication processes

• A backlog of domain requests across Oracle Health

• Limited resource capacity to process them

This is not an outright complaint, but it is an adjustment.

If your implementation plan assumes quick refreshes, rewrite that plan now.

9. Upgrades + Infrastructure Are Still Not Coordinated Inside Oracle

We learned this the hard way.

We ran infrastructure migration + our code upgrade together. They should have been compatible and they weren’t.

Key issue:

Two different Oracle teams controlled two different parts of the migration and they were not aligned.

Oracle is improving rapidly, but until these teams are unified, clients must:

• Demand a single accountable program manager

• Require shared timelines

• Insist on cross-team coordination

If Oracle does not provide it, hire a third-party PMO to bridge the gaps, it will save you months.

10. The Future Is Clear: OCI Is Not Optional

This is the universal takeaway:

OCI is not “nice to have.” OCI is where Oracle Health is going. All future innovation depends on it.

Every roadmap — AI agents, embedded automation, faster updates, improved resiliency, new clinical capabilities — is being built for OCI first.

Organizations delaying the inevitable are simply delaying their ability to innovate.

The real question is no longer “Should we move?”

It’s:

“How prepared is our organization to move well?”

Closing Perspective

We learned more in this migration than any project I’ve led in my career.

If your hospital is considering OCI, my recommendation is simple:

• Get aligned early

• Set expectations clearly

• Prepare for slower operational rhythms

• Document everything

• Hire or empower strong program management

• Respect the role of security

• Treat this as a foundational investment

OCI is not just Oracle’s future it’s healthcare’s future infrastructure.

The organizations that master it early will move faster, safer, and with far more strategic flexibility than those who wait.

If you'd like a readiness review or simply want to sanity-check your assumptions, I’m happy to help.

— Brian