10 Questions a Billing Company Should Ask Before a Tebra Migration

Short answer

A Tebra migration is a thirty to forty-five day operating-continuity project, not a data import. The three questions that determine whether a billing company is actually ready to move are: what is the open A/R and how long does legacy collection need to run, is payer enrollment work started (not just planned), and has the outgoing contract been read for the non-renewal notice clause. The Medical Billers and Coders 30-Day Transition Playbook documents that practices rushing the switch under twenty-one days typically lose eight to twelve percent of trailing A/R. If you cannot confidently answer eight of the ten questions below, you need another thirty days of preparation before setting a cutover date.

Why these ten questions matter

Most Tebra migration conversations start with the wrong question. The wrong question is "how long does the data export take?" The right question is "what happens to the revenue we are already working while the new system stands up?"

Tebra exports real data. Patient demographics, charge history, unpaid insurance 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 cleanly 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 determine whether a 837 claim actually reaches a payer from the new system.

Billing companies that skip the diagnostic work before committing to a timeline often discover, mid-cutover, that enrollment is not done, that key custom rules only lived in Tebra and were never documented, or that the outgoing contract contains a renewal clause nobody read. These are not software problems. They are diligence problems, and they are preventable.

The ten questions below are the pre-migration diagnostic. Work through them before setting a cutover date, before signing the new contract, and before telling your clients anything about timing.

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

This question sounds obvious. It is not, and the wrong assumption creates real operational risk.

Kareo and PatientPop merged on November 2, 2021, to form Tebra. The Kareo website fully redirected to tebra.com on December 5, 2024. If your institutional memory still says "Kareo" — if your team calls it Kareo in daily conversation, if your bookmarks go to helpme.kareo.com (now a 301 redirect to helpme.tebra.com), if your contract paperwork has Kareo's name on it — you are almost certainly using the Tebra platform now, but under legacy contract terms that may have different notice windows, support tiers, and data-access clauses than current Tebra agreements.

The three things to verify before answering this question are: pull the actual contract and find the governing entity named on it, check whether your account manager's contact information originates from a Kareo-era onboarding, and confirm which help center URLs your team actually uses for daily tasks.

Where the wrong answer creates migration risk: a legacy Kareo contract may have had a thirty-day non-renewal notice requirement rather than Tebra's published sixty-day window. If you announce a cutover date based on sixty days of lead time and your contract requires more, you may be locked into another renewal period. The data access rights post-termination may also differ from what Tebra's current documentation describes. Read the contract. Do not assume the current Tebra pricing policy applies to a 2019 Kareo agreement.

The Kareo migration guide covers the brand disambiguation in detail and explains what changes — and what does not — depending on which contract you are actually governed by.

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

The renewal date and the notice window are the two numbers that set every other timeline decision. You cannot name a cutover date until you know them.

Tebra's current pricing policy requires sixty days written notice before the end of the then-current Customer Agreement term. A legacy Kareo contract may have different language. A contract that auto-renews annually means a missed sixty-day window locks you into another full year before you can exit without penalty, regardless of whether the new platform is ready to go live.

What to verify: pull the contract, find the non-renewal clause, count the days from today to the next renewal date, and determine whether the sixty-day (or whatever the actual number is) window has already opened. Then count backward from the earliest practical cutover date — accounting for thirty to forty-five days of migration work plus any enrollment lead time — to check whether the math works.

Where the wrong answer creates migration risk: billing companies who start the migration conversation without reading this clause frequently discover, after committing to a new vendor and a go-live date, that they will be paying both platforms simultaneously for a full renewal cycle. That cost changes the economics of the switch entirely. Check the contract on day one.

3. What is your open A/R, and how long do you need legacy collection to run?

This is the load-bearing financial question. The answer determines whether a thirty-day migration is responsible or reckless.

Open A/R from dates of service in the last ninety to one hundred twenty days is the revenue that is most at risk during a cutover. Those claims are still in flight — some are waiting for payer response, some are appealed, some are in a follow-up queue, some have received a 277CA acknowledgment but not yet an 835 ERA. None of that working state moves cleanly through any export, from any system. The forward-only parallel-run model — where Tebra continues to work legacy claims for sixty to ninety days after the Medi cutover — exists precisely because this revenue needs continuity.

What to verify: run an A/R aging report in Tebra, broken out by payer and date-of-service bucket. Pay close attention to claims in the thirty to ninety day bucket — those are most likely to surface denial responses, ERA postings, or secondary claim needs during the cutover window. Identify which payers have the highest dollar concentration in that bucket, because those payers need to be in the legacy closeout arrangement.

