When 2 Million Patient Records Run on Borrowed Time: A Healthcare Database Migration Story

A regional hospital network moves 65 TB of clinical data to AWS without losing a record or an hour of clinical access. The four phases, the five non-negotiable constraints, and why the cutover is never where a migration succeeds.

*How a regional hospital network moves its most critical data to AWS — without losing a single record, a single hour of clinical access, or the confidence of its compliance team.*

About this article. MedCare Health Systems is a composite illustration, not a client engagement. The pressures, the sequence of decisions, the constraints and the failure modes described here are drawn from how healthcare database migrations to AWS actually run; the organisation itself is not real, and the figures are representative of a programme of this shape rather than a report of one we delivered. We label it because the alternative — an invented customer presented as a real one — is not something a healthcare buyer should have to detect for themselves.

Technical scope note. Oracle → Amazon Aurora PostgreSQL is a heterogeneous database migration path. In this illustrative scenario, the EHR application's compatibility, database-specific code, drivers and integrations are assumed to have been assessed and approved before production cutover.

Every healthcare CIO knows the feeling. Somewhere in a data centre, a database holding the medical histories of millions of patients is running on hardware that gets older every day, under a licensing contract that gets more expensive every year, protected by a disaster recovery plan designed for a different decade.

Nothing is broken — yet. Clinicians pull up records. Claims get processed. The lights stay on. But the executive team knows the truth: the organisation's most important digital asset is living on borrowed time, and every quarter of delay narrows the options and raises the stakes.

This article follows that decision from the boardroom to the cutover window. It is not a story about technology for its own sake. It is about risk, cost, compliance, and continuity of care — the four things that keep healthcare leadership awake at night. And it ends where these programmes should end: with a short, rehearsed cutover on a Sunday morning, after which clinicians log in for morning rounds and notice only that everything is faster.

The Situation: A Success Story Becoming a Liability

MedCare operates 12 hospitals and more than 40 outpatient clinics, serving roughly 2 million patients. Like most health systems of its size, its digital estate grew organically over 15 years, and — critically — it is not one system but two very different categories of system.

The Oracle EHR database. In this illustrative scenario, MedCare's EHR database runs on Oracle and contains roughly 45 TB of patient records and claims data. The migration assumes the EHR application and its integrations have been assessed and cleared for the target PostgreSQL-compatible architecture; the database conversion is therefore treated as a controlled application-modernisation programme, not a simple database copy.

The surrounding data estate. The EHR is part of a broader clinical data environment. MedCare also operates a SQL Server data warehouse powering analytics and regulatory reporting (~20 TB), plus imaging metadata and documents connecting radiology systems to patient charts. These systems are included in the wider modernization programme.

By the time leadership commissioned a formal review, four pressures had converged on that second category.

The hardware was reaching end-of-life. The storage arrays and servers underpinning the clinical data repository were approaching the end of vendor support. A refresh meant a capital outlay in the millions — buying more of the same, and locking in another five to seven years of the status quo.

Licensing costs were compounding. Annual database licensing and support had grown into one of the largest line items in the IT budget, with renewal negotiations trending in only one direction. The finance leadership's position was blunt: the organisation was paying premium prices to stand still.

Disaster recovery was a quiet compliance risk. The DR site could tolerate up to 30 minutes of data loss in a failover. Thirty minutes of lost admissions, medication orders and lab results is not merely an operational problem — in a post-incident regulatory review, it is a finding. The board's audit committee had flagged it two years running.

Ambition had outgrown the foundation. Leadership wanted predictive readmission-risk analytics, population health dashboards, and eventually AI-assisted clinical decision support. None of that was realistic on infrastructure straining to keep up with daily transaction volume.

Any one of these might have justified action. Together, they made the case unavoidable. The question was no longer *whether* to modernise, but *how* — and how to do it without putting patient care or compliance at risk for even an hour.

Why the Easy Answer Wasn't Good Enough

The path of least resistance was obvious: buy new hardware, renew the licences, revisit in five years. It was also, on analysis, the most expensive and least strategic option available. A refresh consumes capital budget while solving none of the underlying problems — not the licensing burden, not the DR gap, not the analytics ceiling.

The second-easiest path was a lift-and-shift: move the existing Oracle environment onto cloud infrastructure as-is. That addresses the hardware problem and improves DR, but it carries the licensing costs — the single largest recurring expense — straight into the cloud, where they are just as expensive and somewhat harder to see.

