Migrating from Tebra

Short answer

A Tebra-to-Medi migration is a thirty to forty-five day operating-continuity project, not a data export. 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 with a sixty to ninety day legacy A/R closeout running in parallel inside Tebra. Industry guidance from the Medical Billers and Coders 30-Day Transition Playbook reports that practices rushing the switch under twenty-one days typically lose eight to twelve percent of trailing A/R. Treat enrollment carry-over, parallel-run reconciliation, and ownership of every open claim as the load-bearing pieces.

Plan for thirty to forty-five days

Per published industry playbooks for switching RCM platforms, a clean transition takes thirty to forty-five days when credentialing transfers, EDI enrollment, and A/R handoff run in parallel rather than in sequence. Practices that compress the timeline to under three weeks routinely lose eight to twelve percent of trailing A/R, because aged claims need someone working them while the new system stands up.

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

• The outgoing party continues to work all claims with dates of service prior to 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 period

Skipping the second clause is the most common revenue leak in a poorly-run switch. The Medical Billers and Coders 2026 playbook reports that practices missing it routinely pay four to eight weeks of unnecessary 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

There are two known gotchas. First, the chart export does not carry author information forward; on import into another system, every chart entry's author defaults to a generic Admin Account. For a billing service that depends on attribution for compliance audits, plan to 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 — open-claim follow-up notes, in-flight appeal documents, unposted ERAs sitting in the queue, mid-investigation denial threads — does not move cleanly through any per-practice system's export. That is not a Tebra-specific limitation; it is the reason a parallel run matters.

Migration planning checklist

EDI enrollment is the long pole

Payer enrollment is usually the constraint that determines cutover date, not data migration. The CMS Electronic Billing and EDI Transactions guidance and most payer enrollment portals describe a process that takes a few weeks per payer at minimum, with significant variance by payer.

A few enrollment realities that bite during a switch:

• The Anthem and Elevance family of payers route through Availity as their single EDI gateway; if your Tebra deployment uses a different clearinghouse, that connection has to be re-established at Availity for the new platform
• BCBS plans vary in enrollment process from state to state; the Texas BCBS enrollment is not the Florida BCBS enrollment
• Medicare and Medicaid require 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; missing the ERA enrollment means cash gets posted from paper EOBs while waiting

Start enrollment work 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 with a date of service after the cutover date
• Tebra continues to receive and post ERAs for claims with dates of service before cutover for sixty to ninety days
• Both systems post ERAs for at least the first two weeks so totals can be reconciled, payer by payer, day by day
• The outgoing Tebra arrangement reports A/R aging weekly until the legacy claims are either paid or written off
• Daily reconciliation meetings between the two teams for the first two weeks, weekly thereafter

The reconciliation is what catches the ERAs that landed in Tebra after cutover that should have been routed 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. The migration shape that recovers from problems is a staggered rollout:

• Choose 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
• Apply what was learned to the next cutover (specific payer enrollment delays, posting rule adjustments, user training gaps)
• Move the largest and most complex clients last, after the operational pattern is stable

A book of eight clients moves over six to eight weeks under this shape. A book of twenty clients moves over three to four months. The trade is calendar time for execution risk.

What does not migrate, and what to do about it

• Author information on historical chart entries does not migrate from Tebra's export; keep read-only Tebra access for compliance audits rather than relying on the imported copy
• Open-claim follow-up notes do not survive the export cleanly; for any claim still open at cutover, screenshot the Tebra working notes or copy them into a structured handoff document
• In-flight appeals do not migrate; document each open appeal with payer reference number, submission date, appeal level, supporting documentation, and next-action date
• Unposted ERAs sitting in the Tebra queue at cutover should be posted in Tebra, not migrated to Medi
• Per-payer custom scrub rules need to be re-implemented in Medi; do not assume the rule library moves 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

The day cutover happens:

• 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?

Plan for thirty to forty-five days from contract signing to first production use for a single client practice, including payer enrollment work. A multi-client billing company moves practices in waves rather than all at once, so a book of eight clients typically moves over six to eight weeks. Per industry playbooks, transitions rushed under twenty-one days lose eight to twelve percent of trailing A/R.

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

Importing closed historical claims is not recommended because it duplicates ledgers and produces reconciliation errors that compound for months. Open claims at cutover are a more nuanced question: the working state of a denied or appealed claim does not transfer cleanly through any export, so the pattern that works is to leave open Tebra claims in Tebra under the legacy A/R closeout arrangement for sixty to ninety days, and run Medi forward-only.

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?

Yes for ERA and 837 claim submission enrollment in most cases, because EDI enrollment is tied to the submitter ID, which changes when the clearinghouse changes. The Anthem and Elevance family of payers route through Availity; BCBS varies by state; Medicare and state Medicaid plans have separate processes. Start payer enrollment work 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.

How current is this guide?

Last reviewed 2026-05-17. Tebra export tooling and pricing change. The source for Tebra's current export capabilities is the Tebra Help Center Data Management section. Industry migration timelines are drawn from the Medical Billers and Coders 30-Day Transition Playbook and the CMS Electronic Billing and EDI Transactions guidance.