I wrote the standard for making websites AI-operable. Learn More

Migration · Allscripts to athenahealth

Before anything else: which Allscripts are you actually running?

"Allscripts" has covered several genuinely different products over the years, with different data models, different deployment shapes, and different export paths. A migration plan written without establishing which one you are on is not a plan, it is a template.

So the first deliverable here is narrower and more useful than it sounds: an unambiguous statement of what you are running, what that means for extraction, and what it implies about how much of your chart survives as discrete data rather than as documents.

— extraction How the data comes out of Allscripts

Certified EHRs support standards-based clinical export, and C-CDA is the usual mechanism for the clinical summary — with the important caveat that C-CDA is an interchange standard, not a full-fidelity database export. Beyond that, the available paths depend materially on which product and deployment you are on, and whether it is hosted or installed. Establishing that is the first task of the assessment, because everything downstream — cost, timeline, and how much arrives discretely — follows from it.

— what moves Object by object

What transfers to athenahealth.

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 medical record number strategy decided early.

Insurance and coverage

Payers, plans, subscriber relationships, and active coverage so eligibility and billing function on day one.

Problem list

Active problems with coded diagnoses, discrete where the source coded them discretely.

Medications and allergies

Active medication and allergy lists as discrete coded data — the clinical safety objects, validated as their own step with their own sign-off.

Immunizations

Immunization history with dates and products.

Results and diagnostic history

Laboratory and diagnostic results, discrete where held discretely and as documents where not.

Encounter notes and clinical documents

Historical notes and documents attached to the correct patient and encounter, predominantly in document form for historical depth.

Appointments

Future scheduled appointments with types and providers.

— the honest part What does not survive this migration

Written down before you spend anything, because the alternative is finding out in week six. This list is specific to Allscripts to athenahealth; the assessment turns it into your list, with record counts attached.

— Full discrete fidelity for historical charting. Core clinical elements carry discretely; the long tail arrives as documents. Quantified per object in the assessment.

— Accounts receivable as a working AR. A runout in the source system with the source retained read-only is the standard approach.

— Custom templates, order sets, macros, and clinical decision support configuration. Rebuilt in the destination as a substantial separate project.

— Interfaces: lab, radiology, HIE, immunization registry, e-prescribing, and pharmacy. Re-established rather than migrated, each with weeks of lead time and some with enrollment steps that cannot be compressed.

— E-prescribing and controlled-substance prescribing authority. Provider enrollment and identity proofing, not data, and they gate day-one prescribing.

— Product-specific configuration and any third-party modules layered onto your Allscripts installation. Named in the assessment rather than discovered at go-live.

— quirks The parts that decide whether this goes well

What actually goes wrong on this pair.

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

Establish the product and deployment before anything else

Extraction path, contractual export rights, and realistic discrete-data yield all differ by product and by whether you are hosted or installed. Any plan or price produced before this is settled should be treated as provisional, including mine — which is exactly why the assessment exists and why it is priced separately.

02

C-CDA is a summary, not an export

It communicates a clinical summary between systems and it does that well. It does not reproduce a source database. Proposals that treat it as a full archive are the most common misrepresentation in this category.

03

Interface lead times set the schedule

Lab, radiology, registry, and e-prescribing connections each involve third parties on their own timelines. They start on day one and run in parallel, because they — not data volume — are the usual cause of a delayed go-live.

04

Retain the source read-only, for years

Record retention obligations do not end at cutover. The retained system is how you answer a records request about an old encounter, and its cost belongs in the business case from the start.

— process Same six steps, every pair

Nothing touches production until you've signed off.

01 — 02

Assessment, then mapping

A read-only audit of your Allscripts 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

Test load, then validation

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

Cutover, then warranty

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.

The full six-step process, written out →

— pricing Where this pair usually lands

What a Allscripts to athenahealth migration costs.

Complex in essentially every case, with the product-identification step front-loaded because it determines the shape of everything after it. 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

— FAQ Allscripts to athenahealth

Questions specific to this pair.

We are not sure which Allscripts product we have.

That is common and it is fine — identifying it is the first thing the assessment does. It matters more than almost anything else you could tell me, because extraction path, export rights, and realistic discrete-data yield all follow from it.

How much of our chart arrives as discrete data?

Core clinical elements carry discretely where they were recorded discretely. Historical notes and templated documentation largely arrive as documents. The number specific to your practice comes from the assessment, per object, and I would be suspicious of anyone who gives you a confident figure without examining your data.

What about our billing and AR?

Standard approach is a runout: work the existing AR down in the source while new activity starts in the destination, with the source retained read-only. Coverage and payer data migrate so that new billing works from day one.

How is PHI handled?

BAA signed before any data moves. 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 you receive in writing.

— start here Step 1 of the process

Request a Allscripts to athenahealth assessment.

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.

I respond personally within 1 business day. Your details are used to answer you and nothing else — no list, no sequence.

— other pairs Same process, same industry

Other medical migrations written up.

Complex

eClinicalWorks → athenahealth

Discrete data versus a PDF of your chart.

Standard – Complex

Practice Fusion → Tebra

Export terms decide what you can take.

Every pair

A different system

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.

Allscripts 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 Allscripts

Find out what's actually recoverable.

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.