Redtail to Salesforce Migration Guide (2026)

Migrating from Redtail CRM to Salesforce Financial Services Cloud is a schema translation problem, not a lift-and-shift. Redtail stores everything at the contact level — Households are labels, not data aggregation points. Salesforce FSC inverts that hierarchy entirely: the Household is a Business Account with rollup summaries, and every person is a Person Account linked through an Account-Contact Relationship (ACR) junction object. If you export Redtail as flat CSV files and push them into Salesforce without restructuring the relational graph, you will orphan notes, sever household links, and break the financial rollups your advisors depend on.

If you only need a current client list, CSVs can work. If you need full notes, activities, documents, financial accounts, UDFs, and household integrity, plan for ETL and a real cutover runbook.

This guide covers the architectural mismatch, every viable extraction and loading method with its trade-offs, object-level mapping, API constraints on both sides, and the edge cases that silently destroy data during a Redtail to Salesforce migration. For a detailed walkthrough of getting your data out of Redtail, see How to Export All Data from Redtail CRM: Methods & Limits. For target-side structure, see How to Export Data from Salesforce Financial Services Cloud.

Why Wealth Management Firms Leave Redtail for Salesforce FSC

The migration drivers are consistent across the firms we work with:

• Scalability ceilings. Redtail works well for solo advisors and small teams, but multi-branch structures, OSJ compliance processes, and cross-team collaboration strain its architecture. Salesforce FSC supports those organizational patterns natively.
• Automation limits. Redtail's workflows require manual steps and lack the conditional logic that growing firms need for onboarding, compliance reviews, and service scheduling. Salesforce Flows replace those manual steps with programmable automation.
• Ecosystem integration. Redtail integrates with a narrower set of custodians, portfolio tools, and marketing platforms. Salesforce's AppExchange and MuleSoft connectors give firms access to thousands of pre-built integrations — Orion, Black Diamond, Tamarac, DocuSign, and more.
• Reporting and AI. Salesforce provides predictive analytics, next-best-action recommendations, and AI-driven client engagement scoring that Redtail does not offer.

Be honest about fit. If your firm has a small team, light reporting, and no serious household or downstream automation requirements, Salesforce can be too much platform. If you are standardizing an enterprise wealth stack, Redtail usually becomes the ceiling before Salesforce does.

For a broader look at the business drivers, see Why Top-Performing Teams are Migrating to Salesforce Service Cloud.

The Core Challenge: Data Model Architecture Mismatch

This is the single most important section for anyone planning a Redtail to Salesforce FSC migration. The data model mismatch is where nearly every DIY migration breaks.

Redtail is contact-centric. Every record — individual or organization — lives in a single contacts table, distinguished by a type field. Households (called "Families" in Redtail) are simple grouping labels attached to contacts. No data rolls up to the Household level. Advisors interact with the client record, not the family record. When you export this data, you receive flat lists of contacts tied loosely by household string identifiers.

Salesforce FSC is account-centric with a Household hierarchy. A Person Account (which combines Account and Contact fields into a single record) represents an individual. A Household is a Business Account that groups Person Accounts together. The link between a Person Account and a Household Account is made through the Account-Contact Relationship (ACR) junction object, which carries role definitions, start/end dates, and rollup configuration. (help.salesforce.com)

This means a single Redtail "Family" must be decomposed and rebuilt as:

1. One Household Account (Business Account with record type = Household)
2. Multiple Person Accounts — one per family member
3. One ACR record per person linking them to the Household, with role (Primary, Secondary, Dependent) and rollup settings
4. Contact-Contact Relationships for spouse, parent-child, and other interpersonal links

If you skip the ACR records, Salesforce's Household rollups — aggregated AUM, total financial accounts, consolidated activity feeds — will not function. If you push Redtail contacts directly into Salesforce without engineering the ACR junction layer, you will orphan financial accounts and destroy the relational integrity of your CRM.

Migration Approaches: API vs. Database Backup vs. Custom ETL

There are four practical ways to move data from Redtail to Salesforce. Each has hard constraints.

1. Native Export → CSV Import via Data Loader

How it works: Request a database backup from Redtail's Admins Only → Dropbox Files and Database Backups section. This produces a MySQL .sql dump inside a .zip archive. Restore it locally, extract tables to CSVs, then import into Salesforce using Data Loader or Data Import Wizard. Salesforce's Data Import Wizard caps at 50,000 records per import; Data Loader handles larger CSV-based loads. (help.salesforce.com)

When to use: Small firms (<5,000 contacts) with a dedicated database engineer and simple Household structures.

