CRM migration

Migrate from tab32 to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between tab32 and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

tab32 logo

tab32

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

83%

10 of 12

objects map 1:1 between tab32 and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Dental groups move from tab32 to Salesforce Sales Cloud when multi-location complexity outgrows tab32's analytics model — teams need cross-practice dashboards, provider performance reporting, and insurance reconciliation that tab32's native reporting cannot deliver at DSO scale. The migration carries everything tab32 stores natively: patient demographics, provider records, appointment history, treatment plans, claims, and billing activity into Salesforce's Account, Contact, Lead, and custom object model. The harder problems are mapping tab32's clinical-to-billing relationship (where treatment plans and claims are linked to patients) into Salesforce's Opportunity and Task structures, preserving the provider-to-appointment assignment in Salesforce's User and Event model, and handling insurance carrier data that has no direct Salesforce equivalent without a custom carrier object. FlitStack sequences the migration so parent Account records (insurance carriers and employers) load before patient Contacts, appointments map to Events with original start/end times and provider-linked owners, and treatment history migrates as custom dental record objects with procedure codes. We run a sample migration with field-level diff before the full cutover and capture any in-flight changes during the delta window.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

tab32 logo

tab32

What's pushing teams away

  • Support response times of 24–48 hours frustrate practices during critical operations — one reviewer described waiting days for answers to simple questions during an onboarding window.
  • Training relies heavily on pre-recorded video content rather than live, scheduled onboarding sessions, creating access problems for practices operating outside standard business hours.
  • The platform is not user-friendly by default and requires a significant time investment even for tech-savvy teams, with one reviewer recommending competitors for better onboarding UX.
  • Add-on costs and tier-based feature gating reported by multiple sources push the realistic monthly cost above the advertised starting price, creating sticker shock for budget-conscious practices.
  • Feature discoverability is poor — staff report difficulty finding and configuring features even after initial training, suggesting the UI does not surface functionality in an intuitive way.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How tab32 objects map to Salesforce Sales Cloud

Each row shows how a tab32 object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

tab32

Patient

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

tab32 patient demographics (name, DOB, address, phone, email) map directly to Salesforce Contact. The patient's primary provider assignment resolves to Contact.OwnerId by provider email match. Multi-location patients use Account Contact Relationships when the patient has records at more than one practice.

tab32

Patient (lead-source records)

maps to

Salesforce Sales Cloud

Lead

1:many
Fully supported

tab32 patients marked as lead-source prospects who have not yet had an appointment route to Salesforce Lead with LeadSource populated from tab32's referral source field. Active patients with treatment history route to Contact; inactive leads with no treatment stay in Lead.

tab32

Provider

maps to

Salesforce Sales Cloud

User + Contact

1:1
Fully supported

tab32 providers with active user logins map to Salesforce User records, preserving NPI, DEA number, specialty, and credential fields as custom fields. Providers who are also referring doctors map additionally as Contact records with a Provider_Type__c custom pick-list. These custom fields include License_Number__c, Specialty__c, and Credential_Expiry__c to capture complete professional history within Salesforce.

tab32

Practice/Location

maps to

Salesforce Sales Cloud

Account (Location)

1:1
Fully supported

Each tab32 practice location becomes a Salesforce Account record with Type='Practice Location'. Billing address, phone, and taxonomy code map to Account fields. Multi-location DSO parent company becomes the Salesforce Account hierarchy root using ParentId. If the DSO uses Salesforce Territories, each location can also be assigned a Territory__c field to streamline reporting and quota allocation.

tab32

Appointment

maps to

Salesforce Sales Cloud

Event + Task

1:1
Fully supported

tab32 appointments with a start time and duration map to Salesforce Event with Subject, StartDateTime, EndDateTime, and WhoId (patient Contact). No-duration tasks (recalls, follow-ups) map to Salesforce Task. Provider assignment becomes Event.OwnerId resolved by provider email. When a provider does not have a Salesforce User, the appointment defaults to a DSO admin User and is flagged for later ownership correction.

tab32

Treatment Plan

maps to

Salesforce Sales Cloud

Custom Object: Treatment_Plan__c

1:1
Fully supported

tab32 treatment plans with procedure codes (CDT codes), tooth numbers, surfaces, fees, and provider notes migrate to a custom Treatment_Plan__c object with a lookup to the patient Contact and a related list on the Account. Procedure codes stored as Treatment_Code__c (text) with Description__c for the human-readable label.

tab32

Claim

maps to

Salesforce Sales Cloud

Opportunity + Task

1:1
Fully supported

tab32 insurance claims map to Salesforce Opportunity (for the billed amount) with Claim_Status__c, Payer_Account__c (lookup to insurance carrier Account), Subscriber_ID__c, and Group_Number__c as custom fields. Claim workflow stages (submitted, pending, paid, denied) map to Opportunity Stage values via value mapping.

tab32

