migration
Migrating from Kareo
How billing companies move accounts, claims, and payment workflows from Kareo (now Tebra) to Medi.
Short answer
Kareo is Tebra. The merger closed November 2, 2021; the Kareo website redirected to tebra.com on December 5, 2024. If you are still searching for "Kareo migration" you are either on a legacy Kareo-branded contract, working from documentation that predates the rebrand, or your institutional memory simply has not caught up with the name change. All three are common. The migration playbook is the same either way, because the product is the same product.
A Kareo/Tebra-to-Medi migration is a thirty to forty-five day operating-continuity project, not a data import. Tebra's documented exports are real: patient demographics, charges, unpaid insurance claims, A/R aging reports, and fee schedule data all come out in Excel or CSV format. Clinical history exports as XML Summary of Care files. What does not move cleanly is everything in flight — open-claim working notes, unposted 835 ERA files, in-progress appeal threads, and the EDI enrollment ties that keep claims routing to the right clearinghouse. 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. The pattern that protects revenue is a forward-only Medi cutover with a sixty to ninety day legacy A/R closeout running in parallel inside Tebra.
Kareo is Tebra now — does that change the migration?
Operationally, no. The product you were using 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' compensation and auto), and the same help center — which still answers to helpme.kareo.com URLs, now silently redirecting to helpme.tebra.com. Your EDI enrollments, payer connections, and data all live inside what is now the Tebra platform, regardless of which name appears on your contract.
That said, three things are worth checking if you are on a legacy Kareo contract rather than a current Tebra agreement.
First, the termination notice window. Tebra's pricing policy requires sixty days written notice before the end of the then-current Customer Agreement term. A legacy Kareo contract may have had different terms. Pull the actual contract and find the non-renewal clause before you commit to a cutover date, because a missed notice window locks you into another renewal period regardless of what the new platform is ready to do.
Second, the support path. Kareo customers who never formally transitioned to the Tebra product may be operating on a support tier that predates Tebra's current packaging. If your account manager is still someone you found through kareo.com before December 2024, it is worth confirming which contract terms govern your data export rights and your closeout window.
Third, the historical help documentation. A lot of the Google results for "Kareo enrollment" or "Kareo ERA posting" still resolve to Tebra's help center at helpme.tebra.com, because the old helpme.kareo.com URLs 301-redirect there. The underlying documentation is current Tebra documentation. References to "Kareo" in older PDFs and training materials may describe UI surfaces or menu paths that have since been reorganized under the Tebra brand. Trust the current helpme.tebra.com content over any PDF that still says "Kareo" in the header.
Beyond those three, the migration mechanics are identical to a current Tebra migration. See the full Tebra migration guide for the complete cutover playbook. This page focuses on the Kareo-specific framing and the disambiguation a billing company needs before the tactical work starts.
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. The timeline does not compress below three weeks without real revenue consequences — the Medical Billers and Coders 2026 playbook documents eight to twelve percent of trailing A/R at risk when practices rush the switch.
For a billing company on a legacy Kareo contract, the timing calculation starts from your written non-renewal notice, not from when you first contact Medi. If your Kareo contract renews annually and you are sixty days from renewal, you may have a year to run a well-paced migration or a hard deadline to hit the sixty-day notice window before the next term starts. Knowing which situation you are in is the first decision, and it is a contract-reading question, not a software question.
Two contract terms the outgoing Tebra/Kareo arrangement needs to include:
- 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 A/R aging reconciliation delivered to the billing company
- The billing company owns its trailing A/R outright and retains documented access to claim history during and after the transition period
The second clause is the one billing companies most often discover they negotiated away. 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 after termination.
What the Kareo/Tebra export actually captures
The Tebra Help Center's practice information export guide documents five recommended reports for account closure or data backup:
- Patient Demographic Export — complete patient information with balance details, available 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, available 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 describes bulk XML Summary of Care files, scoped by provider and date range, delivered as a ZIP. Patient documents are bundled with that export. 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 are imported into another system, chart entries default to a generic Admin Account rather than the original provider. For compliance audits that depend on attributing a clinical decision to a specific clinician, the working pattern is to keep read-only Tebra access for the historical chart record rather than relying on the imported copy.
Second, the export inventory above covers structured data. The working state of revenue cycle operations — open-claim follow-up notes, mid-investigation denial threads, in-flight appeal documents, unposted 835 ERAs sitting in the queue, the free-text notes a biller added on a claim before leaving Friday — does not come out cleanly through any per-practice system's bulk export. 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 is usually the constraint that determines cutover date, not data migration. Tebra's own enrollment FAQ confirms that claim submission enrollment "typically ranges between one to eight weeks" per payer, and 835 ERA enrollment takes longer — "typically between two to eight weeks" — because ERA enrollment is a separate process from 837 claim submission enrollment. Missing the ERA enrollment means cash gets posted from paper EOBs while you wait, which is a real operations cost during an otherwise clean cutover.
Tebra routes medical and institutional claims through Trizetto Provider Solutions and workers' compensation and auto claims through Jopari Solutions. When you move to Medi, which uses Stedi as its clearinghouse, every payer connection migrates to a new trading partner. The CMS Electronic Billing and EDI Transactions guidance documents the process for updating EDI submitter relationships, and the variance by payer is wide.
A few enrollment realities specific to the Kareo/Tebra population that bite during a switch:
- The Anthem and Elevance family of payers routes through Availity as their EDI gateway. If your Kareo deployment connected to 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 process by state; the Texas BCBS enrollment 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 processing timelines run weeks longer than commercial payers
- 835 ERA enrollment is separate from 837 claim submission enrollment in every payer's system; completing claim enrollment does not trigger ERA enrollment automatically
- 270/271 eligibility connections and 276/277 claim status connections are separate enrollments as well, not bundled with claim submission
Start enrollment work the day the contract is signed, not the day of cutover. For a billing company moving eight client practices, enrollment work across all practices at once is operationally overwhelming. The practice-by-practice rollout below is partly an enrollment-pacing decision.
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 835 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 catches 835 files that landed in Tebra after cutover for claims that should have been routed to Medi, and payer responses that came back to Medi for dates of service that belong in Tebra's legacy closeout. In a Kareo-era migration, there may also be historical ERAs that were never fully posted — check the Tebra unposted ERA queue before cutover and post any that can be resolved cleanly, so they are not orphaned when Medi goes live.
A practice-by-practice rollout protects everyone
Migrating eight client practices at once compresses every problem into a single weekend. The shape that recovers from issues:
- Choose the smallest client with the simplest payer mix and cleanest enrollment picture for cutover one
- Run that client end to end in Medi for two weeks before moving the next
- Apply what was learned — specific payer enrollment delays, posting rule gaps, user training gaps — to the next cutover
- 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, and for a billing company migrating off a legacy Kareo contract, the calendar time is frequently the cheaper option compared to a rushed full-book cutover that loses follow-up coverage on aged claims across every client simultaneously.
For billing companies operating under Medi's multi-practice workspace, the practice-by-practice rollout is also the right onboarding shape from Medi's side — each client practice is a scoped tenant inside the billing company workspace, and permissions, payer rules, and reporting are configured per practice.
What does not migrate, and what to do about it
- Author information 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 sitting in the Tebra queue at cutover should be posted in Tebra before the cutover, not moved to Medi
- Per-payer custom scrub rules, write-off tolerance thresholds, and automatic posting rules need to be re-implemented in Medi; they do not copy through any export
- The BPR segment in incoming 835 files carries check or EFT payment details — confirm Medi's ERA review queue is configured to surface 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 the same in Medi, but the display and workflow routing may differ from what your team is used to in 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
- Active payer enrollment status and the clearinghouse trading-partner relationships that are transferable
- 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, exported from Tebra's fee schedule export and re-entered in Medi
- The last twelve months of paid claims and posted payments for reporting continuity, sourced from the Charges Export and A/R Aging reports
Day-zero cutover checklist
The day cutover happens for a given practice:
- 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 and the data looks correct
- Confirm payer enrollment for that practice is active in Medi for at least the top three payers by claim volume
- Confirm the first 837 claim submission test in Medi passes scrub and reaches Stedi's clearinghouse acknowledgment
- Confirm the first 835 ERA can be received in Medi for at least one test payer
- Confirm 270/271 eligibility is live for the highest-volume payer before the first live appointment date
- Notify the practice and payer-facing staff that Tebra is read-only for new work as of today
- Set the Tebra legacy closeout reporting cadence — weekly A/R aging delivered 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. The Kareo website fully redirected to tebra.com on December 5, 2024, completing the brand transition. 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 has more on the product history.
How long does a Kareo-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. For a multi-client billing company, practices move in waves — a book of eight clients typically takes six to eight weeks. The clock starts from your written non-renewal notice to Tebra, which the current Tebra pricing policy sets at sixty days before the end of the term. Check your actual contract for the notice requirement, because legacy Kareo agreements may differ.
Do we have to re-enroll with every payer when leaving Kareo/Tebra?
Yes, in most cases. Tebra routes claims through Trizetto Provider Solutions; Medi routes through Stedi. Changing clearinghouses means new trading-partner relationships for every payer that did not have a direct EDI connection with your billing Tax ID independent of the clearinghouse. Claim submission enrollment takes one to eight weeks per payer; 835 ERA enrollment is separate and takes two to eight weeks. Anthem and Elevance plans route through Availity, which requires 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 pattern that works is leaving open claims in Tebra under the legacy A/R closeout arrangement rather than migrating them. The working state of a denied or appealed claim — follow-up notes, CARC codes worked, appeal documents attached, biller comments — does not transfer cleanly through any bulk export. Importing historical closed claims is also not recommended because it creates duplicate ledger entries that produce reconciliation errors for months. Run Medi forward-only and close out the legacy book in Tebra.
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 the time of 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 that is now in Medi, the parallel-run reconciliation process catches it and routes the posting decision to the right system.
How current is this guide?
Last reviewed 2026-05-18. The Kareo-to-Tebra rebrand completed December 2024; all help documentation now lives at helpme.tebra.com. Tebra's export capabilities, clearinghouse relationships, and contract terms change. The primary sources for current export documentation are the Tebra Help Center Data Management section and the Tebra practice information export guide. EDI enrollment timelines are drawn from the Tebra Enrollments FAQ and the CMS Electronic Billing and EDI Transactions guidance. Migration timeline benchmarks come from the Medical Billers and Coders 30-Day Transition Playbook. Verify current Tebra contract terms and export capabilities directly before making any migration decision.
References
These public sources provide background for standards, terminology, or competitor context discussed on this page.