Pros:

• No API rate limit concerns on the extraction side
• Full historical data in a single dump
• Free tooling (MySQL + Salesforce Data Loader)

Cons:

• The backup strips the user lookup table — added_by fields contain numeric IDs with no corresponding names table. You must manually build a user mapping.
• Attachments from Redtail Imaging and email archives (Zimbra .zdb format) are excluded entirely.
• Activities are not pre-split into Tasks vs. Events — you must parse the type field and route accordingly.
• Requires MySQL expertise to restore and query.
• High risk of breaking parent-child links when rebuilding relational IDs manually.

Complexity: Medium

2. API-Based Migration (Redtail REST → Salesforce Bulk API 2.0)

How it works: Extract data from Redtail's REST API endpoint by endpoint — contacts, notes, activities, opportunities — then transform and load into Salesforce via Bulk API 2.0. (api2.redtailtechnology.com)

When to use: Firms that need full user attribution, relational integrity, and the ability to run incremental delta syncs before cutover.

Pros:

• Preserves createdById and lastModifiedById on every record
• Supports pagination with updated_since filters for delta extraction
• JSON responses maintain relational foreign keys (e.g., householdId on contacts)

Cons:

• Redtail's public API terms reserve the right to restrict excessive request volume. The public authentication reference exposes a Tier value but does not publish a durable, official per-plan rate-limit matrix. Secondary integration guides commonly report approximately 100 requests per minute on lower tiers, but treat that as field guidance, not a contract. (redtailtechnology.com)
• Every list endpoint caps default responses at 50 records — you must implement pagination or silently lose data
• Redtail uses HTTP Basic Auth with a user-key system, not OAuth 2.0
• Deleted records do not appear in updated_since queries — you need a separate full-ID-list reconciliation pass
• Document extraction is per contact via contacts/{CONTACTID}/documents, making attachment-heavy backfills slower than teams expect

Complexity: High

3. Third-Party Middleware (Zapier, MuleSoft, Starfish ETL)

How it works: Use a pre-built connector between Redtail and Salesforce. Zapier offers a basic Redtail ↔ Salesforce integration. MuleSoft and Starfish ETL offer more control over transformation logic. (zapier.com)

When to use: Ongoing sync between systems during a parallel-run period, or lightweight record-level triggers.

Cons:

• Zapier's Redtail connector is limited to a subset of endpoints and does not handle Household reconstruction
• These tools are designed for ongoing sync, not bulk historical migration — they hit Redtail's rate limits quickly on backfill
• Complex Household-to-ACR transformations require custom logic that middleware UIs struggle to express
• Generic ETL tools are not built for FSC's ACR junction objects

Complexity: Low (for simple sync) / High (for full migration)

4. Managed Migration Service

How it works: A specialized team handles extraction (typically using a combination of the database backup and API), schema transformation, loading via Salesforce Bulk API 2.0, relationship rebuilding, and validation.

When to use: Any firm where the cost of getting it wrong — broken Household rollups, lost compliance notes, orphaned activities — exceeds the cost of hiring experts.

Complexity: Low (for your team)

Approach Comparison

Pre-Migration Planning & Data Audit

Before touching any export button, audit what you actually have in Redtail. We've seen firms attempt to migrate 50,000 contact records only to discover 30% are duplicates, inactive, or test data from a decade ago. Migrating legacy garbage into a pristine Salesforce org guarantees immediate user adoption failure.

Data audit checklist:

• Contacts: Count individuals vs. organizations (type field in Redtail). Identify duplicates by email, SSN last-4, or name+DOB.
• Households/Families: Map every family grouping. Identify orphan contacts (no family assignment).
• Financial Accounts: Catalog manually tracked accounts (policies, annuities, investment accounts). Decide which map to FSC Financial Accounts vs. custom objects.
• Notes: Count per-contact note volume. Check for HTML formatting, embedded images, and excessively long text blobs (Salesforce ContentNote body has a 131,072 character limit).
• Activities: Separate tasks from appointments. Redtail stores both under a single Activities object — Salesforce requires them split into Task and Event objects. (help.wealthbox.com)
• User Defined Fields (UDFs): Export all UDF definitions. These need to become Salesforce custom fields or picklist values.
• Keywords/Tags: Decide whether these map to Salesforce custom picklists, multi-select picklists, or a custom Tag object.
• Attachments: Confirm whether documents live in Redtail Imaging (separate from the database backup).
• User IDs: Export user names and IDs separately — the database backup does not include the user lookup table.

Migration scope decisions:

