Migrate From Bask Health to TEHR: A Practical Plan

What should you understand about the current Bask setup?

As of October 22, 2026, Bask’s plans page describes provider access and lab ordering, while its pharmacy page describes partner and bring-your-own-pharmacy workflows. Its payments page covers payment processing and tokenization. It would be inaccurate to approach the migration as only replacing a storefront.

Document which of those capabilities your brand actually uses. The configuration in your agreement may differ from a public plan description. Identify external services, custom integrations, account ownership and the people responsible for them. Ask Bask for the available outbound data and transition process in writing.

Before committing, review TEHR versus Bask Health and Bask Health alternatives. A migration should solve a defined operating problem. That may be commercial structure, workflow fit or a different support model; it should not depend on unsupported claims that the current platform lacks capabilities it publicly documents.

How should you define the migration scope?

Separate the project into brand experience, clinical information, commerce activity and continuing operations. Decide whether you are moving the entire storefront or retaining part of the current front end. Identify the destination for new customers, existing patient access and any historical records that will remain in an archive.

Create a baseline inventory with counts by record type and status. Active subscribers, paused subscriptions, canceled accounts and one-time purchasers may need different handling. Likewise, a completed order is different from a prescription awaiting fulfillment or a customer waiting for clinical review.

Use the patient migration checklist to prepare the inventory. Ask TEHR to turn it into a written scope with included data, exclusions, required source assistance and acceptance criteria. The count of patients alone is not enough to determine complexity or duration. The relationships between records and the unresolved work matter just as much.

Which identifiers and records should be mapped?

Keep an explicit crosswalk between source identifiers and TEHR identifiers. Do not rely on a person’s email address as the only record-matching rule. Emails can change, be shared or contain errors; the project needs a documented method for handling ambiguous matches without silently combining records.

Retain the meaning of statuses, not merely their labels. If one system uses “active” for an account and another uses it for a subscription, copying the word can create a false impression of what is currently authorized or billable.

How do you preserve subscriptions without double billing?

Build a renewal ledger before switching billing workflows. For each continuing subscription, identify the current status, next expected charge, amount, interval and any existing pause or cancellation. Reconcile that ledger with the source payment arrangement and the destination plan.

Payment tokens may have portability restrictions or require a provider-managed process. Do not assume that exporting a subscription record transfers authority or ability to charge the saved payment method. Confirm the actual merchant relationship, token handling and customer communication requirements with the relevant providers.

Choose a clear billing cutover boundary. The team should know which system owns each scheduled renewal and how to prevent duplicate charges during overlap. Test failed payments, retries and cancellations as well as a successful renewal. Use TEHR pricing and the cost guide to model transition costs separately from the long-term platform budget.

How should active care and open orders be handled?

Create a separate list of patients with ongoing clinical or fulfillment activity. That can include unresolved intake, upcoming reviews, pending lab work, active prescriptions or orders awaiting shipment. Each item needs an owner and a destination plan before the broader patient cohort moves.

The receiving clinical organization should decide what information and evaluation are needed to continue care. Importing a historical prescription or subscription does not itself authorize a new clinician to prescribe. The brand’s communication should distinguish account migration from any clinical steps a patient must complete.

Agree on how open pharmacy and laboratory work remains visible during transition. Some activity may finish through the existing arrangement while new activity begins in TEHR. That can be a sensible plan if responsibilities and patient instructions are clear. The platform evaluation should include these mixed-state scenarios, because they reveal whether the team can understand the next action during the handoff.

What privacy and retention decisions belong before transfer?

Confirm the source and destination roles, the permitted purpose for each dataset and the relevant agreements. HHS guidance on treatment, payment and operations disclosures explains that some disclosures can occur without individual authorization, subject to limits. It does not justify treating every customer list as clinical transfer data.

Classify any records requiring additional restrictions and preserve the necessary consent or disclosure information. Use an agreed secure transfer process with access limited to the people performing the work. Log what was received, transformed and accepted so that unresolved records can be investigated without guesswork.

Do not delete the source archive simply because an import succeeds. HHS notes that general medical-record retention is governed outside the HIPAA Privacy Rule, often through state requirements. The responsible parties need a documented retention and patient-access plan.

How should the pilot and cutover be tested?

Choose a pilot that represents the difficult parts of the real population, not only clean new accounts. Include different subscription states, historical attachments, open orders and program types. Use authorized data handling and agreed access controls throughout the test.

Validate relationships as well as totals. A matching patient count does not prove that the correct note, order or lab result is attached to the correct record. Compare a sample of source and destination journeys and reconcile exceptions. Document the reason for every record that is excluded or requires manual review.

Before cutover, test account access, renewal ownership, customer messages and support routing. Define the point at which the project can pause or revert without creating duplicate clinical or financial activity. The TEHR migration overview is the starting point for a scoped plan; the pilot results should determine whether the next cohort is ready to move.

What should patients be told?

Tell patients what is changing, what remains accessible and what action they need to take. Explain account access, relevant support contacts and any required steps for continuing care. Avoid a message that implies the customer’s clinical approval automatically transfers unchanged.

Coordinate timing with the actual cutover. Sending a new portal link before the account is usable can generate unnecessary confusion; waiting until after an expected renewal can be equally disruptive. Support staff should receive the same instructions and know how to identify a patient still using the prior workflow.

Keep commercial messages separate from clinical advice. If a patient asks whether a treatment can continue, route the question to the responsible clinical team. If the issue is a login or charge, route it to the appropriate support owner. A migration succeeds from the patient’s perspective when the next step is clear, not when the internal import job finishes.

How long should a Bask-to-TEHR migration take?

Set the schedule after reviewing export availability, record quality, payment arrangements, active care and the scope of storefront changes. The reviewed Bask pages do not establish a universal outbound migration format or deadline. That absence is a reason to ask for details, not evidence that migration is blocked.

A practical plan has discovery, mapping, pilot, reconciliation, staged cutover and stabilization milestones. Some work can overlap, but the project should not proceed past an unresolved clinical or billing risk merely to preserve an early estimate. Define a support period after cutover to resolve delayed events and customer questions.

TEHR’s operators migrated thousands of their own patients and apply that experience to scoped projects. Contact TEHR for a migration plan and quote. For broader procurement context, review white-label platform options. The right outcome is a working destination with reconciled records and clear responsibilities, not an unsupported promise of an instant switch.

What else should you know?