EMR Migration Checklist for Texas Healthcare Providers

This checklist sits under our guide to managed IT for Texas healthcare practices, and it covers the work a practice owns no matter which platform it picks or which vendor sells it.

Most practices choose a new EMR for good reasons. Better templates. A cleaner patient portal. A vendor that actually calls back. Then the migration starts. Something odd happens. The old vendor is leaving, the new vendor is arriving, and nobody owns the ground in between. That’s where charts go missing.

I’m the Lead vCIO at Uprite, and I spend a lot of time on the IT side of projects like this for practices in Houston, Dallas and San Antonio. The software is rarely what breaks. What breaks is the contract nobody read for export terms, the scanner driver nobody tested, and the allergy list everyone assumed came across clean, and each of those failures tends to surface weeks after the vendor has closed its implementation ticket. Below are the 30 checks we work from, grouped into 5 phases, along with the Texas rules that change the plan and the federal export rule most practices have never heard of.

What Is an EMR Migration?

An EMR migration is the move from one electronic medical record system to another, including the transfer of patient data, the rebuild of interfaces to labs, pharmacies and billing, staff retraining, and the retirement or archiving of the old system. The data transfer itself is usually the smallest part of the work.

People use EMR and EHR interchangeably. So does this post. Texas statutes say electronic health records, and the difference doesn’t change a single item on the list.

What does change the list is where you practice. A clinic in Katy and a clinic in Ohio share the same HIPAA obligations, yet only the Katy clinic also answers to the Texas Health and Safety Code, the Texas Medical Board and the Texas attorney general. That’s a real difference.

Which Texas Rules Change an EMR Migration Plan?

Five Texas rules and one federal rule decide most of the hard edges. Here’s where each one lands.

Two corrections I make often. First, Chapter 183 of the Health and Safety Code is a storage rule. It doesn’t ban offshore access by name. It limits access by job duty, and it reaches records stored on or after January 1, 2026, no matter when they were created. Violations carry attorney general penalties of up to $5,000 each when negligent and $25,000 when knowing, per year. So read the statute yourself before a vendor explains it to you in either direction.

Second, the retention clock under Texas Medical Board rule 163.2 runs from the last treatment date. A patient you saw last week pushes that chart’s retention out to 2033. Switching vendors doesn’t reset anything.

Phase 1. What Should the Contract Say Before You Sign?

The cheapest time to fix a migration is before the signature. After it, every missing term becomes a change order. Change orders add up.

Start with your old vendor. Under the federal information blocking rule at 45 CFR 171.302, a fee for exporting data through a certified EHI export when the purpose is switching health IT falls outside the fees exception, and so does a fee to export or convert data that wasn’t agreed to in writing when you bought the system. Certified systems must be able to produce a full patient population export under the ONC EHI export criterion. Pull your original agreement. Read it twice. If the old vendor quotes a deconversion fee, ask which of those provisions they believe it fits. Then wait. It usually tells you plenty.

1. Get the old vendor’s export format, delivery method and timeline in writing, including the full patient population export.
2. Confirm read-only access to the legacy system for as long as your retention clock runs, and price it now.
3. Ask the new vendor where every copy of your data physically sits, including backups and disaster recovery replicas.
4. Sign a business associate agreement with every party that touches the data, including the conversion vendor and any cloud host.
5. Put data validation and a rollback plan in the statement of work, with a named owner on each side.
6. Set the go-live date around your billing cycle and staffing, not the vendor’s install calendar.

That fourth item is easy to underestimate. HHS guidance on cloud computing says a cloud provider that stores ePHI is a business associate even when it only holds encrypted data and has no key to read any of it. That covers a conversion vendor’s staging servers too. They’re easy to forget. They only exist for a few weeks. Get the agreement anyway.

Phase 2. What Data Should You Migrate, and What Should You Archive?

Not everything should move. Pushing 15 years of scanned faxes into a new system mostly migrates clutter, and every extra gigabyte adds conversion time and validation work for your staff, who are learning a new system at the very same time.