• Big bang vs. phased: A weekend cutover (big bang) works for firms under 20,000 records. Larger firms benefit from a phased approach: migrate historical data first, then execute a final delta migration of records created or modified since the initial load.
• What to leave behind: Archived contacts not accessed in 3+ years, test records, voided opportunities. Migrating junk data costs real money in Salesforce storage and API calls.
• History depth: Many firms do not need every closed task from 2013 in Salesforce, but if compliance or service history depends on it, cut it only with written sign-off.

For broader migration planning guidance, see Best Practices for CRM Data Migration in 2026 and The Ultimate CRM Data Migration Checklist.

Data Model & Object Mapping Guide

This is the mapping table your engineering team needs. Start with the target model, not the source columns. For most new FSC orgs, Person Account is the safer target than the legacy individual model. Use the standard Financial Account model where your org has adopted the core-platform FSC approach. (help.salesforce.com)

Handling Redtail UDFs

Redtail User Defined Fields are the most commonly underestimated migration challenge. UDFs in Redtail are loosely typed — a field might contain dates stored as strings, numeric values in text fields, or picklist values that have drifted over years of manual entry. Redtail lets admins create UDFs with types like text, predefined list, number, true/false, yes/no, and date — but the same business meaning is often stored inconsistently across contact UDFs, account UDFs, tags, and free-text notes. Standardize that before load, not after go-live. (redtailtechnology.com)

For each UDF:

1. Export the field definition (name, type, allowed values)
2. Audit actual data values for consistency
3. Create a corresponding Salesforce custom field with the correct data type
4. Write transformation rules to clean and cast values (e.g., "01/15/2024" → 2024-01-15)

Execution: Extract, Transform, Load

A reliable Redtail to Salesforce migration follows this order: extract → stage → transform → load → validate → delta cutover. Do not load directly from Redtail into production Salesforce if you care about auditability or reruns. Stage raw source data first so you can reproduce the exact payload that created each Salesforce record.

Step 1: Extract from Redtail

The most reliable extraction combines both the database backup and API:

• Database backup gives you the complete historical dataset in one shot, with no rate limit concerns.
• API calls supplement the backup with user attribution (the backup strips user IDs), any records created after the backup was generated, and documents (which are fetched per contact).

# Pseudocode: Redtail API extraction with pagination and rate limiting
import requests
import time
 
BASE_URL = "https://api.redtailtechnology.com/crm/v1"
HEADERS = {
    "Authorization": f"UserKey {API_KEY}",
    "Content-Type": "application/json"
}
 
def extract_all(endpoint, params=None):
    records = []
    page = 1
    while True:
        resp = requests.get(
            f"{BASE_URL}/{endpoint}",
            headers=HEADERS,
            params={**(params or {}), "page": page}
        )
        if resp.status_code == 429:  # Rate limited
            time.sleep(60)  # Back off for 1 minute
            continue
        resp.raise_for_status()
        batch = resp.json()
        if not batch:
            break
        records.extend(batch)
        if len(batch) < 50:  # Default page size
            break
        page += 1
        time.sleep(0.6)  # Stay under ~100 req/min
    return records
 
contacts = extract_all("contacts")
notes = extract_all("notes")
activities = extract_all("activities")

Step 2: Transform

This is where the schema translation happens. Key transformations:

1. Split contacts by type → Individuals become Person Account payloads, organizations become Business Account payloads
2. Build Household Accounts from the householdId / family groupings
3. Generate ACR records linking each Person Account to its Household, with role assignment
4. Split activities into Task and Event payloads based on the type field
5. Clean notes — strip HTML tags if targeting ContentNote, truncate to 131,072 characters, preserve timestamps and author attribution
6. Map UDFs to custom field API names using your pre-built mapping table
7. Build a user mapping table — match Redtail numeric user IDs to Salesforce User record IDs

Step 3: Load into Salesforce

Use Bulk API 2.0 for any object with more than 2,000 records. Salesforce documents Bulk API 2.0 as the preferred API for high-volume, asynchronous CRUD workloads. (help.salesforce.com)

The loading order is strict. You must load parents before children to maintain foreign key dependencies:

1. Users (ensure all Salesforce users exist first)
2. Household Accounts (Business Accounts with Household record type)
3. Person Accounts (each gets a Salesforce ID)
4. ACR records (reference both Household Account ID and Person Account Contact ID)
5. Contact-Contact Relationships (spouse, child, etc.)
6. Financial Accounts + FinancialAccountRole records
7. Tasks and Events (reference Person Account/Contact IDs)
8. ContentNotes + ContentDocumentLink (to attach notes to the correct record)
9. Opportunities and remaining objects