The harder, more valuable path is a controlled modernization of the database and data estate:

• The Oracle-based EHR database and claims data move to Amazon Aurora PostgreSQL using heterogeneous database migration techniques.
• The analytics warehouse moves from SQL Server to Amazon Redshift.
• Imaging metadata and documents move to a modern data lake foundation on Amazon S3.
• The HL7 and FHIR integrations are preserved, tested and cut over alongside the application connections.

In one programme, the organisation removes the Oracle licensing and ageing infrastructure burden, closes its DR gap, and builds the platform its analytics ambitions require — while treating application compatibility and clinical integration as first-class migration work.

A cost analysis of a programme in this shape, run with AWS Migration Evaluator, typically projects a 40 to 55 percent reduction in total cost of ownership over five years against the hardware-refresh-plus-licensing status quo. The savings are driven by eliminated licence fees, retired data-centre overhead, and the shift from large capital cycles to predictable operating spend.

But projected savings are only credible if the migration itself doesn't create the very disaster it is meant to prevent. That is where the real work begins.

The Constraints: What "Failure Is Not an Option" Actually Means

Healthcare migrations are unforgiving in ways that migrations in other industries are not. Before a single byte moves, the steering committee — which should include the Chief Medical Information Officer and the Chief Compliance Officer, not just IT — sets the non-negotiable conditions. In a programme of this shape there are five.

First, clinical access cannot be meaningfully interrupted. Clinicians use these systems around the clock. Emergency departments do not close for maintenance windows. Maximum acceptable cutover downtime: 30 minutes, scheduled at the lowest-activity hour of the week, with a full rollback plan if anything looks wrong.

Second, zero data loss. Not "minimal." Zero. Every admission, order, result and note recorded up to the moment of cutover must exist in the new environment. In healthcare, a lost record is not a technical incident; it is a patient safety issue and a legal exposure.

Third, full HIPAA and HITECH compliance throughout — not just at the end. Protected health information stays encrypted in transit and at rest at every stage, covered by a signed Business Associate Agreement with AWS, with audit trails detailed enough to satisfy a regulator asking, months later, exactly who accessed what and when.

Fourth, the ecosystem cannot break. A hospital database does not live in isolation. It exchanges data continuously with the EHR, laboratory systems, pharmacy systems, billing clearinghouses, state health information exchanges and dozens of clinical applications through HL7 and FHIR interfaces. Every one of those connections has to keep flowing — during the migration and after it.

Fifth, compliance signs off in writing at every phase gate. Treating compliance as a co-owner of the programme rather than a final checkpoint is a deliberate choice. It is also, in our experience, the single strongest predictor of whether a healthcare migration finishes on schedule.

The Approach: Discipline Over Drama

A programme of this scope runs in four phases over roughly nine months. The phases are worth understanding at a leadership level, because each one exists to retire a specific category of risk before the next begins.

Phase 1: Assessment — Know Exactly What You're Moving

The programme begins not with servers but with analysis. Automated assessment tooling — AWS Schema Conversion Tool — scans the Oracle environment and produces a precise inventory of what converts automatically to the new engine and what needs human attention. On a fifteen-year-old estate, roughly 75 to 80 percent of schema and logic converting automatically is a typical result. The remainder — mostly complex stored procedures written over many years, some by developers long gone — gets catalogued, prioritised and assigned for manual rework.

That number matters to executives for one reason: it converts an open-ended, anxiety-inducing unknown into a bounded, plannable body of work with a cost and a timeline. Before serious budget is committed, leadership knows the true scope of the hardest part of the project.

Assessment also surfaces surprises early, when they are cheap to handle. The most common one in healthcare: millions of scanned documents — consent forms, referral letters, historical charts — stored *inside* the database itself. It is a normal practice in older systems, it bloats the database, and it will dramatically slow a migration. The remediation moves those documents to Amazon S3 object storage with the database holding lightweight pointers. The database shrinks, migration timelines improve, and document retrieval actually gets faster.

Phase 2: Foundation — Build the Compliant Landing Zone First

Before any patient data moves, the team builds the destination: a multi-account AWS environment governed by AWS Control Tower, restricted to HIPAA-eligible services, with private network segments, dedicated encrypted connectivity from the hospital data centres via AWS Direct Connect, customer-managed encryption keys, and comprehensive audit logging through AWS CloudTrail and AWS Config.