Where the wrong answer creates migration risk: a billing company that terminates the Tebra relationship on cutover day, without a negotiated sixty-day legacy A/R closeout clause in the outgoing agreement, loses the operational team behind those claims. The payer does not stop sending 835 files because you switched platforms. Someone has to post them. Without the clause, that someone is not Tebra, and it may not be the new system either, if the enrollment is not complete.

The Medical Billers and Coders 30-Day Transition Playbook documents eight to twelve percent of trailing A/R at risk in transitions compressed under twenty-one days. The way to avoid that loss is to plan the closeout as a parallel operation, not as a handoff.

4. Which of your client practices are easiest to move first?

The answer is never "all of them at once." The answer is always a specific practice name, and the practice named should be the one with the smallest payer mix, the cleanest enrollment picture, and the fewest open claims at any given time.

Migrating eight client practices simultaneously compresses every unknown into a single cutover weekend. When something goes wrong — and something always does — the problem affects all eight clients at once, with no stable reference point to compare against. A staggered practice-by-practice rollout gives you a controlled environment to find the problems before they scale.

The ideal practice-one candidate looks like this: one location, three to five providers, commercial payers only (no state Medicaid plan with a multi-week enrollment window), under one hundred open claims, and a practice administrator who is communicative and tolerant of a learning-curve week. That practice goes first. The operational pattern the team learns on that practice — where the payer enrollment gaps are, how posting rules need to be configured, what the staff training gaps look like — is what protects the larger, more complex clients that move later.

What to verify: sort your client list by provider count, payer mix complexity, and open-claim volume. The bottom of that list is practice one. The top of that list moves last, after the team has run several successful cutovers.

Where the wrong answer creates migration risk: a billing company that chooses their largest and most complex client first, because that client is generating pressure to move, runs the highest possible risk on the highest-possible-stakes account. Save the complex clients for when the migration pattern is stable.

5. What payer enrollment work do you have running that needs to follow?

Payer enrollment is the long pole in the tent. It is almost always the constraint that sets the cutover date, not the data migration.

The CMS Electronic Billing and EDI Transactions guidance documents the process for establishing EDI submitter relationships, and the variance by payer is wide. Tebra routes medical and institutional claims through Trizetto Provider Solutions and workers' compensation and auto claims through Jopari Solutions. Moving to a different clearinghouse means every payer connection needs to be re-registered under the new trading-partner relationship.

A few specific enrollment realities that come up in Tebra migrations:

• 837 claim submission enrollment and 835 ERA enrollment are separate processes with separate enrollment forms for most payers. Completing claim submission enrollment does not trigger ERA enrollment. Missing the ERA enrollment means cash gets posted from paper EOBs during the gap.
• 270/271 eligibility connections and 276/277 claim status connections are also separate enrollments, not bundled with claim submission. A practice that runs eligibility checks before every appointment needs the 270/271 connection live before the first patient day.
• The Anthem and Elevance family of payers routes through Availity as their EDI gateway. This connection needs to be established under the new clearinghouse relationship even if your existing Tebra deployment already used Availity for Anthem claims.
• 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.

What to verify: pull the payer list for every client practice that will migrate in the first wave. Identify which payers account for the top eighty percent of claim volume by dollar. Those payers need to have enrollment work started — not just initiated, actually progressing with a contact at the payer or clearinghouse — before a cutover date is set.

Where the wrong answer creates migration risk: a billing company that files enrollment applications the week of cutover will be submitting paper claims or holding electronic claims for two to eight weeks while waiting. That is real revenue with real aging implications.

6. What custom rules, payer setups, and workflow configurations live only in Tebra?

This is the question that surfaces the institutional knowledge nobody documented.

Years of billing work often produce a layer of custom configuration inside a platform that nobody thinks of as configuration — it just feels like "the way things work." Per-payer scrub rules that catch a specific denial reason before the claim leaves. Write-off tolerance thresholds that reflect negotiated take-back amounts for a specific payer. Automatic posting rules that route ERA line items to a specific work queue based on CARC code. Follow-up cadences that were set up after a payer changed their response timelines. None of this is in any export. All of it has to be re-implemented in the new system from scratch, which requires knowing it exists.

What to verify: ask every biller, poster, and denial lead on your team to describe the rules they rely on that "just work." Schedule a screen-recording session where each person walks through their daily workflow in Tebra and narrates what they are doing. The rules that surface in that narration — "oh, for this payer we always do X first" — are the rules that need to be documented before cutover.

The Tebra migration guide lists the specific categories that do not move through any export: per-payer custom scrub rules, write-off tolerance thresholds, automatic posting rules, and follow-up cadences. The documentation work happens before the cutover date is set.