# Salesforce Bulk API 2.0 — create an ingest job
curl -X POST https://yourinstance.my.salesforce.com/services/data/v67.0/jobs/ingest \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "object": "Account",
    "operation": "insert",
    "contentType": "CSV"
  }'
 
# Upload CSV data
curl -X PUT https://yourinstance.my.salesforce.com/services/data/v67.0/jobs/ingest/{jobId}/batches \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: text/csv" \
  --data-binary @household_accounts.csv
 
# Mark job complete
curl -X PATCH https://yourinstance.my.salesforce.com/services/data/v67.0/jobs/ingest/{jobId} \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"state": "UploadComplete"}'

Log every rejected row, owner-crosswalk miss, and relationship rebuild failure to a replayable error table — not ad hoc text files.

Edge Cases That Silently Break Migrations

These are the issues that don't surface until an advisor opens a client record and finds missing history:

• Duplicate contacts: Redtail firms commonly have 10–30% duplicate contacts accumulated over years of manual entry. Run deduplication before loading into Salesforce — Salesforce's native duplicate management tools do not effectively handle Person Accounts. Dedupe on deterministic keys: Redtail IDs, household IDs, email, and normalized legal name. Never on name alone.
• Notes with HTML formatting: Redtail email notes often contain raw HTML. Salesforce ContentNote accepts rich text, but rendering may break. Strip <style> tags and inline CSS, preserve <p>, <br>, and <b> tags.
• Long text blobs: Notes exceeding 131,072 characters must be truncated or split. Log every truncation for compliance review.
• Missing activity types: Redtail's activity_type field must match a value from its own lookup table (/crm/v1/activitytypes). If your export contains activity types that don't map to a Salesforce Task Type or Event Type picklist value, those records will fail on import.
• Recurring activities: Future occurrences of recurring activities are not included in the database backup. If your firm relies on recurring review meetings, these must be recreated manually in Salesforce.
• Attachments: Documents stored in Redtail Imaging are completely separate from the CRM database backup. They require a separate extraction workflow and load into Salesforce Files (ContentVersion + ContentDocumentLink). Salesforce support docs recommend special CSV prep and often batch size of 1 for attachment-style imports. (help.salesforce.com)
• Email archives: Redtail's email archiving uses a proprietary Zimbra-based system (.zdb format). These cannot be directly imported into Salesforce — they need conversion to .eml or direct parsing before creating EmailMessage or Task records.
• Salesforce automation during load: Apex triggers, validation rules, and Flows on the Salesforce side can cause bulk jobs to fail. Disable non-essential triggers and validation rules during the initial data load, then re-enable them after validation.

Limitations & Constraints

Redtail Side

• No single "Export Everything" button. The database backup covers most record types but strips user IDs and excludes attachments and email archives.
• API rate limits throttle extraction at approximately 100 requests/minute on standard plans, though Redtail's API terms do not publish a durable per-plan rate-limit matrix — treat the 100 req/min figure as field guidance, not a contract. (redtailtechnology.com)
• Deleted records are invisible to updated_since API queries — you need a full reconciliation pass to catch deletions.
• Notes are append-only — no PATCH endpoint exists for modifications.
• Custom Exports are designed for selected contact fields, not full-fidelity relational exports.

Salesforce Side

• Governor limits per transaction: 100 SOQL queries, 150 DML statements, 10,000 DML rows.
• Bulk API 2.0 allocations: 15,000 batch submissions per rolling 24 hours, shared between Bulk API and Bulk API 2.0.
• Daily API call cap: 100,000 base calls + per-user additions (Enterprise: +1,000/user; Unlimited: +5,000/user). Monitor org API usage — limits apply across REST, SOAP, and Bulk APIs. (developer.salesforce.com)
• Person Account irreversibility: Once Person Accounts are enabled in an org, they cannot be disabled. Confirm your FSC architecture before loading any data.
• Sandbox API limits differ from production: Sandboxes have a fixed 5M API calls/24h regardless of edition.

Validation & Testing

Never trust a migration without quantitative validation. Do not assume a 200 OK response means the data is correct.

Record count comparison:

Field-level validation: Sample 5% of records per object. For each sampled record, compare every mapped field value between Redtail and Salesforce. Focus on:

• Date fields (timezone offsets can shift dates by one day)
• Currency fields (decimal precision)
• Phone number formatting
• UDF values (type casting errors)

Relationship validation: For every Household Account, verify:

