# Migrating from Kareo

How billing companies move accounts, claims, and payment workflows from Kareo (now Tebra) to Medi.

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

# Migrating from Kareo

## Short answer

Kareo is Tebra. The merger closed November 2, 2021, and the Kareo brand has since been folded fully into tebra.com. If you are still searching for "Kareo migration," you are on a legacy Kareo-branded contract, working from documentation that predates the rebrand, or both. The migration playbook is the same either way, because the product is the same product.

The Medi cutover itself runs about a business day per practice once exports and enrollment inputs are ready, while payer enrollment and legacy A/R continue in parallel. That is a planning target, not an average from a track record, and the Medi team runs the migration as a concierge project rather than handing you an import tool. Tebra's documented exports are real: patient demographics, charges, unpaid insurance claims, A/R aging, and fee schedules all come out in Excel or CSV. Clinical history exports as XML Summary of Care files. What does not move cleanly is everything in flight, the open-claim working notes, unposted 835 ERA files, in-progress appeals, and the EDI enrollment ties that keep claims routing to the right clearinghouse. The pattern that protects revenue is a forward-only Medi cutover with legacy A/R closeout running in parallel inside Tebra.

Migration to Medi is free with a 12-month commitment, or a one-time $100 per client practice (capped at $3,000) month-to-month. Data export from Medi is always free in standard formats. There is no termination fee; the annual commitment is the only lock-in. Medi itself starts at $1.00 per claim, with no monthly fee and no per-practice fee; the full schedule is at [/pricing](/pricing).

## Kareo is Tebra now — does that change the migration?

