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.

Schema translation means you are not just moving data between fields — you are rebuilding the relational graph itself. A flat Redtail contact with a household label must become a Salesforce Person Account, linked to a Household Business Account via an ACR junction record, with role semantics, rollup flags, and relationship direction explicitly set. None of that structure exists in the source. You are constructing it during the transform phase.

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)

FSC licensing prerequisite: Salesforce Financial Services Cloud is a paid add-on that requires a compatible base edition (typically Enterprise or above). Every FSC-specific object referenced in this guide — FinancialAccount, FinancialAccountRole, AccountContactRelation with FSC role semantics, Household record types — depends on that license being active in the target org. If you load data into an org without an FSC license, every FSC object reference will fail. Confirm your org's license before writing a single transformation script.

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

The IsPersonAccount flag. When your FSC org has Person Accounts enabled, every Account record is either a Person Account or a Business Account. The boolean field IsPersonAccount on the Account object controls this. It is set by Salesforce automatically based on record type — you cannot set it directly via DML. This matters during SOQL queries: filtering on IsPersonAccount = true returns only individuals; IsPersonAccount = false returns only Business Accounts (Households, organizations). Any reporting or automation that queries across Account types needs to account for this flag, and any Apex triggers on Account will fire for both types unless you explicitly filter.

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. Each API request must include a UserKey header derived from your Redtail API credentials — this is distinct from your database key, which is a separate per-account identifier used for some administrative operations. Mixing them up is a common source of 401 errors on first implementation.
• 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

| Factor | CSV Import | API-Based | Middleware | Managed Service | |---|---|---|---| ---| | User attribution preserved | ❌ (manual rebuild) | ✅ | Partial | ✅ | | Household → ACR reconstruction | Manual | Custom code | ❌ | ✅ | | Attachments included | ❌ | Partial | ❌ | ✅ | | Rate limit risk | None (one-time dump) | High | High | Handled | | Engineering effort | 40–80 hours | 100–200+ hours | 20–60 hours | ~0 hours | | Best for | Small firm, simple data | Dedicated dev team | Parallel-run sync | Most firms |

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.
• User Defined Fields (UDFs): Export all UDF definitions. These need to become Salesforce custom fields or picklist values. Note that Salesforce enforces an 80-character limit on custom field labels — any Redtail UDF name longer than 80 characters will cause a load failure and must be shortened before you create the corresponding Salesforce field.
• 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 The Ultimate CRM Data Migration Checklist 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)

Field-Level Mapping Examples

The object table above maps at the object level. The table below shows concrete field-to-field mappings for the most commonly migrated objects. Use these as a starting point — your actual field names in the MySQL dump may vary based on your Redtail version and UDF configuration.

The External ID Pattern

Every Salesforce object you load should carry the source Redtail ID in a dedicated External ID field. Create a custom field — for example, Redtail_ID__c — on each target object and mark it as an External ID in the Salesforce field definition.

This matters for three reasons:

1. Upsert operations. Bulk API 2.0 supports upsert by External ID. If you re-run a load (for delta migrations or error recovery), Salesforce matches on the External ID and updates the existing record instead of creating a duplicate.
2. Cross-object relationship resolution. When loading child records (ACRs, Activities, Notes), you can reference the parent by its Redtail source ID rather than having to track the Salesforce-generated ID across pipeline stages. Bulk API 2.0 resolves the relationship at load time.
3. Auditability. Every loaded record is traceable back to its Redtail source row. This is table stakes for compliance environments.

# Example: Bulk API 2.0 upsert using External ID
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": "Contact",
    "operation": "upsert",
    "externalIdFieldName": "Redtail_ID__c",
    "contentType": "CSV"
  }'

Without this pattern, delta migrations require full ID reconciliation across every object — a fragile, error-prone process that does not scale.

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 — check that the field label does not exceed 80 characters; Salesforce will reject custom field creation if it does
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
8. Populate Redtail_ID__c on every transformed record before load — do not skip this step, or you will lose the ability to run clean delta upserts

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.
• Person Account name constraints: Salesforce requires LastName to be non-null on every Person Account. Middle names and suffixes must go into their dedicated fields (MiddleName, Suffix) — concatenating them into LastName causes downstream display and deduplication problems. A Person Account with a null LastName will be rejected at load time.
• 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.
• Custom field label length: Salesforce enforces an 80-character limit on custom field labels. UDF names longer than 80 characters will cause field creation to fail silently or return an error depending on the tool. Audit and shorten all UDF names before creating target fields.

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 types and data limits: Developer sandboxes support up to 200 MB of data; Developer Pro sandboxes up to 1 GB; Partial sandboxes up to 5 GB; Full sandboxes mirror production. If you are testing a large migration in a Developer sandbox, you will hit data volume limits before you can validate a full-scale load — use a Partial or Full sandbox for realistic volume testing.
• 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
• Confirm FSC licensing — verify the target Salesforce org has an active FSC license before writing any transformation scripts
• Create Redtail_ID__c External ID fields — add External ID custom fields on every target object before load; populate them in the transform step
• Run test migrations in a Salesforce Sandbox — never load directly into production; use a Partial or Full sandbox for realistic volume testing
• 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.