Insurance Carrier

maps to

Salesforce Sales Cloud

Account (Carrier)

1:1
Fully supported

tab32 insurance carriers and employer benefit plans become Salesforce Account records with Type='Insurance Carrier'. Carrier address, payer ID, and electronic submission settings map to custom fields. Patient coverage details (subscriber ID, group number, effective dates) live in a custom Dental_Coverage__c junction object between Contact and the carrier Account.

tab32

Payment

maps to

Salesforce Sales Cloud

Task + Opportunity (for outstanding)

1:1
Fully supported

tab32 patient payments map to Salesforce Task with Type='Payment' recording amount, payment date, and payment method. Outstanding balances with a defined collection path become Opportunities with Stage reflecting collection status. Full payments close the related treatment plan Opportunity. For practices using Salesforce Payments, each settled transaction can also generate a corresponding Payment record linked to the Opportunity.

tab32

Tooth Chart / Perio Chart

maps to

Salesforce Sales Cloud

Custom Object: Dental_Chart__c

1:1
Fully supported

tab32 tooth chart and perio chart data migrate to a custom Dental_Chart__c object linked to the patient Contact. Tooth number, surface condition (MO, DO, MOD), perio probing depths, and mobility grades map to custom fields. Chart type (initial, recall, perio maintenance) stored as Chart_Type__c pick-list.

tab32

Recall / Recare

maps to

Salesforce Sales Cloud

Task + Campaign

many:1
Fully supported

tab32 recall intervals (6-month, annual, perio) merge into Salesforce Tasks with reminder dates. Bulk recall campaigns (e.g., all patients due for hygiene in Q1) map to Salesforce Campaigns with Campaign Member status reflecting recall completion. We also preserve any validation rules defined on these fields in the mapping documentation.

tab32

Custom Dental Properties

maps to

Salesforce Sales Cloud

Custom Fields on Corresponding Objects

1:1
Fully supported

tab32 custom fields on any object migrate as Salesforce custom fields with the __c suffix. Field types (pick-list, date, text, number) map to equivalent Salesforce field types. tab32 formula fields require recalculation in Salesforce as formula fields or flow-triggered updates.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

tab32 logo

tab32 gotchas

High

Data quality inheritance blocks clean migration

High

DSO multi-location structure requires explicit office mapping

Medium

Imaging data lives outside the standard export path

Medium

Fee schedule consolidation is a pre-migration prerequisite

Low

Training and support model assumes daytime availability

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Provider-to-User owner resolution fails without Salesforce User invites

    tab32 providers must exist as Salesforce Users for appointments and treatment plans to inherit the correct OwnerId. If a provider does not have a Salesforce login, their appointments land under a fallback DSO admin User, breaking provider-specific reporting in Salesforce. We flag all unmatched provider IDs before migration and your team must issue Salesforce invitations to each provider who needs their own User record before data lands — this is a pre-migration requirement, not a post-migration fix.

  • Insurance carrier data requires a custom junction object for coverage details

    Salesforce has no native dental insurance coverage object. tab32 stores subscriber ID, group number, effective dates, and coverage percentages per patient per carrier. These do not map to any standard Salesforce field. We create a custom Dental_Coverage__c junction object between Contact and the carrier Account, with Subscriber_ID__c, Group_Number__c, Coverage_Start__c, Coverage_End__c, and Coinsurance__c fields. Without this custom object, coverage data either drops or requires manual re-entry after migration. This custom object also supports coordination‑of‑benefits scenarios where a patient has multiple insurance plans, allowing the DSO to track primary, secondary, and tertiary coverage details within Salesforce.

  • Treatment plan and claim relationships require Salesforce Bulk API sequencing

    tab32 treatment plans link to patients, providers, and appointments. Claims link to patients, providers, and insurance carriers. Salesforce requires parent records (Accounts, Contacts, carrier Accounts) to exist before child records (Opportunities, custom dental objects) can reference them via lookup fields. We sequence the migration: carrier Accounts first, then patient Contacts, then Treatment_Plan__c and Opportunity records, then Events. Skipping this order creates orphaned lookups and validation errors in Salesforce. We also generate a dependency report before migration to identify any records that violate this hierarchy, allowing your team to clean up data in tab32 before the load.

  • Recall and recare intervals do not map to Salesforce native scheduling

    tab32 recall intervals (e.g., 6-month hygiene recall, annual perio maintenance) are scheduling constructs with automatic patient outreach triggers. Salesforce has no native recall object — these must migrate as Salesforce Tasks with reminder ActivityDate values, or as Campaign Members in a recall Campaign. The outreach automation (text reminders, email recalls) that tab32 handles natively must be rebuilt in Salesforce using Flow or a dental-specific AppExchange app like Lighthouse 360 or Demandforce.

  • Clinical imaging URLs do not migrate as files — only as text references

    tab32 stores X-ray and intraoral image URLs within patient records. These URLs point to tab32's cloud imaging storage. Salesforce does not automatically download and re-host these images. We preserve the URL in a custom field on the Dental_Chart__c object. If tab32's imaging URLs become inaccessible after the migration (account closure, API revocation), images are lost. Your team should export and re-host images in Salesforce Files or a connected PACS system before cutover if image continuity is required.

