I wrote the standard for making websites AI-operable. Learn More
Migration · eClinicalWorks to athenahealth
Every EHR migration proposal says your clinical data comes across. Almost none of them distinguish between data that arrives as structured, searchable, decision-support-usable information and data that arrives as a PDF attached to a patient record. That distinction is the entire quality of the migration.
The honest position is that a meaningful portion of your historical chart will arrive as a document rather than as discrete data, and the useful work is establishing exactly which portion, per object, before you commit — rather than discovering it when a physician cannot filter by a diagnosis that used to be filterable.
Certified EHRs support standards-based clinical export, and C-CDA is the usual mechanism. It is important to be precise about what that means: C-CDA is a clinical summary interchange standard, not a full-fidelity dump of the source database. It carries the core clinical elements well — problems, medications, allergies, immunizations, results — and it does not carry everything a decade of charting produced. Alongside it, discrete data extraction for demographics, scheduling, and financial objects runs through separate paths. The assessment establishes, per object, which of your data comes across discretely and which arrives as a document.
Each of these gets its own record count in the assessment and its own line in the reconciliation report. Depth of history is a scope decision made with real numbers in front of you, not an assumption baked into a quote.
Patient demographics and identifiers
Names, dates of birth, contact details, and identifiers, with a deliberate strategy for the medical record number — see the quirks section, because MRN continuity affects everything downstream.
Insurance and coverage
Payers, plans, subscriber relationships, and active coverage, so eligibility and billing work on day one.
Problem list
Active problems with coded diagnoses, carried discretely where the source coded them discretely.
Medications and allergies
Active medication list and allergy list as discrete, coded data. These are the clinical safety objects and they are validated as their own step, separately from everything else.
Immunizations
Immunization history with dates and products, discretely where recorded discretely.
Results and lab history
Laboratory and diagnostic results, discrete where the source held them discretely and as documents where it did not.
Encounter notes and clinical documents
Historical notes and documents attached to the correct patient and encounter. Predominantly document-form for historical depth; the assessment quantifies this.
Appointments
Future scheduled appointments with their types and providers, so the schedule survives cutover.
Written down before you spend anything, because the alternative is finding out in week six. This list is specific to eClinicalWorks to athenahealth; the assessment turns it into your list, with record counts attached.
— Full discrete fidelity for historical charting. This is the central honest point of this page. Core clinical elements carry discretely; the long tail of historical notes, flowsheets, and templated documentation generally arrives as documents. The assessment quantifies this per object before you commit, and any vendor who will not is worth pressing.
— Accounts receivable as a working AR. Standard practice is to work the existing AR down in the source system while new activity starts in the destination, with the source retained read-only. Migrating an in-flight AR is not the normal answer.
— Custom templates, order sets, macros, and clinical decision support rules. These are rebuilt in the destination and it is a substantial project in its own right — often larger than the data migration.
— Interfaces: lab, radiology, HIE, immunization registry, e-prescribing, and pharmacy. Historical data migrates; every interface is re-established, each with its own lead time measured in weeks, and several require enrollment steps that cannot be compressed.
— E-prescribing and controlled-substance prescribing authority. These are provider enrollment and identity-proofing processes, not data — and they must start early because they gate a provider's ability to prescribe on day one.
— Source internal record IDs. The destination issues its own; anything keyed externally needs the mapping table.
None of this is in either vendor's documentation. It is the category of thing that looks fine in a test load and produces a wrong number in month two, which is why the process puts a full sandbox load and a reconciliation you sign in front of any production cutover.
01
This single misunderstanding causes more disappointment than anything else in EHR migration. C-CDA was designed to communicate a clinical summary between systems, not to reproduce a source database. It does its job well. It is not a full-fidelity archive, and a proposal that treats it as one is either uninformed or misleading.
02
Whether medical record numbers carry unchanged determines how much external reconciliation you face — with the lab, the hospital, the HIE, and your own historical paper. It is a deliberate decision made early, not a by-product of the import.
03
Re-establishing lab, radiology, registry, and e-prescribing connections takes weeks each and involves third parties who do not work to your timeline. On a well-run EHR migration these start on day one, in parallel with everything else. Practices that treat them as a cutover task lose a month of clinical throughput.
04
For an EHR this is not optional prudence, it is how you meet record retention obligations and how you answer a records request about a 2016 encounter. The retention period is years, the cost is real, and it belongs in the business case from the start rather than as a surprise line item afterwards.
01 — 02
A read-only audit of your eClinicalWorks instance produces record counts, a risk register, and a fixed quote. Then a field-by-field mapping document you sign before any code runs.
03 — 04
The complete migration runs into a athenahealth sandbox — not a sample. You spot-check records you choose, and sign a written reconciliation. If the counts don't tie, we don't cut over.
05 — 06
Scheduled around your calendar with the rollback plan written in advance, followed by 30 days of included corrections for the things that only surface in real use.
Complex in essentially every case. Interface re-establishment, provider enrollment, template rebuild, and an AR runout strategy are all standard components rather than optional extras. The assessment is what makes a fixed migration price possible, and its fee is credited toward the migration if you proceed.
Tier
Scope
Price
Migration Assessment
A read-only audit of your source system.
$1,500 – $2,500
Standard Migration
One source system to one destination.
$6,500 – $15,000
Complex / Multi-Entity Migration
Multiple locations, systems, or long history.
$18,000 – $40,000
The core clinical elements — problems, medications, allergies, immunizations, results — carry discretely where the source recorded them discretely. Historical notes and templated documentation predominantly arrive as documents. The only honest answer specific to your practice comes from the assessment, which quantifies it per object. Be sceptical of anyone who answers this confidently without looking at your data.
The normal approach is a runout: you work the existing AR down in the source system while new activity starts in the destination, and retain the source read-only. Trying to migrate an in-flight AR creates reconciliation problems that outweigh the convenience.
Day one, in parallel with everything else. Lab, radiology, registry, and e-prescribing each involve third parties with their own timelines, and they are the most common cause of a delayed go-live. Data volume almost never sets the schedule; interfaces do.
A BAA is signed before any data moves, not after. Work happens in an environment scoped for PHI, access is limited to what the engagement requires, and test data is destroyed at the end on a documented schedule that you receive in writing.
The assessment is the read-only audit — what data exists, what is extractable, what will be lost, and a fixed-price quote for the migration itself. It is priced at $1,500 – $2,500 depending on scope, fixed before anything starts, and the report is yours whether or not you go further.
Tell me what you're moving. I read every one of these personally and reply within one business day, usually with a couple of specific questions about your source system — the answers change the price, so it's worth asking early.
Nothing is committed by this form. No payment, no contract, no scheduling sequence. It starts a conversation.
If your destination vendor can handle it, I'll say so. Some conversions genuinely don't need an independent migration.
Complex
Which Allscripts product you are on.
Standard – Complex
Export terms decide what you can take.
Every pair
Twenty-odd pairs are written up across seven industries — and the written ones are not the limit of the work. Search the full list, or just ask.
eClinicalWorks and athenahealth are trademarks of their respective owners. This page describes independent data migration work involving those systems and does not imply any affiliation with, partnership with, or endorsement by either vendor.
Before you give notice on eClinicalWorks
The most expensive mistake in this category is losing source-system access before the extraction is done. The assessment is read-only, fixed-price, and yours to keep either way.
I respond personally within 1 business day. No pitch — just a real conversation.