10 Questions a Billing Company Should Ask Before a Tebra Migration

Short answer

For planning, we usually estimate around one business day per practice for a Tebra-to-Medi cutover once exports and payer-enrollment inputs are ready; the exact pace depends on export quality, payer mix, and readiness. Three questions decide whether a billing company is ready to move: what is your open A/R and how long does legacy collection need to run, is payer enrollment actually started (not just planned), and has the outgoing contract been read for its non-renewal notice clause. If you cannot confidently answer eight of the ten questions below, finish that prep before setting a cutover date.

Why these ten questions matter

The first migration question is usually the wrong one: "how long does the data export take?" The right one is "what happens to the revenue we are already working while the new system stands up?"

Tebra exports real data. Demographics, charge history, unpaid claims, A/R aging, and fee schedules all come out in recognizable formats; clinical history exports as XML Summary of Care files. What does not come out is everything in motion: open-claim working notes, in-flight 835 ERA files, unresolved denial threads, active appeal documents, and the EDI enrollment ties that decide whether an 837 claim reaches a payer from the new system.

The failures that hit mid-cutover are diligence failures, not software ones. Enrollment is not done. A custom rule lived only in Tebra and nobody wrote it down. The outgoing contract had a renewal clause no one read. All preventable. Work these ten questions before you set a cutover date, sign the new contract, or tell clients anything about timing.

1. Are you on Tebra, or are you on Kareo?

Why it matters: a legacy Kareo contract can carry different notice windows, support tiers, and data-access rights than a current Tebra agreement, and you are billed under whichever name signed.

Kareo and PatientPop merged on November 2, 2021 to form Tebra. The Kareo site fully redirected to tebra.com on December 5, 2024. If your team still says "Kareo," if your bookmarks point at helpme.kareo.com (now a 301 to helpme.tebra.com), or if your paperwork carries Kareo's name, you are on the Tebra platform under legacy terms.

Verify: pull the contract and read the governing entity named on it, check whether your account manager came from a Kareo-era onboarding, and confirm which help-center URLs your team uses daily. A legacy Kareo contract may require 30 days non-renewal notice rather than Tebra's published 60-day window. Plan a cutover on 60 days of lead time when your contract demands more and you are locked into another renewal period. The Kareo migration guide covers the disambiguation and what changes by contract.

2. What is your renewal date, and what is the notice period?

Why it matters: these two numbers gate every other timeline decision. You cannot name a cutover date until you know them.

Tebra's current pricing policy requires 60 days written notice before the end of the then-current Customer Agreement term. A legacy Kareo contract may read differently. A contract that auto-renews annually turns a missed window into another full year of payments before you can exit without penalty, ready or not.

Verify: find the non-renewal clause, count the days to the next renewal date, and check whether the notice window has already opened. Then count backward from the earliest practical cutover, using around one business day per practice as the Medi cutover estimate plus payer-enrollment lead time, and confirm the math works. Owners who skip this step routinely discover, after committing to a new vendor and a go-live date, that they will pay both platforms for a full renewal cycle. Check the contract on day one.

3. What is your open A/R, and how long must legacy collection run?

Why it matters: this is the load-bearing financial question, and the answer is what makes a fast cutover responsible or reckless.

Open A/R from the last 90 to 120 days of service is the revenue most at risk during cutover. Those claims are in flight: some await payer response, some are appealed, some are in a follow-up queue, some have a 277CA acknowledgment but no 835 ERA yet. None of that working state moves cleanly through any export, from any system. The forward-only parallel run, where Tebra keeps working legacy claims for 60 to 90 days after the Medi cutover, exists because this revenue needs continuity.

Verify: run an A/R aging report in Tebra, broken out by payer and date-of-service bucket. Watch the 30 to 90 day bucket; those claims are most likely to surface denials, ERA postings, or secondary needs during the window. Identify the payers with the highest dollar concentration there, because those are the ones that need a negotiated legacy closeout clause in the outgoing agreement. Terminate the Tebra relationship on cutover day without that clause and you lose the team behind those claims. The payer does not stop sending 835 files because you switched platforms; someone still has to post them. Plan the closeout as a parallel operation, not a handoff.