Where the wrong answer creates migration risk: a billing company that discovers mid-cutover that a specific payer was producing high denial rates — and that the reason they were not denying previously was a Tebra scrub rule nobody documented — is now looking at denial cleanup across the full claims volume for that payer, retroactively, while also standing up the new system. That is an avoidable situation.

7. Who is responsible for chart-history access after cutover?

This question has a regulatory dimension that billing companies sometimes overlook.

Tebra's clinical export produces XML Summary of Care files. The files import into other systems. But the author attribution does not carry forward. When a chart entry that was authored by a specific provider in Tebra imports into another system, the authoring clinician becomes a generic Admin Account. For compliance audits where a payer or regulator needs to trace a clinical decision to a specific provider — by name, by date, by the relevant CMS documentation standard — the imported copy is not defensible as the authoritative record.

The working pattern for handling this is to maintain read-only access to Tebra for the historical chart record, and use the new system only for clinical context tied to dates of service after cutover. That pattern requires a specific negotiated right in the outgoing contract: what does read-only access look like, how long does it last, and what does it cost.

What to verify: identify which client practices have active compliance audit risk or pending payer investigations on dates of service before the cutover date. Those practices need read-only Tebra access explicitly written into the outgoing agreement. For billing companies whose clients use Tebra as their EHR, also confirm how the practice's clinical team will access records for patient care after the billing relationship migrates.

Where the wrong answer creates migration risk: a billing company that terminates Tebra access on cutover day and then receives a payer audit request covering dates of service from three months prior is in a difficult position. The export is there, but the attribution is not. Read-only access to the source system is the simplest resolution and it needs to be negotiated before, not after, the outgoing contract is terminated.

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

This question is about who you are actually working with, not what the contract says.

Tebra offers a data services team with a thirty-day SLA on inbound data services agreements when acting as a receiving system. The support path for exiting customers is a different conversation, and the shape of that support varies by account size, tier, and account manager relationship. Before committing to a cutover timeline, you should know the name of the person at Tebra who owns your account for purposes of the exit, what their availability looks like during the transition period, and what escalation path exists if the data export encounters a problem.

What to verify: request a transition planning call with your Tebra account manager specifically to discuss the export path, the format of each deliverable, the timeline for delivery, and the support window that will remain open after notice is given. Get the name of the data services contact if there is one. Confirm what happens to the account portal access during the sixty-day legacy closeout period — specifically whether your billing team retains full operating access to work open claims and post ERAs, or whether access is restricted.

Where the wrong answer creates migration risk: a billing company that discovers, after giving notice, that the Tebra account manager has changed and the new manager is unfamiliar with the transition requirements is now managing a handoff with someone who needs to be onboarded on the details. That friction compounds during a period when the team already has higher operational load.

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

This is the question most billing companies do not want to answer, because answering it requires admitting that a blocker is possible.

Common mid-cutover blockers: an enrollment that was submitted but has not cleared the payer's processing queue, so the first batch of 837 claims comes back undeliverable. A payer that acknowledges claims through a 277CA but was configured with the wrong submitter ID in the new system, so the loop is broken. A posting rule in the new system that was set up incorrectly during configuration, causing ERAs to hold rather than auto-post. A data import that looked correct but contained a formatting error in the NPI column for a specific provider, causing claim rejections for that provider's encounters.

None of these are catastrophic if the fallback plan is clear. All of them cause real revenue disruption if there is no plan.

A workable fallback shape for a Tebra migration:

• Keep Tebra fully operational for the practice until the first week of production in the new system is complete and reconciliation confirms the numbers are clean
• Designate one person on the team who has the 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 forty-eight hours, the revert happens automatically, without a meeting

What to verify: name the person with revert authority before the cutover day. Document the specific conditions that trigger a revert. Confirm that Tebra access is still live and production-capable for the practice through at least the first week, so the revert is actually executable.

Where the wrong answer creates migration risk: a billing company that does not define revert authority in advance discovers, mid-crisis, that nobody feels empowered to make the call without a meeting. Claims age during the meeting.

10. How will you measure whether the migration actually worked?

A migration that feels smooth is not the same as a migration that worked. The measurement tells you whether the revenue cycle held.

The three metrics that answer the question directly are days sales outstanding (DSO), first-pass denial rate, and collection rate by payer. A successful migration holds DSO flat or improves it within sixty days. A first-pass denial rate that spikes after cutover is a signal that scrub rules were not fully rebuilt in the new system. A collection rate that drops for a specific payer is a signal that something in the enrollment or posting configuration is wrong for that payer.

