Changing EHRs is not primarily a data problem. The export is a solved, well-understood step; what goes wrong is sequencing—contracts signed before anyone asked how the data comes out, subscriptions cancelled before anyone checked the migration worked, and go-live dates set for the busiest week of the year.
Here's the checklist, roughly in the order the work actually happens. Plan in months, not weeks, and expect most of that time to go to things other than moving records.
Read the exit terms in the contract you're leaving
Before anything else, find your current agreement and answer four questions: How much notice must you give? What happens to your data after termination, and how long do you have to retrieve it? Are there export fees? And is there an auto-renewal date that's about to make this decision for you?
That data-destruction window is the one that bites. Vendors commonly keep your data for a defined period after termination and then delete it, and that's ordinary practice rather than anything sinister—storage costs money, and no vendor wants to hold your records forever. DrChrono's terms, for example, say customer content "may be retained for 30 days and then destroyed." Read that as a planning constraint rather than a guarantee: it tells you roughly how much room you have, not exactly. Credit where it's due—DrChrono states this plainly in public terms, and its EHI export is self-service at no additional charge, which is more than every vendor offers. Your migration schedule still has to fit inside whatever your own contract says, with room to spare, and the safe approach is never to start the clock until the new system is verified and running.
Negotiate the exit before you sign the entrance
The best moment to secure your future data rights is while a salesperson wants your signature. Before signing with the new vendor, get in writing: what export formats they support and at what cost, what migration help is included, whether they'll accept the specific shape your old data comes out in, and the same destruction-window terms you just went looking for in the old contract.
Practices that skip this step tend to discover the answers two years later, in a hurry, from a support ticket.
Inventory what you have, with counts
Write down what exists before you move it: patients, appointments past and future, clinical notes, problem lists, medications, allergies, lab results, documents and scanned attachments, and billing history. Attach real numbers—how many patients, how many documents, how many open claims.
That inventory is the only thing that later lets you prove the migration worked. On the mechanics of getting the data out, our guide to exporting from DrChrono walks through the routes—built-in exports, the API, and the electronic health information export every certified EHR must offer. The routes differ by vendor; the inventory discipline doesn't.
Decide what actually has to migrate
Not everything needs to land inside the new system, and pretending otherwise is how migrations balloon.
Three tiers usually make sense. Structured data that must be live—active patients, demographics, medications, allergies, problem lists, future appointments—goes into the new system properly, in its fields. History that only needs to be readable—closed notes, old documents, historical results—can often live as an attached archive rather than a fully mapped import. And billing needs its own decision: many practices leave open claims to run their course in the old system rather than migrating a live accounts-receivable mess mid-flight.
Deciding this early cuts cost and risk, because mapping structured data into a new system's fields is the expensive part.
Run both systems in parallel
Pick a cutover date, and keep the old system available—read-only is ideal—for a defined period afterward. This is the single practice that separates calm migrations from bad ones.
Choose the date deliberately: a slower stretch, never the start of a busy season, and not the week a key staff member is away. Front-load training so staff are learning the new system before it's the only one. Expect a real productivity dip for a few weeks; schedule slightly lighter and tell everyone it's expected, so nobody concludes on day three that the project failed.
Two things need explicit owners during the overlap: which system is the source of truth from the cutover moment on—one answer, written down, no exceptions—and who handles anything that arrives addressed to the old system.
Verify before you cancel anything
Now the arithmetic from your inventory. Does the new system show the patient count you wrote down? The document count? Spot-check a sample of charts against the old system, field by field. Open documents at random and confirm they're readable rather than corrupted placeholders. Confirm future appointments made the trip, because that's the failure staff will find at 8 AM on go-live day.
Only when that passes do you start the termination clock. Keeping the old subscription running an extra month is the cheapest insurance in this project, and cancelling early to save one month's fee is the most expensive way to save money in practice operations.
Keep an archive, permanently
The last step gets skipped because by then everyone is exhausted. Take a complete, verified copy of the old system's data and store it somewhere you control, independent of either vendor—with the documents, not just the spreadsheets, and with a note explaining what's in it for whoever opens it in five years.
You need this because the practice, not the software vendor, is generally the one on the hook for retaining patient records. In New York, the physician retention floor is six years as the statute reads, with longer periods for obstetrical records and for minors—broadly, six years and until about a year past the patient's 18th birthday. If you also employ nurses, social workers, or psychologists, a separate rule appears to put their records on a longer clock again.
I'm summarizing those rules, not advising on them, and I'm not a lawyer. Which ones actually bind your practice depends on your licensure mix, your specialty, and sometimes your payers, and the details are exactly where this gets fiddly. Treat the longest period that could apply to anyone on staff as your planning assumption, and have counsel confirm the real numbers before you rely on them. What isn't in doubt: a subscription you've cancelled is not a records retention plan.
To say it once more, plainly: I'm not a lawyer, and none of this is legal advice. Retention rules, contract terms, and information-blocking questions all turn on details I can't see from here, so get your counsel to sign off on the plan before you cancel anything.
If the reason you're switching is that the subscription stack stopped making sense, our custom vs. off-the-shelf comparison covers that math—the monthly fee was never the lock-in; the data is. And if you'd rather hand the export and verification to someone who has done it end to end, that's work we do for practices: our app development service scopes it with a written inventory first and a fixed quote, starting with a free conversation.