For the compliance team, the pivotal moment in this phase is not technical. It is a two-day workshop mapping every HIPAA administrative, physical and technical safeguard to a specific, documented control in the AWS environment — and clarifying, line by line, which controls AWS operates and which remain the organisation's responsibility under the shared responsibility model.

This is worth dwelling on, because it is counterintuitive to most boards. The migration improves auditability before it moves a single record. For many organisations, that workshop produces the first complete, single-document account of their own security posture they have ever had.

Phase 3: Migration — Weeks of Replication, Not a Weekend of Prayer

Here is the part most leadership teams find surprising: migrating 65 terabytes of live, constantly changing data does not happen during a heroic weekend. It happens gradually, invisibly, over several weeks — while the hospital network operates completely normally.

AWS Database Migration Service performs an initial full copy, then switches into continuous change data capture, capturing every change in the source systems — every admission, every order, every result — and applying it to the new AWS environment within seconds. For weeks, old and new run in parallel, in sync.

That parallel period is where the risk is systematically drained out of the project. Automated validation jobs continuously compare the two environments — row counts, checksums, sampled record-level comparisons — and report discrepancies daily. The clinical applications are tested exhaustively against the new database. Integration problems surface *here*, in testing, with time to fix them: the third-party billing application hard-coded to the old database drivers; the reporting job nobody documented; the interface engine mapping that silently depends on a legacy column type. Each one is a cutover-night disaster discovered on a Tuesday afternoon instead.

Then the team performs two full dress-rehearsal cutovers on non-production weekends, timing every step, until the real thing is a procedure rather than an event.

Phase 4: Cutover — Twenty-Two Minutes on a Sunday Morning

At 2:00 a.m. on a Sunday — the quietest hour of the network's week, chosen from a year of activity data — the team executes the cutover. Applications are paused, final transactions confirmed replicated, validation checks run green, and application connections redirected to the new environment. Clinical staff have been briefed weeks in advance; downtime procedures, familiar from routine maintenance, are in effect.

Twenty-two minutes later, the network is live on AWS. Every interface — EHR, lab, pharmacy, billing, health information exchange — resumes flowing. The rollback plan, rehearsed and ready, is never needed. By morning rounds, the only observable change for clinicians is that record retrieval is noticeably faster.

The window is short because the work was done in Phase 3. A cutover is not where a migration succeeds; it is where a migration is revealed to have already succeeded.

The Results: What Leadership Actually Bought

Six months after a cutover of this kind, the outcomes a board reviews look like this:

Disaster recovery goes from a 30-minute exposure to near-zero. The new environment replicates continuously across multiple isolated data centres, with a standby copy in a second geographic region. The audit committee's two-year-old finding is formally closed — which, for many boards, is the single line that justified the programme.

The largest controllable licensing line item is gone. With the move to Aurora PostgreSQL, proprietary licensing fees on the migrated systems are eliminated entirely. Combined with retired hardware and data-centre costs, the organisation tracks against its projected 40–55 percent five-year TCO reduction.

Performance improves where it matters clinically. Patient record lookup — the query clinicians run hundreds of times a day — runs several times faster. That is a difference measured not in server metrics but in seconds saved at the bedside, thousands of times daily.

Compliance posture is stronger, not merely preserved. Every access to patient data is logged centrally and immutably. Evidence-gathering for audits, previously a weeks-long scramble, becomes largely a reporting exercise.

The strategic ceiling is gone. With data consolidated on a modern platform, the analytics team can launch predictive readmission-risk models and population health dashboards — initiatives that were architecturally impossible eighteen months earlier.

The migration was never really about moving a database. It was about buying the organisation its next decade of options.

What This Means for Your Organization

Three lessons transfer directly to any healthcare leadership team weighing this decision.

The riskiest option is usually inaction dressed up as prudence. Ageing infrastructure does not fail on a schedule that respects your budget cycle. Every renewal of the status quo is a decision — one that compounds licensing costs, extends compliance exposure and defers strategic capability. The organisations that migrate well are the ones that choose their timing rather than having it chosen for them.

Know exactly what the migration scope includes. An Oracle-to-Aurora PostgreSQL migration is a valid heterogeneous migration pattern, but the database, application, integrations and vendor support model all have to be assessed together. Schema conversion alone is not enough; application compatibility, database-specific logic, drivers and HL7/FHIR workflows must be validated before cutover.