There’s no industry recipe for this part. A 2023 systematic review in the Journal of General Internal Medicine pooled 40 publications on EHR-to-EHR transitions, and one of the works it cites found that no two sites approached data migration the same way. That matches what we see. So your practice writes its own recipe, and somebody signs it. Put a name on it.

1. List every data source, including the EMR, the practice management system, imaging, the portal, e-fax and any shared drive holding scanned records.
2. List every interface. Labs, e-prescribing, the immunization registry, the clearinghouse, reminder tools and devices.
3. Map each field from the old system to the new one, and flag anything that lands in a free-text box.
4. Merge duplicate patients first.
5. Agree on cutoff dates for results and documents with your clinicians.
6. Write down what stays in the archive, so nobody hunts for it in the new system later.

Phase 3. Which Security and Compliance Checks Belong in the Plan?

An EMR switch changes where ePHI lives, who can reach it and how it moves. Your HIPAA risk analysis has to keep up. A migration also creates exposure that didn’t exist last quarter. Full patient exports on a laptop. A staging server at the conversion vendor. A shared folder called final export. You’ve seen that folder.

Those files are a real target in Texas. The HHS OCR breach portal lists 57 breaches of 500 or more records reported by Texas organizations in 2025, and a network server was listed as a breach location in 31 of those 57 reports. An export sitting on a file server fits that pattern exactly. Lock it down.

1. Update the HIPAA risk analysis to cover the export, the transfer, the staging environment and the new system.
2. Encrypt every export file at rest and in transit, and log who opens it.
3. Turn on multi-factor authentication in the new EMR from day 1, vendor support accounts included.
4. Build user roles around treatment, payment and operations duties, which is the access test in Health and Safety Code 183.002(b).
5. Ask the new vendor how it handles the Chapter 183 requirements for parental access to minors’ records and the separate biological sex field.
6. Walk the team through the Texas breach clock, so a lost export file triggers the 60-day and 30-day notices on time.

The breach timelines come straight from Business and Commerce Code 521.053. If you want the full compliance view beyond the migration window, our Texas HIPAA IT compliance checklist covers HB 300 training and the rest of the program.

Phase 4. Is Your Network Ready for the New EMR?

Here’s my honest take. When a go-live goes badly, the software gets the blame. Usually it isn’t.

A cloud EMR is only as fast as the circuit in your building and the firewall behind it, which is where our network security services come in. The new platform may want a different browser, a new scanner driver, a signature pad your front desk PCs can’t run, or a print setup nobody has touched in years. None of that shows up in a demo. All of it shows up at 8 in the morning on go-live Monday. Running more than one clinic? Repeat every device test at each site, and see our multi-location medical IT guide for the rest of that picture.

1. Check the vendor’s workstation requirements against a real inventory, device by device.
2. Test every scanner, signature pad, label printer and card reader in each exam room and at the front desk.
3. Measure internet capacity at peak hours, then add a second circuit with automatic failover.
4. Load a sample of real charts into a test environment and have clinicians compare them against the old system.
5. Reconcile allergies and active medication lists for every active patient.
6. Rehearse downtime procedures before go-live, using the SAFER Contingency Planning guide as the outline.

That fifth item sounds like overkill. It isn’t. A 2026 quality study at a pediatric research hospital reviewed 197 patients with penicillin allergies a year after an EHR switch and found discrepancies between the old and new allergy lists in 72 of them, or 36.5%. Three had been relabeled allergic after earlier de-labeling. Three more were wrongly listed as not allergic. Those hurt people.

For the sixth item, the 2025 SAFER Guides from ONC are free, and the Contingency Planning guide covers planned and unplanned EHR unavailability as well as data lost in transmission. Downtime is expensive. Our EMR downtime cost breakdown puts lost productivity at about $488 per hour, per physician, before any billing cleanup starts, and that clock runs whether the outage is the vendor’s fault or a failed circuit in your own closet.

Phase 5. How Do You Handle Cutover, Go-Live and the Old System?

