A Telegra-to-TEHR migration should map patient, clinical and commerce records together while giving each its own validation and continuity plan. TEHR publishes this guide for brands evaluating its platform; Telegra’s public import documentation is useful context, but it does not establish the outbound export rights or formats for your account.
TEHR can start migration work as soon as your data is available. The complete cutover is coordinated around validation and continuity of care. The under-24-hour launch capability for new brands is separate from a patient migration timeline.
What does Telegra’s public documentation establish?
As of October 22, 2026, Telegra describes an integrated telehealth platform with patient-facing and operating workflows. Its CSV migration documentation covers importing patients, products, coupons, orders and subscriptions, with validation and dependency handling.
That documentation shows that Telegra has migration-import tooling. It does not prove which outbound files your account can obtain, that clinical records are included in a particular export or that saved payment credentials can move. Ask for the current source process and contractual terms in writing.
Use TEHR versus Telegra and Telegra alternatives to evaluate the destination before beginning transfer work. The move should have a defined purpose, such as a preferred operating model or commercial scope. Avoid treating public import features as either an obstacle to leaving or a guarantee that every field can be moved unchanged.
How should the source inventory be organized?
Create an inventory that distinguishes identity, clinical records, catalog, transactions and continuing obligations. Record counts by status and note which exports contain references to other files. A product identifier in an order is useful only if the destination can interpret the product correctly.
Separate active and historical activity. A canceled subscription may need to remain in the record without being recreated as billable. An old coupon may be relevant to explaining a customer’s price even if it should not be available for new purchases. A completed encounter may be clinically useful without representing an open task.
The migration checklist helps identify these distinctions. Ask TEHR to specify what will be imported, transformed, archived or excluded. Each choice should have a reason and a responsible reviewer. A broad promise to “move everything” is less useful than a field-level plan that explains how the destination will use the data.
How should dependencies be mapped?
Build the mapping in the order needed to preserve relationships. Identify the stable source identifiers and retain them in the migration crosswalk. Resolve duplicate or ambiguous identity matches before attaching clinical or financial records. Do not use the existence of a row as proof that it has been linked correctly.
| Data dependency | What to validate |
|---|---|
| Patient to account | Correct identity, contact details and access state. |
| Product to order | Accurate commercial description and destination mapping. |
| Offer to subscription | Price, interval, discount and renewal obligations. |
| Encounter to patient | Correct clinical history, attachments and dates. |
| Order to fulfillment | Open activity remains assigned to the responsible workflow. |
Treat the catalog as a commercial mapping, not a clinical authorization. A product name or SKU cannot by itself establish that a patient is eligible, that a prescription should continue or that a destination program is currently available.
What needs special attention in products, discounts and subscriptions?
Historical commercial terms can be easy to lose during a platform change. Record the actual price and billing interval a customer agreed to, along with any relevant discount, pause or cancellation. Decide how legacy offers will be represented and whether they remain available only to existing customers.
Reconcile subscriptions against payment and order records. A subscription labeled active may still have a failed payment or pending cancellation. The destination needs enough context to avoid recreating an obligation incorrectly. Any intended change to customer terms requires its own review and communication rather than being hidden inside a technical migration.
Confirm which system controls each upcoming renewal during overlap. Payment-token transfer is a separate provider-dependent process; do not infer portability from a subscription CSV. Review TEHR pricing and the cost guide to distinguish transition expenses from the future platform model. TEHR uses flat platform and transaction fees with 0% revenue share; contact TEHR for a scoped quote.
How should clinical records and pending care move?
Identify the clinical records available from the source and how they relate to the patient’s current care. Include relevant notes, attachments, consents, laboratory results and pending actions within the lawful and agreed scope. A commerce export should not be treated as a replacement for clinical history.
The receiving clinical organization should define what it needs to evaluate ongoing patients and how unresolved issues will be handled. A historical treatment name or recurring charge does not authorize new prescribing. Patients may need additional review or other steps before continuing a program.
Assign responsibility for open laboratory, pharmacy and clinical activity that began before cutover. Some items may finish through the source arrangement while future activity enters TEHR. The platform demonstration should show how staff can understand that distinction. A mixed transition is manageable when ownership and patient instructions are explicit; it becomes confusing when every imported record is simply marked active.
Which privacy and retention requirements should be addressed?
Confirm the purpose, authority and recipient for each transfer. The agreements should reflect the real entities handling the information, not just the names of the software systems. HHS business-associate guidance provides relevant context for covered relationships and their safeguards.
Classify specially protected records and preserve applicable restrictions. Limit migration access, use approved transfer channels and keep a manifest of what was received. Transformations should be documented so that the destination record can be traced to the source rather than becoming an unexplained rewrite.
Maintain an archival and patient-access plan. HHS explains that the HIPAA Privacy Rule does not set a general medical-record retention period. Applicable requirements and legal holds need separate review. Successful import does not itself justify deleting historical source records or ending access needed for continuing obligations.
How should a dry run be evaluated?
Use a representative sample that contains the record relationships and exceptions expected in production. Include historical orders, different subscription states, discounts, clinical attachments and active care tasks. Agree on what a successful result means before running the sample.
Validate at several levels. Check file completeness, field transformations, identifier relationships and the behavior of the destination workflow. A correct row count can coexist with wrong links or lost status meaning. Inspect representative patient journeys and commercial histories rather than relying only on a summary report.
Record every exception with an owner and disposition. Some issues require source correction; others may need a destination rule or manual review. Do not automatically reject or merge records without an agreed process. The TEHR migration overview should lead to a project-specific validation plan, including the conditions under which the pilot is repeated or the next cohort proceeds.
What should a cutover and rollback plan contain?
Set the boundary for new registrations, live updates and renewals. Identify when the source stops accepting particular changes and how updates made near the boundary are captured. A final export may be needed for activity that occurred after the first migration snapshot; scope that process with the source and destination teams.
Define rollback carefully. Restoring a website link is not the same as reversing a clinical action, a shipped order or a completed payment. The plan should identify which actions can be undone, which must be reconciled and who decides whether to pause a cohort.
Prepare support and patient communications before changing traffic. Explain login instructions, support contacts and any required steps. Test those instructions against real account states. The launch planning framework offers useful release gates, but a migration must add data reconciliation and continuity checks to the ordinary website-readiness review.
How should timing and post-migration support be agreed?
Do not substitute Telegra’s published onboarding estimate for an outbound migration deadline. Its pricing page describes onboarding terms, which are different from the timing of your export, clinical handoff and TEHR destination project. Establish the schedule from actual dependencies.
Use milestones for discovery, mapping, pilot, remediation, staged cutover and stabilization. Include the source vendor, payment provider and clinical organizations where their work affects timing. Make any required service overlap and associated cost visible in the plan.
After cutover, reconcile delayed events, upcoming renewals and customer questions. TEHR’s operators migrated thousands of their own patients, but each new project still needs scoped acceptance criteria. Contact TEHR for a written migration plan and quote. Review turnkey platform options if the destination decision remains open. A finished migration is an operating service with accountable people, not merely a completed file upload.
What else should you know?
Does Telegra’s CSV import tool prove that all our data can be exported?
No. Import documentation describes what can enter that system through the documented process. Outbound data availability, formats, fees and timing must be confirmed for your account. Clinical records and payment credentials may follow separate processes from commerce exports.
Can coupons and legacy prices be preserved?
They should be inventoried and mapped explicitly. A historical discount may explain an existing customer’s terms without needing to become a new public offer. Validate the resulting subscription amount, interval and status before allowing the destination to schedule a charge.
Should canceled subscriptions be imported as active?
No. Preserve the actual meaning of the source state and the customer’s instructions. The migration should not recreate billing authority or reverse a cancellation through a default mapping. Resolve ambiguous cases before cutover and record the decision.
Can patient records be matched only by email?
Email alone may be insufficient because addresses can change, be shared or contain errors. Use a documented matching approach with stable identifiers where available and a review process for ambiguous cases. Never silently merge clinical records based on an uncertain match.
Does a migrated product authorize continued prescribing?
No. Catalog and subscription data describe commercial history. Independent licensed providers determine the appropriate evaluation and treatment for the patient. Clinical continuity must be planned separately from recreating an offer or recurring billing schedule.
What should TEHR receive before estimating the project?
An aggregate inventory, current system diagram, available export descriptions, active program list and summary of subscriptions and open obligations. Agree on secure discovery before sharing patient-level information. Those inputs support a more useful estimate than a patient count alone.
Which sources support this guide?
Public sources reviewed as of 2026-10-22. Vendor statements describe the vendor’s published offering; your contract determines actual scope.
Build around your operation.
Discuss your categories, patient experience and costs with TEHR.