Operationally, no. The product you used as "Kareo" and the product now branded "Tebra" share the same claim submission infrastructure, the same clearinghouses (Trizetto Provider Solutions for medical and institutional claims, Jopari Solutions for workers' comp and auto), and the same help center. The old helpme.kareo.com URLs 301-redirect to helpme.tebra.com. Your EDI enrollments, payer connections, and data all live inside what is now the Tebra platform, regardless of which name is on your contract.

Three things are worth checking if you are on a legacy Kareo contract rather than a current Tebra agreement.

1. **Termination notice window.** [Tebra's pricing policy](https://www.tebra.com/pricing-policy) requires 60 days written notice before the end of the current term. A legacy Kareo contract may have set different terms. Pull the contract and find the non-renewal clause before you commit to a cutover date. A missed notice window locks you into another renewal period no matter what the new platform is ready to do.
2. **Support and data rights.** Kareo customers who never formally moved to the Tebra product may be on a support tier that predates Tebra's current packaging. If your account manager came through kareo.com before December 2024, confirm which contract terms govern your data export rights and closeout window.
3. **Historical documentation.** Older PDFs and training materials that say "Kareo" may describe menu paths since reorganized under the Tebra brand. Trust current helpme.tebra.com content over any PDF with "Kareo" in the header.

Beyond those, the mechanics are identical to a current Tebra migration. See [the full Tebra migration guide](/migration/tebra) for the complete cutover playbook. This page covers the Kareo-specific framing a billing company needs before the tactical work starts.

## Plan on about a day per practice

Use about one business day per practice as the planning target for the Medi cutover once the Kareo/Tebra export, provider identifiers, payer inventory, and user list are ready. It is a scheduling assumption rather than a measured average, so adjust it once your first practice has moved. Payer enrollment and A/R handoff run in parallel around that cutover. The revenue risk is not speed by itself; it is moving without ownership for aged claims and enrollment follow-up.

For a billing company on a legacy Kareo contract, the clock starts from your written non-renewal notice, not from when you first contact Medi. If the contract renews annually and you are 60 days out, you either have a year to pace the migration or a hard deadline to hit the notice window before the next term. Which one is a contract-reading question, not a software question, and it is the first decision to make.

The same two non-negotiable contract terms apply here that apply to any Tebra-platform exit: the outgoing party keeps working pre-cutover claims for at least 60 days with reconciliation reporting, and the billing company owns its trailing A/R outright with documented access to claim history after termination. See [the Tebra migration guide](/migration/tebra) for the full language to put in the termination agreement — the clause billing companies most often negotiate away by accident is the second one, and skipping it is what turns a routine switch into weeks of paying the outgoing vendor just to retrieve your own records.

## What the Kareo/Tebra export actually captures

The [Tebra Help Center's practice information export guide](https://helpme.tebra.com/Tebra_PM/11_Run_Reports_and_Analytics/05_Provider_and_Practice_Reports/Reporting_Export_Practice_Information) documents five recommended reports for account closure or data backup:

- Patient Demographic Export: complete patient information with balance details, via Reports > Patients
- Charges Export: encounter-based charge data scoped to a custom date range
- Unpaid Insurance Claims Export: outstanding insurance claim inventory at the time of export
- Accounts Receivable Aging: broken out by insurance and patient, in Excel, CSV, and PDF
- Standard Fees and Contract Rates: fee schedules and insurance contract rates, exported per schedule to Excel

Clinical history comes through a separate path. The [Tebra Help Center export documentation](https://helpme.tebra.com/Platform/Practice_Settings/Data_Management/Export_Patient_Clinical_Data) describes bulk XML Summary of Care files, scoped by provider and date range, delivered as a ZIP with patient documents bundled in. One-time and recurring exports are both available.

Two known gaps. First, author attribution does not carry through the clinical XML export. When the Summary of Care files import into another system, chart entries default to a generic Admin Account instead of the original provider. For compliance audits that attribute a clinical decision to a specific clinician, keep read-only Tebra access for the historical chart rather than relying on the imported copy.

Second, the export inventory above covers structured data only. The working state of revenue cycle operations does not come out cleanly through any per-practice system's bulk export: open-claim follow-up notes, mid-investigation denial threads, in-flight appeal documents, and the unposted 835 ERAs sitting in the queue. This is not a Tebra-specific limitation. It is why the forward-only parallel-run pattern exists.

## Migration planning checklist

| Workstream | What to inventory before migration | Why it matters |
|---|---|---|
| Contract and termination | Non-renewal notice date, legacy Kareo vs current Tebra agreement, data access rights post-termination | Sets the hard constraints on timeline before any operational planning starts |
| 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 status, 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, Trizetto and Jopari trading partner relationships, EDI enrollment status, eligibility connections, and 276/277 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 |
| Help center bookmarks | Which helpme.kareo.com URLs your team uses daily | Those URLs 301-redirect to Tebra documentation; update internal wikis and training materials during migration, not after |

## EDI enrollment is the long pole

Payer enrollment, not data migration, is usually the constraint that sets the cutover date. Tebra's enrollment FAQ puts claim submission enrollment at "typically between one to eight weeks" per payer, and 835 ERA enrollment longer at "typically between two to eight weeks," because ERA enrollment is a separate process from 837 claim submission. Miss the ERA enrollment and cash posts from paper EOBs while you wait, a real operations cost in an otherwise clean cutover.

Tebra routes medical and institutional claims through Trizetto Provider Solutions, and workers' comp and auto claims through Jopari Solutions. Medi uses Stedi, so every payer connection moves to a new trading partner. The [CMS Electronic Billing and EDI Transactions guidance](https://www.cms.gov/medicare/coding-billing/electronic-billing) documents how to update EDI submitter relationships, and the variance by payer is wide.

Enrollment realities specific to the Kareo/Tebra population that bite during a switch:

- Anthem and Elevance plans route through Availity as their EDI gateway. If your Kareo deployment used Availity for Anthem claims, that connection is between your practice's Tax ID and Availity. You re-register the same Tax ID under the new clearinghouse; you do not inherit the old Trizetto relationship.
- BCBS plans vary enrollment by state. Texas BCBS is a different form and timeline from Florida BCBS, and each state plan processes independently.
- 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 in every payer's system. Completing claim enrollment does not trigger ERA enrollment.
- 270/271 eligibility and 276/277 claim status are separate enrollments too, not bundled with claim submission.

Start enrollment the day the contract is signed. For a billing company moving eight client practices, enrolling all of them at once is overwhelming, which is part of why the practice-by-practice rollout below paces the work.

## Parallel-run plan

The legacy A/R closeout and the forward-only Medi cutover run the same way here as in [the Tebra migration guide's parallel-run plan](/migration/tebra): side by side for two weeks at minimum, ERAs posting in both systems so totals reconcile payer by payer, and reconciliation meetings daily for the first two weeks, then weekly.

One wrinkle specific to a Kareo-era book: check the Tebra unposted ERA queue before cutover for anything left over from before the rebrand, and post it before it becomes an orphaned line nobody can trace back to a claim.

## A practice-by-practice rollout protects everyone

[The Tebra migration guide](/migration/tebra) covers the staggered-rollout shape this follows: smallest, simplest client first, two weeks to prove the pattern, largest and most complex last. Larger books are still sequenced practice by practice here. For a billing company on a legacy Kareo contract, the separate timing constraint is the notice window, not the Medi migration duration.

Under [Medi's multi-practice workspace](/billing-company-operations), the practice-by-practice rollout is also the right onboarding shape. Each client practice is a scoped tenant inside the billing company workspace, with permissions, payer rules, and reporting configured per practice.

## What does not migrate, and what to do about it

- Author attribution on historical chart entries does not survive Tebra's XML export. Keep read-only Tebra access for compliance audits rather than relying on the imported copy.
- Open-claim follow-up notes do not export cleanly. For any claim still open at cutover, screenshot the working notes in Tebra or copy them into a structured handoff document before cutover day.
- In-flight appeals do not migrate. Document each open appeal with payer reference number, submission date, appeal level, supporting documentation sent, and next-action date.
- Unposted 835 ERAs in the Tebra queue at cutover belong in Tebra. Post them there before cutover, not in Medi.
- Per-payer scrub rules, write-off tolerances, and automatic posting rules do not copy through any export, and Medi is not a place to rebuild a per-payer rule library. Medi runs one global pre-submission scrubber, and the payer-level rules you can author are prior-authorization and referral requirements, turned on during onboarding rather than by default. Inventory what the old rules caught, then decide what the global scrubber covers and what moves to coding review or follow-up.
- The BPR segment in incoming 835 files carries the check or EFT total. Confirm Medi's ERA review queue surfaces BPR check totals before going live with payment posting.
- CARC reason codes on denied lines and RARC remark codes on adjusted lines are standard X12 codes. The meaning is identical in Medi; the display and workflow routing may differ from Tebra.

## What absolutely must move

- Patient demographics, including all active insurance coverages and authorizations.
- Provider NPIs, taxonomy codes, and billing identifiers for every provider across every client practice.
- A documented inventory of active payer enrollment status and clearinghouse trading-partner relationships. Enrollment is not imported into Medi; it is re-established payer by payer through Stedi, and the inventory is what that re-enrollment runs from.
- User roles and practice-level access permissions, translated into Medi's permission model before cutover day.
- Custom fee schedules where they differ from Medicare allowables, from Tebra's fee schedule export into Medi.
- The last twelve months of paid claims and posted payments for reporting continuity, from the Charges Export and A/R Aging reports.

## Day-zero cutover checklist

Run [the Tebra day-zero checklist](/migration/tebra) for the core steps: read-only cutover, import verification, payer enrollment confirmation, first claim and ERA tests. Two items to add for a Kareo-era book specifically:

- Confirm 270/271 eligibility is live for the highest-volume payer before the first live appointment date.
- Set the Tebra legacy closeout reporting cadence: weekly A/R aging to the billing company starting the following Monday.

## Frequently asked questions

### Is Kareo the same as Tebra?

Yes. Kareo and PatientPop merged on November 2, 2021, to form Tebra, and the Kareo brand has since been folded fully into tebra.com. The products, clearinghouse relationships (Trizetto for medical claims, Jopari for workers' comp and auto), and help center are all under the Tebra name. Legacy Kareo contracts may still use Kareo language but they govern access to the Tebra platform. The [comparison of Medi and Tebra](/compare/medi-vs-tebra) has more on the product history.

### How long does a Kareo-to-Medi migration take?

Plan on about one business day per practice for the Medi cutover once exports and enrollment inputs are ready, as a planning target rather than a measured average. For a multi-client billing company, practices still move in waves. The separate clock starts from your written non-renewal notice to Tebra, which the current pricing policy sets at 60 days before the end of the term. Check your contract, because legacy Kareo agreements may differ.

### What does migration to Medi cost?

Migration is free with a 12-month commitment. Month-to-month, the fee is $100 per client practice migrated, capped at $3,000 regardless of practice count. Data export from Medi is always free in standard formats, and there is no termination fee. The only lock-in on the annual path is the commitment itself.

Medi itself starts at $1.00 per claim, with no monthly fee, no per-practice fee, and no per-provider fee, so cost tracks claim volume rather than how many practices or providers you bring; the full schedule is at [/pricing](/pricing). ERA posting is included in the claim price, and there is no contract.

### Do we have to re-enroll with every payer when leaving Kareo/Tebra?

In most cases, yes. Tebra routes claims through Trizetto Provider Solutions; Medi routes through Stedi. Changing clearinghouses means new trading-partner relationships for every payer without a direct EDI connection to your billing Tax ID independent of the clearinghouse. Claim submission enrollment takes one to eight weeks per payer; 835 ERA enrollment is separate at two to eight weeks. Anthem and Elevance plans route through Availity, which needs its own setup. Start enrollment the day the new contract is signed.

### Can we import open Kareo claims into Medi rather than working them in Tebra?

The default pattern is to leave open claims in Tebra under the legacy A/R closeout rather than make them active in Medi on day one. The working state of a denied or appealed claim (follow-up notes, CARC codes worked, appeal documents, biller comments) does not transfer cleanly through any bulk export. The history and the open balances do come across, though, as a read-only historical-reference ledger. Medi imports Kareo/Tebra claim ledgers when source evidence is strong: they land as Historical, hold their balance to the cent, sit visible beside live work, and stay out of active A/R, aging, statements, Money In, denial queues, and work queues until someone promotes one deliberately on a dated action. Nothing is stranded in the old system and nothing pollutes the new book, which is what ends the two-system tax of keeping Tebra open just to read a balance. When a biller does need Medi to work one, a guarded Make Operational action raises balance, aging, payer, provider, and setup warnings before the claim enters active operations.

### What about unposted ERAs sitting in Kareo/Tebra when we switch?

Post them in Tebra before cutover. An unposted 835 ERA in Tebra's queue at cutover belongs to Tebra's ledger, not Medi's. The BPR segment in each ERA carries the check or EFT total; reconcile those totals against the unposted queue during the pre-cutover audit so nothing is orphaned. If an ERA arrives in Tebra after cutover for a date of service now in Medi, the parallel-run reconciliation catches it and routes the posting decision to the right system.

### How current is this guide?

Last reviewed 2026-07-27. The Kareo-to-Tebra rebrand completed December 2024, and all help documentation now lives at helpme.tebra.com. Tebra's export capabilities, clearinghouse relationships, and contract terms change. Primary sources for current export documentation are the [Tebra Help Center Data Management section](https://helpme.tebra.com/Platform/Practice_Settings/Data_Management/Export_Patient_Clinical_Data) and the [Tebra practice information export guide](https://helpme.tebra.com/Tebra_PM/11_Run_Reports_and_Analytics/05_Provider_and_Practice_Reports/Reporting_Export_Practice_Information). EDI enrollment timelines come from the [Tebra Enrollments FAQ](https://helpme.tebra.com/01_Kareo_PM/04_Settings/EDI_Enrollment/Enrollments_FAQs) and the [CMS Electronic Billing and EDI Transactions guidance](https://www.cms.gov/medicare/coding-billing/electronic-billing). Transition-risk benchmarks come from the [Medical Billers and Coders transition playbook](https://www.medicalbillersandcoders.com/blog/switch-medical-billing-companies/). Verify current Tebra contract terms and export capabilities directly before making any migration decision.