4. Which client practices move first?

Why it matters: the order you migrate in is your main lever for containing risk; the wrong first pick puts your highest stakes on your least-tested process.

The answer is never "all of them at once." Migrating eight practices on one cutover weekend compresses every unknown into a single event, and when something breaks it breaks for all eight with no stable reference to compare against. A staggered, practice-by-practice rollout gives you a controlled environment to find problems before they scale.

The ideal first candidate: one location, three to five providers, commercial payers only (no state Medicaid plan with a multi-week enrollment window), under 100 open claims, and a communicative practice administrator who tolerates a learning-curve week. The operational pattern your team learns there, where the enrollment gaps are, how posting rules configure, what staff training is missing, is what protects the larger clients that move later.

Verify: sort your client list by provider count, payer-mix complexity, and open-claim volume. The bottom of that list goes first; the top moves last, after several successful cutovers. Picking your largest, most complex client first because it is generating pressure runs the highest risk on the highest-stakes account.

5. What payer enrollment is running that has to follow?

Why it matters: enrollment is the long pole in the tent. It, not the data migration, almost always sets the cutover date.

The CMS Electronic Billing and EDI Transactions guidance documents how EDI submitter relationships get established, and the variance by payer is wide. Tebra routes medical and institutional claims through Trizetto Provider Solutions and workers' comp and auto claims through Jopari Solutions. Moving to a different clearinghouse means re-registering every payer connection under the new trading-partner relationship.

Enrollment realities specific to Tebra migrations:

• 837 claim submission and 835 ERA enrollment are separate processes with separate forms for most payers. Completing claim enrollment does not trigger ERA enrollment, and missing ERA means posting cash from paper EOBs during the gap.
• 270/271 eligibility and 276/277 claim-status connections are also separate, not bundled with claim submission. A practice that checks eligibility before every appointment needs 270/271 live before the first patient day.
• The Anthem and Elevance family routes through Availity as its EDI gateway. That connection re-establishes under the new clearinghouse relationship even if your current Tebra deployment already used Availity for Anthem.
• Medicare and state Medicaid plans have separate EDI agreements and timelines that routinely run longer than commercial payers.
• BCBS enrollment varies by state plan, and each state plan processes independently.

Verify: pull the payer list for every first-wave practice and identify the payers covering the top 80 percent of claim volume by dollar. Those need enrollment started, actually progressing with a contact at the payer or clearinghouse, before a cutover date is set. File applications the week of cutover and you will submit paper or hold electronic claims for two to eight weeks while you wait.

6. What custom rules and configurations live only in Tebra?

Why it matters: this surfaces the institutional knowledge nobody documented, and none of it appears in any export.

Years of billing work produce a layer of configuration nobody thinks of as configuration; it just feels like the way things work. Per-payer scrub rules that catch a specific denial before the claim leaves. Write-off tolerance thresholds that reflect negotiated take-backs for one payer. Posting rules that route ERA line items to a work queue by CARC code. Follow-up cadences set after a payer changed its response timelines. All of it has to be rebuilt in the new system from scratch, which means knowing it exists.

Verify: ask every biller, poster, and denial lead to describe the rules they rely on that "just work," and record a screen session where each walks through their daily Tebra workflow and narrates it. The "oh, for this payer we always do X first" moments are the rules to document before cutover. The Tebra migration guide lists the categories that do not export: per-payer scrub rules, write-off tolerances, automatic posting rules, and follow-up cadences. Miss one and you may face retroactive denial cleanup across a payer's full volume while standing up the new system.

7. Who owns chart-history access after cutover?

Why it matters: this has a regulatory dimension. Imported clinical records lose their author attribution, which can break a compliance audit.

Tebra's clinical export produces XML Summary of Care files that import into other systems, but author attribution does not carry forward. A chart entry authored by a specific provider in Tebra becomes a generic Admin Account on import. For an audit where a payer or regulator must trace a clinical decision to a named provider on a date under the relevant CMS documentation standard, the imported copy is not defensible as the authoritative record.

