# Migrating from Tebra

What billing companies should consider before moving accounts, claims, and payment workflows from Tebra to Medi.

URL: https://medibilling.app/migration/tebra
Last reviewed: 2026-07-27

# Migrating from Tebra

## Short answer

The Medi cutover itself runs about a business day per practice once exports and enrollment inputs are ready. That is a planning target for scheduling, not an average measured across a book of completed cutovers, and the real pace depends on export quality, payer mix, and readiness. Migration is a concierge service the Medi team runs directly; there is no self-serve migration uploader. 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.

## Plan on about a day per practice

Use about one business day per client practice as the planning target for the Medi cutover once the export files, provider identifiers, payer inventory, and user list are ready. It is a number for building a schedule against, not a benchmark drawn from a long track record, so treat it as the starting assumption and adjust it after your first practice moves. The Medi team runs the cutover work directly with you rather than handing you an import tool.

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](https://www.medicalbillersandcoders.com/blog/switch-medical-billing-companies/) 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](https://helpme.tebra.com/Platform/Practice_Settings/Data_Management/Export_Patient_Clinical_Data) 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

| Workstream | What to inventory before migration | Why it matters |
|---|---|---|
| Practices | Active clients, locations, providers, billing identifiers, and permission boundaries | Practice context determines user access and operational reporting from day one |
| Open claims | Open, rejected, denied, appealed, aging buckets, and payer status for every claim with a date of service in the last 120 days | Open work needs continuity during cutover, not a fresh start |
| ERAs and payments | ERA enrollment, posted and unposted payments, unapplied cash, EOB workflows, write-off tolerances, and recoupment adjustments | Payment posting affects ledgers, balances, and client trust |
| Payer enrollment | Payer IDs, clearinghouse trading partners, EDI enrollment status, eligibility connections, and claim-status dependencies | Enrollment can block production for weeks even when patient data is imported |
| Users and roles | Account managers, posters, follow-up staff, admins, offshore contractors, and practice-level access | Migration should preserve who can see and act on which account |
| Reports | Month-end, client reporting, A/R, denial, payment, and productivity outputs | Owners need continuity in how they manage the business |
| Custom rules | Per-payer scrub rules, write-off thresholds, automatic posting rules, follow-up cadences | Custom configuration often holds the institutional knowledge of years of billing work |

## 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](https://www.cms.gov/medicare/coding-billing/electronic-billing) 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.

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. Medi does not have a per-payer rule library to rebuild them in. It runs one global pre-submission scrubber for every claim, and the payer-level rules you can author are prior-authorization and referral requirements, enabled per billing company during onboarding. Inventory what your Tebra rules were catching, then decide which of those checks the global scrubber already covers and which become a follow-up or coding-review step instead.

## What absolutely must move

- Patient demographics, including all insurance coverages and active authorizations
- Provider NPIs, taxonomy codes, and billing identifiers
- A documented inventory of active payer enrollment status and clearinghouse trading-partner relationships. Enrollment itself is not imported; it is re-established payer by payer through Stedi, and the inventory is what you work that re-enrollment from
- 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, charge, and payment imports for that practice. Those are the three import lanes; providers are set up directly in Medi rather than imported, so verify the provider records were built and match the source before the first claim
- 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?

Plan on about one business day per client practice for the Medi cutover once exports and enrollment inputs are ready. Treat that as a planning target rather than a measured average. 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, and the Medi team runs the cutover work with you.

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

The history and the open balances do come across. Medi imports Tebra claim ledgers as a read-only historical-reference ledger when source evidence is strong, preserved to the cent and visible beside live work. Those claims land as Historical: they hold their true balance but stay out of active A/R, aging, statements, Money In, denial queues, and work queues until someone deliberately promotes one on a dated action. So nothing is stranded in Tebra and nothing pollutes the new book, which is what kills the tax of keeping the old system running forever just to read a balance.

That is not the same as balances arriving live and workable. Open-claim working state does not survive a bulk export cleanly, so the safer default is still to leave open cutover work in Tebra under the sixty to ninety day legacy A/R closeout. When a biller does need 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. Medi itself starts at $1.00 per claim and steps down to $0.90 and then $0.80 as monthly volume crosses the published tiers, with no monthly fee, no per-practice fee, and no per-provider fee, plus per-transaction EDI usage for eligibility and claim status. COB inquiry is priced the same way but is in controlled rollout, turned on during onboarding rather than by default. ERA posting is included in the claim price. The full schedule is at [Medi pricing](/pricing).

### How current is this guide?

Last reviewed 2026-07-27. 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](https://helpme.tebra.com/Platform/Practice_Settings/Data_Management/Export_Patient_Clinical_Data). Transition-risk benchmarks come from the [Medical Billers and Coders 30-Day Transition Playbook](https://www.medicalbillersandcoders.com/blog/switch-medical-billing-companies/) and payer-enrollment constraints from the [CMS Electronic Billing and EDI Transactions guidance](https://www.cms.gov/medicare/coding-billing/electronic-billing).