• Correct number of Person Accounts linked via ACR
• Role assignments (Primary, Secondary) match Redtail family roles
• Contact-Contact Relationships (spouse, child) exist and are bidirectional

UAT process: Have 3–5 advisors review their own book of business in the Salesforce sandbox. They will catch data quality issues that automated checks miss — things like a client's nickname being mapped to the legal name field, or a note appearing on the wrong contact.

Rollback plan: Keep your Redtail subscription active for a minimum of 30 days post-cutover. If critical data integrity issues surface, you need a clean source of truth to re-extract from. Your rollback plan should be operational, not theoretical: preserved Redtail access, archived extracts, and a clear production sign-off gate.

Post-Migration Tasks

• Rebuild automations: Redtail workflows do not export. Recreate only the automations users actually need in Salesforce Flows — don't copy Redtail habits one-for-one into Salesforce.
• Reconnect integrations: Custodial feeds (Schwab, Fidelity, Pershing), portfolio management tools (Tamarac, Orion, Black Diamond), and marketing platforms need to be pointed at Salesforce.
• User training: Salesforce FSC's Household-centric navigation is fundamentally different from Redtail's contact-first interface. Budget 2–4 hours of hands-on training per advisor on household views, task vs. event behavior, and financial account relationships.
• Monitor for 30 days: Run daily record count checks, spot-check note content, and monitor Salesforce error logs for failed automation triggers on migrated data.

When to Use a Managed Migration Service

Build in-house if you have a dedicated Salesforce developer and someone who understands Redtail's database schema and you're migrating fewer than 10,000 records with simple Household structures.

For everyone else, the math favors a managed service:

• Hidden engineering cost: A senior developer spending 100–200 hours on a migration script at $150/hr is $15,000–$30,000 in opportunity cost — before accounting for bugs, retesting, and the business risk of getting Household rollups wrong.
• Household reconstruction complexity: Building the ACR junction records, role assignments, and Contact-Contact Relationships programmatically requires deep knowledge of both Redtail's flat model and Salesforce FSC's relational model. This is not a weekend project.
• Compliance risk: Wealth management firms are audited on data completeness. A migration that drops 2% of client notes or severs activity history from the wrong contact creates a compliance exposure that far exceeds the cost of hiring experts.

How ClonePartner Handles Redtail-to-FSC Migrations

We approach Redtail-to-Salesforce migrations as a two-source extraction problem. Rather than relying solely on the API (and fighting rate limits for weeks), we parse the raw MySQL database backup directly and transform it into Salesforce Bulk API 2.0 payloads. This gives us full historical coverage without rate limit constraints.

What that means in practice:

• Household → ACR transformation is automated. We reconstruct the full Household hierarchy — Person Accounts, ACR junction records, roles, and Contact-Contact Relationships — from Redtail's flat family groupings without manual VLOOKUPs or spreadsheet gymnastics.
• UDFs map to native custom fields. Redtail User Defined Fields and Keyword tags are mapped directly to Salesforce custom fields and picklists with type casting and data validation, not truncated into a generic text blob.
• Point-in-time delta migrations. Firms keep using Redtail right up until the cutover weekend. We run the bulk historical migration first, then execute a precise delta migration of records created or modified since the initial load. No continuous sync bridge. No data drift.
• User attribution is preserved. We build the user mapping table from the Redtail application and apply it to every note, activity, and record change — solving the biggest gap in the database backup.

Best Practices Checklist

• Back up everything — download the Redtail database backup and Imaging documents before starting
• Run test migrations in a Salesforce Sandbox — never load directly into production
• Validate incrementally — check record counts and field values after each object load, not just at the end
• Keep Redtail active post-cutover — minimum 30 days for rollback capability
• Automate repetitive transformations — manual mapping in Excel doesn't scale past 5,000 records
• Document every mapping decision — future auditors and administrators will need to understand why UDF_47 became Investment_Preference__c
• Test with real advisors — automated validation catches quantity errors, humans catch context errors

What Comes Next

A Redtail to Salesforce migration is one of the more technically demanding CRM transitions in wealth management because of the data model inversion. The firms that get it right treat it as an architecture project, not a data dump. Map the relationships first, validate obsessively, and don't underestimate the Household reconstruction step.

If your scope is current contacts and a few core fields, start with CSVs and native Salesforce loaders. If the requirement is full advisory history with households, financial accounts, files, UDFs, and stable audit trails, treat this as a schema translation project and choose custom ETL or a managed service from day one. The budget conversation should be driven by relationship risk and cutover risk, not by which tool has the cheapest UI.