Verify: identify which client practices have active compliance-audit risk or pending payer investigations on pre-cutover dates of service. Those need read-only Tebra access written explicitly into the outgoing agreement, including how long it lasts and what it costs. For clients who use Tebra as their EHR, confirm how their clinical team will reach records for patient care after the billing relationship migrates. The working pattern is read-only Tebra for historical charts and the new system only for service dates after cutover. Negotiate that right before the contract is terminated, not after a payer audit lands.

8. What does the Tebra-side handoff team look like?

Why it matters: the exit runs on who you actually work with, not on what the contract says.

Tebra offers a data services team with a 30-day SLA on inbound data services agreements when it is the receiving system. The support path for exiting customers is a different conversation, and its shape varies by account size, tier, and account-manager relationship.

Verify: request a transition-planning call with your account manager specifically to cover the export path, the format and timeline of each deliverable, and the support window that stays open after notice. Get the name of the data services contact if one exists. Confirm what happens to portal access during the 60-day legacy closeout, specifically whether your team keeps full operating access to work open claims and post ERAs or gets restricted. Discover after giving notice that your account manager changed and the replacement is unfamiliar with the exit, and you are onboarding them on the details during your highest-load period.

9. What is your fallback if cutover surfaces a blocker mid-week?

Why it matters: a blocker is possible, and a clear revert plan is the difference between a delay and lost revenue.

Common mid-cutover blockers: an enrollment submitted but not cleared, so the first 837 batch comes back undeliverable; a payer that acknowledges via 277CA but was configured with the wrong submitter ID, breaking the loop; a posting rule set up wrong, so ERAs hold instead of auto-posting; an import that looked correct but carried a formatting error in one provider's NPI column, rejecting that provider's claims. None are catastrophic with a clear fallback. All disrupt real revenue without one.

A workable fallback shape:

• Keep Tebra fully operational for the practice until the first production week is complete and reconciliation confirms the numbers are clean.
• Name one person with authority to call a pause and revert the practice to Tebra submission if a blocker is confirmed.
• Set a decision deadline: if the blocker is not resolved within 48 hours, the revert happens automatically, no meeting.

Verify: name the revert owner before cutover day, document the conditions that trigger a revert, and confirm Tebra access stays live and production-capable through at least the first week so the revert is actually executable. Without a named owner, nobody feels empowered to make the call, and claims age while you schedule a meeting.

10. How will you measure whether the migration worked?

Why it matters: a migration that feels smooth is not the same as one that worked. The numbers tell you whether the revenue cycle held.

Three metrics answer it directly: days sales outstanding (DSO), first-pass denial rate, and collection rate by payer. A successful migration holds DSO flat or improves it within 60 days. A first-pass denial rate that spikes signals scrub rules were not fully rebuilt. A collection rate that drops for one payer signals an enrollment or posting-config problem for that payer.

Staff time is a real metric too, and it is usually ignored. If posting staff spend more hours per week after cutover, because hold queues are longer, because ERA lines that should auto-post need manual intervention, or because they are re-entering lost configuration, the migration has a cost the A/R numbers do not show yet.

Verify: pull baselines before cutover, DSO by practice, denial rate by payer, collection rate by payer, and hours per week by function, then run the same reports at 30 and 60 days. Without a baseline you cannot tell whether a rising DSO trend after go-live is a new problem the migration caused or a pre-existing trend it coincided with. The baseline is your defense.

The migration checklist most billing companies skip

A quick-pull reference. Each item maps to one of the ten questions.

• Read the actual contract and find the non-renewal clause (questions 1 and 2)
• Confirm which legal entity governs the agreement, Kareo or Tebra (question 1)
• Pull the A/R aging report and flag the 60 to 90 day bucket by payer (question 3)
• Negotiate a 60-day legacy closeout clause into the outgoing agreement before signing anything new (question 3)
• Sort client practices by payer-mix complexity and open-claim volume, and move the simplest first (question 4)
• Start payer enrollment the day the new contract is signed, not the day of cutover (question 5)
• File 837 and 835 enrollment separately; do not assume one triggers the other (question 5)
• Record a screen session with each biller to capture custom rules and configurations (question 6)
• Negotiate read-only Tebra access for chart history into the outgoing contract (question 7)
• Get the name and direct contact of the Tebra transition representative before giving notice (question 8)
• Define revert authority and revert conditions in writing before cutover day (question 9)
• Pull baseline DSO, denial rate, and collection rate by payer before cutover (question 10)