Migration approach

Six steps for a successful tab32 to Salesforce Sales Cloud data migration

  1. Audit tab32 data model and export clinical-financial object graph

    FlitStack connects to tab32 via API (or CSV export for offline processing) and inventories all patient, provider, appointment, treatment plan, claim, payment, and insurance coverage records. We assess record volume per object, identify duplicate and null-value rates, and produce a data quality report. This step also identifies custom fields and any tab32-specific data points that require Salesforce custom objects or fields. The audit output is a migration scope document that both teams sign off on before development begins.

  2. Build Salesforce custom object schema for dental domain

    Before any data loads, FlitStack deploys the custom dental objects (Treatment_Plan__c, Dental_Chart__c, Dental_Coverage__c) and all required custom fields to the Salesforce org via the Metadata API. We also create the Salesforce User records for each tab32 provider by email invite or admin fallback assignment. The Salesforce admin reviews page layouts, record types (if separating by location), and sharing rules at this stage. No data moves until the schema is validated in a Salesforce sandbox.

  3. Run sample migration with field-level diff across 100–500 records

    A representative slice of patients, appointments, treatment plans, and claims migrates to the Salesforce sandbox. FlitStack generates a field-level diff report showing source value, mapped Salesforce field, and any transformation applied (value mapping, formula recalculation, or carrier Account lookup resolution). Your team verifies provider ownership, insurance carrier lookups, claim stage mapping, and treatment plan tooth-number accuracy. Any mapping errors are corrected before the full run is scheduled.

  4. Execute full migration with delta-pickup window at cutover

    Full data export runs from tab32 to Salesforce production. A delta-pickup window (typically 24–48 hours) captures any records created or modified in tab32 during the cutover. FlitStack logs every operation to an audit trail and performs a reconciliation count against tab32's record totals. If reconciliation fails (record count mismatch, validation errors above threshold), one-click rollback reverts the Salesforce org to pre-migration state. Your team receives a migration report with record counts by object, error log, and field-level summary.

  5. Post-migration: rebuild outreach automations in Salesforce Flow

    FlitStack exports tab32's recall interval settings, recare rules, and patient outreach templates as documentation for your Salesforce admin. The outreach automation (hygiene recall texts, appointment reminders, insurance expiration alerts) must be rebuilt in Salesforce Flow or a dental-specific AppExchange tool — this is not part of the data migration scope. FlitStack can provide a Flow rebuild specification document and can connect you with a Salesforce dental-specialty partner if needed.

Platform deep dives

Context on both ends of the pair

tab32 logo

tab32

Source

Strengths

  • Fully cloud-native on Google Cloud Platform with no server infrastructure required and no per-practice hardware footprint.
  • Purpose-built for DSO-scale multi-location management with centralized reporting, fee schedule normalization, and office-level permission structures.
  • Bundled patient engagement suite: two-way texting, automated reminders, e-forms, e-statements, and mobile payments in one platform without per-feature add-on pricing.
  • Open Data Warehousing API provides transparent access to the practice data warehouse for BI and analytics integrations.
  • AI voice charting and AI-driven perio exam dictation are first-to-market clinical features that reduce manual documentation burden.

Weaknesses

  • Support responsiveness lags at 24–48 hours for routine queries, making the platform difficult to use during onboarding and operational troubleshooting.
  • Steep learning curve even for technically sophisticated teams — one reviewer explicitly recommended competing platforms for better live training support.
  • Pricing lacks transparency with reported hidden add-on charges pushing realistic costs above advertised tiers, particularly at enterprise scale.
  • Poor feature discoverability in the UI means staff frequently cannot locate or configure capabilities they have paid for without external consulting help.
  • Customer reviews are sparse on major platforms, making independent evaluation difficult — the available reviews show a bimodal pattern of enthusiastic long-term users and frustrated switchers.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across tab32 and Salesforce Sales Cloud.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    tab32: Not publicly documented.

  • Data volume sensitivity

    A

    tab32 exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your tab32 to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about tab32 to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during tab32 to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your tab32 to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most tab32-to-Salesforce migrations complete in 48–72 hours of clock time for under 50,000 patient records. Larger DSO setups with 200,000+ records across multiple locations or complex treatment plan history extend to 7–14 days. The pre-migration schema build (Salesforce custom objects and field deployment) typically takes 3–5 business days. Provider-to-User resolution and Salesforce admin sign-off on record types are the longest planning steps.

Adjacent paths

Related migrations to explore

Ready when you are

Move from tab32.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day