Staff time is also a real measurement, and it is often ignored. If your posting staff is spending more hours per week after the cutover than before — because hold queues are longer, because manual intervention is required for ERA lines that should auto-post, because they are re-entering configuration that was lost in the transition — the migration has a cost that does not appear in the A/R numbers yet.

What to verify: pull baseline numbers before the cutover date. DSO by practice, denial rate by payer, collection rate by payer, and hours-per-week by function. Run the same report thirty days and sixty days post-cutover. The delta tells you whether the migration worked.

Where the wrong answer creates migration risk: a billing company that does not collect baseline numbers before cutover cannot tell whether a rising DSO trend that starts the week after go-live is a new problem caused by the migration or a pre-existing trend that the migration coincided with. The baseline is your defense.

The migration checklist most billing companies skip

This is a quick-pull reference. Each item maps to one of the ten questions above.

• 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 identify the sixty to ninety day bucket by payer (question 3)
• Negotiate a sixty-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 — move the simplest first (question 4)
• Start payer enrollment work 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)
• Run a screen-recording session with each biller to document custom rules and workflow 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 the cutover date (question 10)

What the answers tell you about your actual migration timeline

If you can answer all ten questions with specific, documented responses — contract clause cited, A/R dollar amount named, enrollment applications submitted, custom rules documented, person named for each responsibility — then a thirty to forty-five day cutover timeline is realistic. The full Tebra migration guide walks through the parallel-run plan and the day-zero checklist for executing that timeline.

If you can answer seven or eight of the questions but are vague on two or three — "we think enrollment is underway," "we haven't pulled the A/R report yet," "someone is documenting the custom rules" — you need two to four more weeks of preparation work before the cutover date is defensible.

If you can answer fewer than seven, you are not ready. That is not a criticism; it is the finding. The missing answers represent real revenue risk, real operational risk, or both. The right call is to use the questions as a project checklist, close the gaps, and revisit the timeline in thirty days.

The billing-company software evaluation guide covers the broader vendor evaluation criteria that belong in the diligence process alongside these migration-specific questions.

A note on timing pressure: billing companies sometimes feel pressure to compress the migration timeline because a client is unhappy, because a competitor is mentioned, or because the team is eager to be done with the old system. That pressure is real. But a migration that loses eight to twelve percent of trailing A/R to recover two weeks of calendar time is not a good trade. Do the preparation work.

Frequently asked questions

How long does a Tebra migration actually 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, the right shape is a staggered practice-by-practice rollout: the first practice moves at the thirty to forty-five day mark, subsequent practices move in two-week waves after that. A book of eight clients typically moves over six to eight weeks using this shape.

Is a Kareo migration different from a Tebra migration?

Operationally no, because Kareo is Tebra. The merger closed November 2, 2021; the Kareo website redirected to tebra.com on December 5, 2024. The products, clearinghouse relationships, and data export paths are the same. The difference is in the contract. A legacy Kareo agreement may have different non-renewal notice windows, different data access rights, or different support tier terms than a current Tebra agreement. Read the contract regardless of which name is on it. See the Kareo migration guide for the full disambiguation.

Can we import open claims from Tebra rather than leaving them to close out in Tebra?

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

What if our 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, which means ERA responses that cannot be received, which means payment posting that cannot happen. The enrollment is not a detail that can be resolved after go-live; it is the prerequisite for go-live. The fallback for an enrollment delay is to continue running claims through Tebra for that payer specifically while the new enrollment clears, reconciling both systems until enrollment is confirmed active. The 277CA acknowledgment from the payer is the confirmation that a claim reached the payer's system through the new clearinghouse — wait for that before declaring enrollment live.

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

In plain terms, it says: the outgoing party agrees to continue working all claims with dates of service prior to the cutover date for a period of sixty days following cutover, with A/R aging reports delivered to the billing company on a weekly basis, and with the billing company retaining full access to claim history in the source system throughout that period. The billing company owns the trailing A/R and has documented rights to the data regardless of the status of the outgoing contract. Have a healthcare attorney review the actual language before signing. The specific enforcement path varies by the terms of the outgoing agreement.

How do I know whether our denial rate went up because of the migration or because of something else?

You pull baseline numbers before cutover. A denial rate measured at thirty, sixty, and ninety days post-cutover means something. A denial rate that starts from "we think it was about this before" means nothing. Specifically, pull the first-pass denial rate by payer from Tebra for the ninety days preceding cutover. Run the same report in the new system at the same intervals. If the rate is flat or improving, the migration did not hurt you. If a specific payer shows a spike, start with the scrub rules and enrollment configuration for that payer. That 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 for the new platform is at medi.com/pricing. If you want to walk through the migration plan with someone before committing to a timeline, the demo page is the right starting point.