DMS migration at scale: Balancing speed with minimal patient care impact

In Article 1, we looked at why health systems are moving clinical documents out of standalone platforms such as OnBase, OpenText, M-Files, and Box, and into the EHR through Epic Gallery. This installment turns from why to how to undertake a DMS migration.

The engineering frontlines of the data exit

For health systems that want one record, one login, and one place a clinician looks for a document, consolidation into a native EHR multimedia repository has become a strategic standard. The more difficult problem to solve is: How does the data actually get there?

The answer starts with an honest accounting of scale. A mid-to-large health system’s legacy repository holds 75 million to more than 100 million documents — scanned images, multi-page PDFs, and unstructured clinical content built up over decades. That archive cannot be taken offline, because clinicians pull from it every hour of every day.

The promise of a unified record therefore rests on a single piece of engineering: an extract-transform-load (ETL) pipeline capable of moving that volume without disrupting active patient care.

Why legacy platforms weren’t built for the exit

The first obstacle is the platform itself. Legacy content management silos were engineered to ingest, store, and share documents, never to release them at enterprise volume. Getting data out means working around each vendor’s technical processes, availability, and timeline.

Hosting decisions made years ago compound the challenge. Health systems that moved from on-prem to hosted environments, whether self-hosted, AWS, Azure, or a vendor’s data centers, gave up a degree of direct access to their own content. Nothing is being withheld. The content simply is not easily reachable at scale for extraction.

The conventional approach (e.g. relying on legacy DMS vendors for extraction) means months of waiting before a project even kicks off. Then it takes several months to years to complete at the high end of the volume range, with extraction limited to business hours or the vendor’s maximum export process. Meanwhile, every added month extends maintenance fees on a system the organization is trying to sunset.

The lesson for IT leaders is that the export limitation, not the size of the archive, determines whether a DMS migration takes months or years. A well-planned migration project that runs around the clock rather than business hours compresses that timeline substantially. High-velocity delivery is a financial argument as much as a technical one.

Infrastructure realities of on-prem and hosted

No two environments are alike. Walk into two hospitals running the same EHR and you will find two different systems, shaped by how each was implemented and configured. The same is true of the legacy repository, which is why infrastructure deployment flexibility matters. The migration framework must conform to the health system’s posture, not the reverse.

Hosted and on-prem are fundamentally different when extracting data. Hosted extraction engagements are meaningfully more complex. When the legacy environment sits in a data center states away, the binding constraint shifts from local processing speed to facility-to-facility network latency, and the required skill set shifts with it.

However the environment is arranged, the security architecture stays constant. Data moves out through a secure pathway and down into the customer’s own environment, secured end to end in transit and never leaving that environment. This is zero-egress architecture in practice. No third-party applications, tools, or monitoring enter the environment along the way, a discipline that serves both security and a clean exit when the project ends.

For a closer look at hosted environments, see Davey Rowan’s Q&A, From Your Hosted Legacy DMS to Gallery.

Moving fast without being felt

Once the project is customized for the health system’s environment, the focus turns to calibration. A manual, script-driven extract by internal IT lands at a modest baseline. Discovery work and targeted enhancements push throughput several times higher. A purpose-built parallel-processing architecture goes further still.

Peak capacity, however, only proves what a pipeline can do. Sustainable execution runs well below peak, at a rate set by each system’s architecture, network capacity, and timeline. The job is to find that number for each environment rather than chase the maximum. Push too hard and end users feel it — retrievals slow, latency creeps in, and faxes and scans back up at exactly the moment someone needs them.

Go-live sequencing shapes the work as well. A health system can go live on the native repository before or after extraction begins. When they go live after, clinicians are actively adding documents while historical extraction is still running, so recent content is deliberately left untouched until go-live.

Through it all, throttling remains a live conversation. The health system flags anything that seems even slightly unusual, whether or not it turns out to be the DMS migration, so processing can be dialed back or resources added.

The standard is that providers never notice. A clinician pulls a patient’s report and gets it. Whether it comes from the legacy silo or the native repository, they see no difference. Patient care is not affected.

The surprise factor and 24/7 operations

Even a calibrated pipeline meets surprises. Opening a decades-old repository surfaces hidden technical debt: un-inventoried document types, obsolete keyword indexing schemas that no longer map to modern EHR structures, and forgotten integrations with ancillary systems.

Orphaned documents are the clearest example. Documents surface inside the EHR through a mapping that ties them to an encounter or order. Files without that link belong to a patient but are not connected to an encounter, so they appear only if someone logs into the legacy system directly. Native multimedia layers need that mapping intact to render a document at go-live. Closing the gap takes intelligent ingestion, which matches orphaned files back to the right patient and encounter using multiple identifying data points before they move.

Format transformation is the step most migration plans skip. The native repository accepts a wide range of formats, with PDF and TIFF accounting for the overwhelming majority of what moves, but anything arriving in a format it does not take must be converted before load.

Around-the-clock operation, the discipline that compresses the window and stops the double maintenance bleed, carries a staffing requirement. It calls for a domestic engineering team monitoring throughout, with structured checks confirming that processing is running and nothing has crashed. Internal IT is not that team. They stay in the loop without carrying the monitoring load, so the DMS migration never becomes another item on their staff’s plate.

Looking forward: Successful DMS migration

A clean exit is a matter of engineering discipline, secure in-environment handling, and throughput calibrated to the system it runs against. When executed correctly, high-velocity data extraction transforms a massive IT hurdle into a transparent background process, ensuring that frontline clinicians never lose access to critical care histories for a single second.

However, getting patient records cleanly into the native EHR multimedia layer is only half the battle. To fully capture the financial and operational benefits of system consolidation, healthcare leaders must look beyond the clinical footprint and finish the job.

In the next article, the final in the series, the focus will shift from the active extraction pipeline to the ultimate goal of system consolidation: turning off the legacy DMS for good. Drawing on lessons learned from health systems in the field, we explore how IT leaders handle the stranded non-clinical data, like HR files and AP invoices, to avoid the costly “read-only” trap, ensure compliance, and capture the full ROI of application decommissioning.

About the Author

Davey has spent more than 20 years working inside legacy document management and Epic environments, including roles with Hyland Software, Cleveland Clinic, and health IT consulting and data migration organizations. Today, he leads FastLane delivery at Quoris, helping health systems navigate the migration of hosted legacy DMS environments to Epic Gallery.

About the sponsor

Quoris is a global healthcare IT firm with more than 26 years of experience helping health systems get more from their clinical and operational technology. Its FastLane program offers accelerated extraction and conversion services for data headed to Epic Gallery from any environment, hosted or on-premise. FastLane works alongside your Epic team, and is led by Gallery-accredited, veteran DMS professionals who work directly inside your network, with no data leaving your environment and no third-party tools introduced.