Migrating from Tebra

Short answer

For planning, we usually estimate around one business day per practice for the Medi cutover once exports and payer-enrollment inputs are ready; the exact pace depends on export quality, payer mix, and readiness. The data Tebra hands over is real but partial. Patient demographics, claim history, ledger balances, and clinical chart bundles export cleanly. Open-claim working state, in-flight appeals, unposted ERAs, and payer enrollment ties do not. The pattern that protects revenue is a forward-only cutover on Medi with legacy A/R closeout running in parallel inside Tebra. The work that carries revenue risk is payer re-enrollment, parallel-run reconciliation, and a named owner for every open claim.

Estimate around a day per practice

As a working estimate, a clean Medi cutover is often around one business day per client practice once the export files, provider identifiers, payer inventory, and user list are ready. The long-running items are not the Medi migration itself: payer enrollment and legacy A/R closeout run in parallel around the cutover. The risk is not moving quickly; the risk is moving without a named owner for old A/R and payer enrollment.

Two contract terms for the outgoing Tebra arrangement are non-negotiable:

• The outgoing party works all claims with dates of service before cutover for at least sixty days, with monthly performance reporting and aging reconciliation.
• The practice or billing company owns the trailing A/R outright, with documented access to claim history during and after the transition.

Skipping the second clause is the most common revenue leak in a rushed switch. The Medical Billers and Coders 2026 playbook reports that practices missing it pay four to eight weeks of fees just to retrieve their own claim history.

What Tebra actually exports

Tebra's documented export paths are real. The Tebra Help Center export documentation describes:

• Patient demographics via Reports > Patients > Patient Demographic Export
• Bulk clinical data as individual XML Summary of Care files, scoped by signing or assigned provider over a date range
• Patient documents bundled with the clinical export
• A thirty-day SLA on inbound data services agreements when Tebra acts as the receiving system, handled by a Tebra data specialist

Two gotchas matter. First, the chart export drops author attribution: on import into another system, every chart entry defaults to a generic Admin Account. If your compliance audits depend on attribution, keep Tebra read-only access for the existing chart history rather than relying on the imported copy.

Second, the export is patient and clinical-centric. The working state of revenue cycle operations does not come with it: open-claim follow-up notes, in-flight appeal documents, unposted ERAs in the queue, and mid-investigation denial threads. No bulk export moves that state cleanly, Tebra or otherwise, which is the reason a parallel run matters.

Migration planning checklist

EDI enrollment is the long pole

Payer enrollment, not data migration, usually sets the cutover date. Medi routes through a single clearinghouse, Stedi, so claim and ERA enrollment is re-established per payer under a new submitter ID. The CMS Electronic Billing and EDI Transactions guidance and most payer portals describe a process that runs a few weeks per payer at minimum, with wide variance.

The enrollment realities that bite during a switch:

• Anthem and Elevance plans route through Availity as their EDI gateway. If your Tebra setup used a different clearinghouse, that connection is re-established at Availity for the new platform.
• BCBS enrollment varies by state. Texas BCBS is not Florida BCBS.
• Medicare and Medicaid need separate EDI agreements per state Medicaid plan, and Medicaid timelines run weeks longer than commercial payers.
• 835 ERA enrollment is separate from 837 claim-submission enrollment. Miss the ERA piece and cash gets posted from paper EOBs while you wait.

Start enrollment the day the contract is signed, not the day of cutover.

Parallel-run plan

The legacy A/R closeout and the forward-only Medi cutover run side by side for two weeks at minimum. The shape that protects revenue:

• New billing on Medi starts the day after cutover for any encounter dated after the cutover date.
• Tebra keeps receiving and posting ERAs for pre-cutover dates of service for sixty to ninety days.
• Both systems post ERAs for the first two weeks so totals reconcile payer by payer, day by day.
• The outgoing Tebra arrangement reports A/R aging weekly until legacy claims are paid or written off.
• The two teams reconcile daily for the first two weeks, then weekly.

Reconciliation is what catches the ERAs that landed in Tebra but belong to Medi, and the payer responses that came back to Medi for dates of service that belong in Tebra's legacy A/R.

A practice-by-practice rollout protects everyone

Migrating eight client practices at once compresses every gotcha into a single weekend. A staggered rollout is what lets you recover from problems:

• Pick the smallest client with the simplest payer mix for cutover one.
• Run that client end to end in Medi for two weeks before moving the next.
• Carry the lessons forward to the next cutover: specific payer enrollment delays, posting-rule adjustments, user training gaps.
• Move the largest and most complex clients last, once the operational pattern is stable.

For a ready book, around a day per practice is a reasonable cutover estimate. Larger books still move practice by practice, with payer enrollment and legacy A/R tracked in parallel.

What does not migrate, and what to do about it

• Author attribution on historical chart entries. Keep read-only Tebra access for compliance audits rather than trusting the imported copy.
• Open-claim follow-up notes. For any claim still open at cutover, screenshot the Tebra working notes or copy them into a structured handoff document.
• In-flight appeals. Document each one with payer reference number, submission date, appeal level, supporting documentation, and next-action date.
• Unposted ERAs in the Tebra queue at cutover. Post them in Tebra; do not migrate them to Medi.
• Per-payer custom scrub rules. Re-implement them in Medi. The rule library does not move automatically.

What absolutely must move

• Patient demographics, including all insurance coverages and active authorizations
• Provider NPIs, taxonomy codes, and billing identifiers
• Active payer enrollment status and clearinghouse trading-partner relationships
• User roles and practice access permissions
• Custom fee schedules where they differ from Medicare allowables
• The last twelve months of paid claims and posted payments for reporting continuity

Day-zero cutover checklist

On the day of cutover:

• Confirm Tebra is in read-only mode for the migrated practice for new claim creation
• Confirm Medi has accepted the patient and provider imports for that practice
• Confirm payer enrollment for that practice is active in Medi for at least the top-three payers by volume
• Confirm the first claim submission test in Medi passes scrub and reaches the clearinghouse
• Confirm the first ERA can be received in Medi for at least one test payer
• Notify the practice and the payer-facing staff that Tebra is read-only for new work

Frequently asked questions

How long does a Tebra to Medi migration take?

Use around one business day per client practice as the Medi cutover estimate once exports and payer-enrollment inputs are ready. A multi-client billing company still moves practices in waves rather than all at once, with payer enrollment and legacy A/R closeout running in parallel.

Can Medi import open claims from Tebra so we do not have to keep working them in Tebra?

Medi imports historical Tebra claim ledgers as reference-only records when source evidence is strong. Those claims land as Historical: they keep their true balance and stay out of active A/R, aging, statements, Money In, denial queues, and work queues. The safer default is still to leave open cutover work in Tebra under the sixty to ninety day legacy A/R closeout, because open-claim working state does not survive a bulk export cleanly. If a biller later needs to work a historical claim, Medi uses a guarded Make Operational action that surfaces balance, aging, payer, provider, and setup warnings before the claim enters active operations.

What if our outgoing Tebra contract does not include a sixty-day legacy A/R clause?

Negotiate it into the termination agreement before signing the new contract with Medi or anyone else. Without it, the outgoing vendor has no obligation to work claims after the termination date, and your trailing A/R becomes your own problem with no operational team behind it. Practices that skip this routinely lose meaningful revenue on aged claims that simply stop being worked.

Do we need to re-enroll with every payer when switching from Tebra?

Usually yes, for both 837 claim submission and 835 ERA. EDI enrollment is tied to the submitter ID, and that ID changes when the clearinghouse changes; Medi routes through Stedi. Anthem and Elevance plans route through Availity, BCBS varies by state, and Medicare and state Medicaid plans each have their own process. Start enrollment the day the contract is signed.

What happens to chart history during the migration?

Tebra's clinical export produces XML Summary of Care files. The data imports into other systems, but author attribution does not carry forward; chart entries default to an Admin Account on import. For compliance purposes, the working pattern is to keep read-only Tebra access for the historical chart record and use Medi for any new clinical-billing context after cutover.

What does migrating from Tebra to Medi cost?

Migration is free with a 12-month commitment. On a month-to-month plan it is a one-time $100 per client practice, capped at $3,000. Data export is always free, in standard formats, and there is no early-termination fee. The platform itself is $20 per client practice per month, with volume pricing available, plus per-transaction EDI usage. The full schedule is at Medi pricing.

How current is this guide?

Last reviewed 2026-06-07. Tebra export tooling and pricing change, so confirm current terms before you plan a cutover. The source for Tebra's export capabilities is the Tebra Help Center Data Management section. Transition-risk benchmarks come from the Medical Billers and Coders 30-Day Transition Playbook and payer-enrollment constraints from the CMS Electronic Billing and EDI Transactions guidance.