Downtime and data loss are engineering problems with known solutions — if the discipline is there. Continuous replication, parallel running, automated validation and rehearsed cutovers are proven practices. A sub-30-minute cutover with zero data loss is not a moonshot; it is a standard a qualified partner should be willing to commit to in writing.

And compliance belongs at the table from day one. Bring the compliance and clinical leadership in at the assessment phase and they become the programme's strongest advocates. Bring them in at the end and they become its bottleneck — correctly, because they were not given the chance to be anything else.

Frequently Asked Questions

Can an Oracle database be migrated to Amazon Aurora PostgreSQL?

Yes — it's a supported heterogeneous path, with AWS DMS moving the data and AWS SCT converting the schema and code, from Oracle on premises, on EC2, or on RDS.

The qualifier is the application, not the database. AWS's own guidance is explicit: if the database supports a commercial off-the-shelf or vendor-specific application, you may not be able to convert it, and you should confirm the application supports Aurora PostgreSQL before starting. That check is what the assessment phase is for.

How can a healthcare database be migrated with minimal downtime?

By doing the work while the old system is still live. DMS runs a full load, then change data capture keeps the target in sync for weeks while clinicians keep working normally. Cutover becomes a switch rather than a data movement — pause, confirm replication has caught up, validate, redirect — and under 30 minutes is realistic once rehearsed.

One honest caveat: DMS CDC is near-real-time, not real-time, and AWS publishes no latency SLA. The cutover procedure has to confirm catch-up, not assume it.

What happens to Oracle-specific code — PL/SQL, packages, stored procedures?

SCT converts most of it automatically and reports what it can't, with an effort estimate per item. That report is what turns an unknown into a plannable body of work.

Expect manual attention on constructs with no PostgreSQL equivalent: sequences, ROWID, dynamic SQL, some partitioning schemes, and Oracle-specific TO_CHAR / TO_DATE / TO_NUMBER formats. And schema conversion isn't the whole job — application SQL, drivers and connection handling change too. That is where migrations slip.

Does moving to AWS automatically make the environment HIPAA compliant?

No, and any partner implying otherwise should be treated with suspicion. AWS secures the cloud; you secure what runs in it.

Three things are yours: a signed Business Associate Addendum, an architecture restricted to HIPAA-eligible services — the published list doesn't cover everything — and the controls actually configured, meaning encryption, key management, least privilege and audit logging. Compliance is a property of how the environment is designed and operated, not of moving to AWS.

Can the EHR application keep running during the migration?

During replication, yes. The source stays authoritative while DMS syncs the target in the background — that's the point of running both in parallel.

What can't be skipped is validating the application against the target first: Oracle-specific SQL, drivers, connection strings, and every HL7 and FHIR interface to lab, pharmacy, billing and health information exchange systems. The application is unavailable only for the cutover window itself.

See it against your own estate

The fastest way to judge a migration plan is to point it at the database you are actually worried about. We will walk you through what converts automatically, what needs manual rework, what the cutover window realistically looks like, and what the five-year cost comparison says — request a migration readiness assessment, or talk to us about your specific Oracle estate.

Read-only throughout. We deploy a scoped role you can revoke when the report lands, make no changes to your environment, and see no patient data.

Related reading: Automate genome reporting: a secure lab pipeline on AWS — the same regulated-data principles applied to clinical genomics, from ingestion through the sign-off gate.

*Orbitnexa is a technology consulting firm specialising in cloud migration, data modernisation and managed AWS services for regulated industries. ISO/IEC 27001:2022 · ISO 9001:2015 · ISO/IEC 20000-1:2018.*

Technical References

Official AWS documentation for the services and patterns described above.

• Migrate an Oracle database to Aurora PostgreSQL using AWS DMS and AWS SCT — AWS Prescriptive Guidance: the end-to-end migration pattern, including the application-compatibility limitation quoted above.
• Migrating from Oracle to PostgreSQL with AWS Schema Conversion Tool — how Oracle-specific constructs convert: sequences, ROWID, dynamic SQL, partitions and function emulation.
• Creating tasks for ongoing replication using AWS DMS — change data capture, the mechanism behind the parallel-running approach and the minimal-downtime cutover.
• HIPAA Eligible Services Reference — the authoritative list of AWS services eligible for processing ePHI.
• HIPAA compliance and the AWS Business Associate Addendum — the BAA required under HIPAA rules, and the shared responsibility split between AWS and the customer.