Cutover is a weekend. Everything around it takes months.

1. Freeze scheduling and charge entry in the old system at a set time, then run a final delta export.
2. Keep the old practice management system open for claims and A/R until the balance is worked down.
3. Staff go-live week with extra support at the front desk and in clinical areas, on site where you can.
4. Route patient record requests through one person during cutover, so the 15-business-day clock doesn’t slip.
5. Move the legacy data into a read-only archive that is backed up, access-controlled and stored in the United States.
6. Retire old servers and workstations only after the archive is verified, and sanitize their drives following NIST SP 800-88 Rev. 2.

Item 4 catches practices off guard. Under Health and Safety Code 181.102, a patient who asks for an electronic copy during your switch is still owed it within 15 business days, and for a few weeks that record may live in 2 systems. Decide ahead of time who pulls from which one. Write it down.

The archive is the decision with the longest tail. Rule 163.2 requires access for the full retention period, and old platforms get retired. Vendors get acquired too. A searchable read-only archive under your control usually outlives the vendor’s sunset schedule, and our data backup services protect archives like that, with encrypted and tested copies kept inside the United States. Before you trust any archive, run it past our backup questions for MSPs. When those old drives finally leave the building, NIST SP 800-88 Rev. 2 is the sanitization standard to follow. Keep the certificate.

How Long Does an EMR Migration Take?

Longer than you’d guess. The install is one piece. Contract review, data mapping, validation and working down old A/R all wrap around it, and each one has its own owner and its own calendar that rarely lines up with the vendor’s.

Plan backward from 2 dates. The day the old contract ends, and the day you want old A/R closed. If those dates don’t leave room for a test migration and a rehearsal, move the go-live. Don’t cut the testing.

Expect a dip afterward, too. The same 2023 review found that all 4 studies measuring time on encounters and in the EHR before and after a switch reported negative effects on productivity for the clinicians using the new system. In another study it covered, patient satisfaction fell across 6 Mayo Clinic sites and took 9 to 15 months to return to baseline. Lighter templates for the first weeks cost less than overtime. And less than burnout.

Where Do EMR Migrations Usually Go Wrong?

• Export terms nobody read until the old vendor sent an invoice.
• Allergy and medication lists assumed complete because the import finished without errors.
• Scanned documents that arrived without a patient or date index.
• Interfaces tested once, with test patients, and never with real orders.
• Front desk PCs that couldn’t run the new scanner or signature pad.
• A single internet circuit carrying the entire practice.
• Old servers wiped before anyone confirmed the archive opened.
• Nobody owning the archive.

Look at that list again. Most of it is IT work wearing a software badge. That’s why I tell practices to bring their IT partner in at contract review, not at go-live, when the expensive decisions are already made and the vendor’s timeline is already printed on the kickoff deck. If you’re budgeting for that support, our HIPAA-compliant IT cost guide puts managed IT for Texas healthcare practices at $165 to $250 per user per month.

Who Should Own the IT Side of an EMR Migration?

Your EMR vendor owns the software and the data load. Somebody still has to own the network, devices, accounts, security and archive. At most small practices, that job lands on the office manager by default. It shouldn’t.

Uprite has supported Texas organizations since 1999 with a team of 42, and we hold the Compliancy Group HIPAA Seal of Compliance and a SOC 2 Type 1 report. We’ve built HIPAA-ready infrastructure for healthcare clients, including a multi-location dental surgery group that grew to 4 offices, and the IT side of an EMR switch is work our engineers take on next to the vendor, not instead of it. If you also want help with the vendor contract and the roadmap around the switch, that’s what our vCIO services are for.

Questions Texas Practices Ask Before Switching EMRs

Can my old EMR vendor charge me to export my data?

How long do Texas practices need to keep old EMR records?

Does SB 1188 limit which EMR vendor a Texas practice can use?

Do we need a new HIPAA risk analysis after switching EMRs?

Should we migrate every old chart into the new EMR?

What is the most overlooked step in an EMR migration?