What the answers tell you about your timeline

Answer all ten with specific, documented responses, contract clause cited, A/R dollar amount named, enrollment applications submitted, custom rules documented, and a person named for each responsibility, and a roughly one-business-day-per-practice Medi cutover estimate is realistic. The full Tebra migration guide walks through the parallel-run plan and the day-zero checklist.

Answer seven or eight but stay vague on two or three ("we think enrollment is underway," "we haven't pulled the A/R report yet"), and you need more prep before the date is defensible.

Answer fewer than seven and you are not ready. That is not a criticism; it is the finding. The missing answers are real revenue risk, real operational risk, or both. Use the questions as a project checklist, close the gaps, and revisit the cutover date when the inputs are ready.

The billing-company software evaluation guide covers the broader vendor criteria that belong in diligence alongside these migration questions. One note on pressure: owners often want to force a cutover before enrollment, A/R ownership, and custom rules are ready because a client is unhappy, a competitor got mentioned, or the team is eager to be done with the old system. That pressure is real. A fast Medi cutover is good; a blind cutover that loses trailing A/R is not. Do the preparation work.

Frequently asked questions

How long does a Tebra migration actually take?

Use around one business day per client practice as the Medi cutover estimate once exports and payer-enrollment inputs are ready. For a multi-client billing company, run a staggered rollout: start with the simplest practice, then move the next practices one by one, with payer enrollment and legacy A/R closeout running in parallel.

Is a Kareo migration different from a Tebra migration?

Operationally no, because Kareo is Tebra. The merger closed November 2, 2021; the Kareo site redirected to tebra.com on December 5, 2024. The products, clearinghouse relationships, and export paths are the same. The difference is the contract: a legacy Kareo agreement may carry different non-renewal windows, data-access rights, or support terms. Read the contract whichever name is on it. See the Kareo migration guide.

Can we import open claims from Tebra instead of closing them out there?

The pattern that works is leaving open claims in Tebra under the legacy closeout and running Medi forward-only. The working state of a denied or appealed claim, follow-up notes, CARC codes already worked, in-flight appeal documents, biller comments, does not transfer through any bulk export. Importing open claims creates duplicate ledger exposure and reconciliation problems that compound for months. Leave them where the context lives, negotiate the 60-day closeout, and let the team work them to resolution.

What if payer enrollment takes longer than expected?

Extend the cutover date. A cutover without active enrollment for the top payers by volume means submitting 837 claims that will not route, ERA responses you cannot receive, and posting that cannot happen. Enrollment is not a detail to resolve after go-live; it is the prerequisite for it. The fallback for a delay is to keep running that specific payer through Tebra while the new enrollment clears, reconciling both systems until it is confirmed active. The 277CA acknowledgment is the confirmation that a claim reached the payer through the new clearinghouse; wait for it before declaring enrollment live.

What does a 60-day legacy A/R closeout clause actually say?

In plain terms: the outgoing party agrees to keep working all claims with dates of service before cutover for 60 days after cutover, with A/R aging reports delivered weekly, and with the billing company keeping full access to claim history in the source system throughout. The billing company owns the trailing A/R and has documented rights to the data regardless of the outgoing contract's status. Have a healthcare attorney review the actual language; enforcement varies by the terms of the agreement.

How do I tell whether the migration raised our denial rate or something else did?

Pull baselines before cutover. A denial rate measured at 30, 60, and 90 days post-cutover means something; "we think it was about this before" means nothing. Pull the first-pass denial rate by payer from Tebra for the 90 days before cutover, then run the same report at the same intervals in the new system. Flat or improving means the migration did not hurt you. A spike for one payer points first at that payer's scrub rules and enrollment configuration, which is usually the cause.

Where is the full migration playbook?

The Tebra migration guide has the parallel-run plan, the day-zero cutover checklist, and the full inventory of what exports cleanly and what does not. The billing-company operations guide covers how multi-practice workflow is organized in Medi after migration. Pricing is at Medi pricing. To walk through the plan before committing to a timeline, start at the demo page.