Salesforce FSC to Redtail CRM Migration: The Technical Guide

Salesforce FSC to Redtail CRM Migration: The Technical Guide

Migrating from Salesforce Financial Services Cloud (FSC) to Redtail CRM is a schema flattening problem. FSC stores client data in a multi-object hierarchy — Person Accounts linked to Household Accounts through Account-Contact Relationship (ACR) junction objects, with Financial Accounts, Opportunities, and custom objects layered on top. Redtail inverts that: everything is contact-centric, households are grouping labels, and there are no true custom objects.

If you export FSC via Bulk API and try to push flat CSVs into Redtail, you will lose household structure, sever note attribution, and orphan activities that advisors depend on for compliance.

This guide covers the architectural mismatch, every viable migration method with trade-offs, object-level mapping, API constraints on both sides, and the edge cases that silently destroy data during this transition. For source-side extraction details, see How to Export Data from Salesforce Financial Services Cloud. For a deeper platform comparison, see Redtail vs Salesforce Financial Services Cloud: The 2026 CTO Guide.

Why Advisory Firms Leave Salesforce FSC for Redtail

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

• Per-seat cost pressure. Salesforce Financial Services Cloud runs $150–$225 per seat per month. The Enterprise Edition costs $325 per user/month, and the Unlimited Edition costs $500 per user/month. Redtail typically costs $99–130/month flat for a 10-advisor team. For a 10-person RIA, the difference can exceed $30,000/year before Salesforce add-ons and admin costs.
• Over-engineering for the use case. Salesforce was built for enterprise sales teams managing high-volume pipelines. Financial advisors use roughly 15–20% of its features and pay for the other 80–85%.
• Admin overhead. FSC's heritage is a strength for large wealth-management enterprises with dedicated Salesforce admins — and a real cost for smaller shops. Redtail requires no dedicated admin; configuration is handled through a point-and-click UI.
• Orion ecosystem integration. Redtail is part of the Orion Advisor Solutions platform, giving firms tighter integration with Orion Planning, Portfolio View, and compliance tools — eliminating the need for middleware between CRM and portfolio management.

Core Data Model Differences

This is the mismatch that breaks most migrations:

Redtail stores contacts, households, notes, activities, and opportunities in a relatively flat relational structure. Household grouping is straightforward: you link individual contacts to a household, and the CRM renders a unified view.

In FSC, the relationship between a Person Account and the Household Account is made through the Account-Contact Relationship object (ACR), which serves as a junction object. That junction object has no equivalent in Redtail — the household link is a direct property on the contact record.

The single biggest mistake is mapping Salesforce object labels literally. In FSC, "Account" can mean a person, a household, or a business. Map by business meaning, not object name.

Migration Approaches

1. CSV-Based Export/Import

How it works: Export FSC data using Data Export Service, Salesforce Reports, or Data Loader into CSV files. Clean and transform in spreadsheets or scripts. Submit CSVs to Redtail's support team for import.

When to use: Small firms (<500 contacts) migrating contacts and basic demographics only.

Key limitation: Redtail does not offer self-service CSV import. The only way to import via CSV file is by emailing a file to their customer service team. You have no control over field mapping, validation, or error handling during import. Notes, activities, and opportunities cannot be imported via this channel. Turnaround time depends on Redtail's support queue — expect 3–10 business days.

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

How it works: Extract data from FSC using Salesforce Bulk API 2.0 or REST API. Transform the hierarchical FSC model into Redtail's flat contact model using custom scripts. Load into Redtail via its REST API.

When to use: Any migration that includes notes, activities, opportunities, or household structures.

Salesforce side: You can process up to 100 million records per 24-hour period using Bulk API 2.0. Note: this is an org-level governor limit shared across all concurrent jobs, not a per-job cap. Salesforce Bulk API allows up to 15,000 batch submissions per 24 hours, shared between Bulk API 1.0 and 2.0. Each batch can contain a maximum of 10,000 records with a 10MB payload limit.

Redtail side: Redtail doesn't publish an official rate limit, but based on observed behavior across multiple migrations, throttling typically starts around 60–80 requests per minute. Add a 150–200ms delay between requests in bulk operations and implement exponential backoff for any 429 responses. The REST API supports single-record POST operations only — there is no batch/array endpoint for creating multiple contacts in one request. Every contact, note, and activity requires its own HTTP call.

Redtail's API base URL is https://api2.redtailtechnology.com/crm/v1/. The v1 API covers contacts, activities, notes, accounts, and a handful of lookup tables. As of this writing, Redtail has not publicly announced an API v2 or a migration to OAuth 2.0. Plan accordingly — the Basic Auth + user-key system is the only available authentication method.

3. Custom ETL Pipeline

How it works: Build a dedicated Extract-Transform-Load pipeline using Python, Node.js, or a data integration tool. Extract FSC data via Bulk API, stage in a local database (PostgreSQL, SQLite), transform the relational graph, then load into Redtail via API.

When to use: Firms with >2,000 contacts, full note and activity history, and complex household structures.

This approach produces the highest fidelity results. The staging database lets you validate referential integrity before writing to Redtail and gives you a rollback point. For enterprise-scale deployments, tools like Azure Data Factory or AWS Glue can add resilience and auditability — but that level of infrastructure is typically overkill for a one-time CRM move.

4. Middleware Platforms (Zapier, Make)

Not viable for migration. These platforms are designed for ongoing event-driven syncs, not bulk historical data transfer. Zapier's Redtail integration covers basic contact creation but cannot handle notes, activities, or household reconstruction at scale. Use these post-migration for ongoing syncs between Redtail and other tools.

5. Managed Migration Service

When to use: When you lack engineering bandwidth, need to preserve compliance-critical data (notes, activity history, document links), or cannot afford a failed migration attempt.

A managed service handles schema translation, API integration, validation, and rollback planning. This is the fastest path for firms without a dedicated developer.

Decision criteria for build vs. buy: Build in-house if you have all four of these: (1) a developer who understands both Salesforce SOQL and Redtail's API, (2) a staging environment, (3) time for two or more test cycles, and (4) an owner for post-go-live QA. If any of these are missing, a managed service typically costs less than the risk of a failed attempt.

Approach Comparison

Pre-Migration Planning

Do not extract a single record until you have audited your Salesforce instance. FSC implementations are notorious for accumulating technical debt.

1. Audit FSC data. Run SOQL queries to count records by object:

SELECT COUNT() FROM Account WHERE IsPersonAccount = true
SELECT COUNT() FROM Account WHERE RecordType.DeveloperName = 'IndustriesHousehold'
SELECT COUNT() FROM AccountContactRelation
SELECT COUNT() FROM Opportunity
SELECT COUNT() FROM Task
SELECT COUNT() FROM Event
SELECT COUNT() FROM ContentNote
SELECT COUNT() FROM FinServ__FinancialAccount__c

2. Identify what Redtail cannot hold. Campaigns, Cases, custom objects, multi-level approval workflows, Apex triggers, Flow automations — all must be archived or abandoned. Create an explicit "does not migrate" list and get stakeholder sign-off.

3. Clean duplicates in FSC first. Deduplication is far easier in Salesforce (with DupeBlocker, Duplicate Rules, or SOQL) than in Redtail. Run duplicate detection before extraction, not after loading.

4. Create UDFs and categories in Redtail. Custom field definitions must be created manually inside the Redtail UI. Once created, you can read and write to custom field values via the API using the field's internal ID. You cannot create UDF definitions programmatically. Set up all activity types, note types, categories, and tags before the migration begins. Fetch and cache the lookup table IDs via the API so your transform layer can validate against them.

5. Map picklist values. Export all Salesforce picklist values and map them to Redtail's fixed lookup tables. Document every value that has no Redtail equivalent — these require either a new Redtail category or consolidation into an existing one.

6. Define migration scope. Will you move email attachments? Historical compliance notes? Archive inactive clients and dead leads — do not pay to migrate garbage data. A typical firm can reduce migration volume 20–40% by excluding leads with no activity in 24+ months.

7. Map users early. Ensure every active and inactive Salesforce user has a corresponding user ID in Redtail so historical notes and activities retain their correct authorship. This is critical for regulatory compliance — SEC and FINRA examiners expect notes to be attributed to the advisor who created them.

8. Choose a cutover pattern. Big-bang weekend cutover is recommended for firms under 50 advisors to prevent split-brain data scenarios. Phased (contacts first, then history) reduces risk for larger firms. For more on coexistence strategy, see Why Running Two CRMs in Parallel Beats a Hard Cutover.

Data Mapping: Salesforce FSC → Redtail CRM

This is the most technically demanding phase. Get the mapping wrong and you corrupt the data silently.

Handling Custom Objects

Redtail does not support true custom objects. If you have custom objects in Salesforce FSC (e.g., a custom Estate_Plan__c object), you have three choices:

1. Map scalar fields to User Defined Fields (UDFs) on the Contact record.
2. Concatenate the custom object data into a formatted Note and attach it to the Contact.
3. Archive the data externally (e.g., in a database or document management system) and store a reference link as a UDF on the Contact.

Migration Architecture

The data flow follows a standard ETL pattern with a critical staging step:

Salesforce FSC (Bulk API 2.0) → Staging DB → Transform Layer → Redtail API (REST v1)

Extract: Use Salesforce Bulk API 2.0 to query Person Accounts, Household Accounts, ACRs, Opportunities, Tasks, Events, ContentNotes, and any custom objects. Do not use the standard REST API for extraction unless you have fewer than 2,000 records. Export as CSV or JSON.

Stage: Load into a local database (PostgreSQL or SQLite). This is where you flatten the hierarchy — join Person Accounts to their Household via ACR, merge Tasks and Events into a single Activity format, and resolve all Salesforce IDs to a mapping table.

Transform: Convert Salesforce picklist values to Redtail lookup table values (activity types, note types, categories). The activity_type field must match a value from Redtail's lookup table. If you pass a free-text string that doesn't match an existing type, the API returns a 422 error. Always pre-fetch the activity types list from /crm/v1/activitytypes and validate against it before posting.

Load: Write to the Redtail API in strict dependency order:

1. Contacts (generates Redtail contact IDs)
2. Households (groups contacts by family)
3. Activities (requires contact_id foreign key)
4. Notes (requires contact_id foreign key)
5. Opportunities (requires contact_id foreign key)

Store Redtail-assigned IDs in your mapping table for each record. Every subsequent record must reference these IDs, not the original Salesforce IDs.

Authentication

Redtail uses HTTP Basic Auth combined with a user-key system, not OAuth 2.0 flows like most modern CRMs. The credentials are a three-part string — api_key:username:password — Base64-encoded and passed as the Authorization header.

Household Flattening: The Hard Part

The ACR resolution is where most migration scripts fail. Here is the concrete transformation:

import base64
import requests
import time
from collections import defaultdict
 
REDTAIL_BASE = "https://api2.redtailtechnology.com/crm/v1"
MAX_RETRIES = 5
 
def get_auth_header(api_key, username, password):
    creds = f"{api_key}:{username}:{password}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {"Authorization": f"Basic {encoded}", "Content-Type": "application/json"}
 
def api_post(headers, endpoint, payload, retry=0):
    """POST with exponential backoff and max retry depth."""
    resp = requests.post(f"{REDTAIL_BASE}/{endpoint}", json=payload, headers=headers)
    if resp.status_code == 429:
        if retry >= MAX_RETRIES:
            raise Exception(f"Max retries exceeded for {endpoint}")
        wait = (2 ** retry) + (time.time() % 1)  # exponential backoff + jitter
        time.sleep(wait)
        return api_post(headers, endpoint, payload, retry + 1)
    resp.raise_for_status()
    return resp.json()
 
# Step 1: Query ACRs to resolve household membership
# This SOQL returns every Person Account and its Household Account assignment
acr_query = """
SELECT AccountId, ContactId, Roles,
       Account.Name, Account.RecordType.DeveloperName,
       Contact.FirstName, Contact.LastName, Contact.Email
FROM AccountContactRelation
WHERE Account.RecordType.DeveloperName = 'IndustriesHousehold'
"""
 
acrs = salesforce.bulk_query(acr_query)
 
# Step 2: Group contacts by household
# A contact may appear in multiple ACRs — pick the primary household
household_map = defaultdict(list)  # household_sf_id -> [contact records]
contact_primary_hh = {}  # contact_sf_id -> household_sf_id
 
for acr in acrs:
    hh_id = acr['AccountId']
    contact_id = acr['ContactId']
    household_map[hh_id].append(acr)
 
    # If contact already assigned, keep the first (or apply your priority logic)
    if contact_id not in contact_primary_hh:
        contact_primary_hh[contact_id] = hh_id
    else:
        # Log secondary household membership — this data will be stored as a note
        log_secondary_household(contact_id, hh_id)
 
# Step 3: Create contacts in Redtail, store ID mapping
sf_to_rt_contact = {}  # salesforce_id -> redtail_id
 
for person in person_accounts:
    contact_payload = {
        "first_name": person['FirstName'],
        "last_name": person['LastName'],
        "email": person.get('PersonEmail'),
        "phone": person.get('Phone'),
        # ... additional field mapping
    }
    result = api_post(headers, "contacts", contact_payload)
    rt_id = result['id']
    sf_to_rt_contact[person['Id']] = rt_id
    time.sleep(0.2)  # 200ms spacing
 
# Step 4: Create households and link contacts
sf_to_rt_household = {}
 
for hh_sf_id, members in household_map.items():
    hh_name = members[0]['Account']['Name']
    # Create household in Redtail
    hh_result = api_post(headers, "households", {"name": hh_name})
    rt_hh_id = hh_result['id']
    sf_to_rt_household[hh_sf_id] = rt_hh_id
 
    # Link each member contact to the household
    for member in members:
        contact_sf_id = member['ContactId']
        if contact_sf_id in sf_to_rt_contact:
            rt_contact_id = sf_to_rt_contact[contact_sf_id]
            api_post(headers, f"households/{rt_hh_id}/contacts",
                     {"contact_id": rt_contact_id})
            time.sleep(0.2)

Idempotent Note Loading

Notes are append-only — there's no PATCH operation, so updates require a DELETE followed by a new POST. This means a retry failure mid-note-load creates duplicates. Build idempotency into your loader:

def load_note_idempotent(headers, contact_id, note_body, note_type, mapping_db):
    """Check mapping table before creating to prevent duplicates on retry."""
    source_hash = hashlib.md5(f"{contact_id}:{note_body}".encode()).hexdigest()
 
    if mapping_db.exists("notes", source_hash):
        return mapping_db.get_rt_id("notes", source_hash)
 
    payload = {
        "contact_id": contact_id,
        "note_type": note_type,
        "body": note_body
    }
    result = api_post(headers, "notes", payload)
    mapping_db.insert("notes", source_hash, result['id'])
    return result['id']

Rate Limit Strategy

Every list endpoint in Redtail caps its default response at 50 records. On the write side, budget for ~60 requests/minute and add 200ms spacing between calls. For a firm with 5,000 contacts, 20,000 notes, and 10,000 activities, that is 35,000 POST requests. At sustained throughput of ~60 requests/minute, the load phase takes approximately 10 hours.

Your loading script must implement exponential backoff with jitter and a maximum retry depth for 429 Too Many Requests errors. Redtail requires User Key authentication, meaning your API calls are attributed to a specific user — which is important for maintaining compliance audit trails on migrated records.

Step-by-Step Migration Process

1. Extract Data from Salesforce. Initiate Bulk API 2.0 jobs for Person Accounts, Household Accounts, ACRs, Opportunities, Tasks, Events, ContentNotes, and custom objects. Download the resulting CSVs or JSON payloads. If you need a source-side checklist, see How to Export Data from Salesforce Financial Services Cloud.

2. Stage and Transform. Load extracted data into a staging database. Normalize dates, owners, picklists, and household roles. Flatten ACR junction records into household assignments on contacts (see the household flattening code above). Merge Tasks and Events into Redtail Activities. Build a source-to-target crosswalk table. Resolve orphaned Contacts (those without an Account in Salesforce) by assigning them a default status.

3. Load Contacts First. Push Contact records to Redtail to generate new Redtail Contact IDs. These IDs are required as foreign keys for all subsequent data. Store each Salesforce ID → Redtail ID mapping immediately.

4. Rebuild Households. Group the newly created Redtail Contacts into Families based on their original Salesforce Household Account IDs. Map relationship types (spouse, child, etc.) from Contact-Contact Relationship records. For contacts that belonged to multiple FSC households, assign the primary household and create a note documenting the secondary membership.

5. Load Child Records. Push Notes, Activities, Opportunities, and Financial Accounts via the Redtail API, associating them with the correct new Redtail Contact IDs from your crosswalk table. Use the idempotent loading pattern to handle retries safely.

6. Validate. Compare record counts between source and target using SOQL SELECT COUNT() against Redtail API counts. Spot-check 5–10% of records at the field level. Have advisors review their top client records.

Log every failure with the source object, source ID, target payload, response code, retry count, and final disposition. That turns reruns from guesswork into controlled operations.

Edge Cases That Break Migrations

Multi-household membership. In FSC, a Person Account can belong to multiple Household Accounts via multiple ACRs. Redtail allows only one household per contact. You must choose a primary household and document the secondary ones as notes or UDFs. Apply a deterministic priority rule (e.g., household with the most recent activity, or the one the advisor designates) so the choice is auditable.

Multi-level relationships. A Contact can simultaneously be a household member, a trustee of a Trust Account, and a board member of a Business Account. Redtail has no multi-layered hierarchy. Use Redtail's "Memberships" and "Linked Contacts" features to approximate this, and accept that some relational context will be reduced to static text in notes.

Notes are append-only. Notes are append-only — there's no PATCH operation, so updates require a DELETE followed by a new POST. If your migration script fails mid-note-load, retries create duplicates. Use the content-hash idempotency pattern described above.

No native upsert. Redtail doesn't have a native upsert endpoint. Without upsert, retries can create duplicates. Use Redtail's internal id field as your primary key and store it in your mapping table on first write. Every subsequent update should reference this ID directly via PUT.

Partial dates. Salesforce allows partial dates (e.g., just a year for a birthdate) in some configurations. Redtail requires strict YYYY-MM-DD formatting. Your transformation script must pad incomplete dates (e.g., 1965 → 1965-01-01 with a flag indicating approximation) or null them out.

Financial Account fidelity loss. FSC's FinServ__FinancialAccount__c stores account number, balance, holdings, roles, and transactions. Redtail's manually tracked accounts have a fraction of these fields — typically just account name, number, value, and type. Holdings-level detail, transaction history, and multi-role assignments (owner, trustee, beneficiary) will not transfer. Archive the full financial account data separately — if you use Orion for portfolio management, this data likely lives there already.

Attachments and documents. Redtail stores documents via Redtail Imaging, which is a separately licensed product with its own upload interface. Salesforce files stored in ContentDocument/ContentVersion must be downloaded individually, then uploaded to Imaging separately — there is no API bridge between the two systems. Redtail Imaging's upload capabilities are limited; check file type support (PDF, DOCX, images) and maximum file sizes before planning document migration. For firms with thousands of documents, this step alone can take longer than the core data migration.

Compliance note metadata. Financial advisory firms subject to SEC Rule 17a-4 and FINRA Rule 4511 must maintain records with specific metadata: author, creation timestamp, and immutability. When migrating notes from FSC to Redtail, verify that each note retains its original author (mapped to the correct Redtail user ID) and creation date. Redtail's append-only note structure provides immutability after creation, but the migration itself must preserve the original timestamp rather than using the migration date. Include the original Salesforce note ID and creation date in the note body as a fallback audit reference.

Deduplication timing. Deduplicate people in Salesforce before you flatten households, not after. Once records are in Redtail, deduplication requires manual review or re-extraction.

Validation and Testing

Do not assume a 200 OK response means the data is correct. A successful POST confirms the record was created — not that it was created correctly.

Record count reconciliation. Compare source counts (SOQL SELECT COUNT()) against Redtail API counts for each object type. Expect 100% match on contacts and households. For notes and activities, allow for a small delta due to records that failed validation — but investigate every discrepancy.

Field-level spot checks. Sample 5–10% of records and verify field values match across platforms. Pay special attention to phone number formatting (Salesforce stores (555) 123-4567, Redtail may strip formatting), date fields (timezone conversion issues), and multi-line address fields.

Relationship validation. Verify every contact's household assignment matches the expected FSC Household. Check that notes and activities are attached to the correct contacts — not to the household or to a different household member.

Compliance note audit. For any firm subject to regulatory examination, verify that migrated compliance notes retain the correct author attribution, original creation date, and complete note body. Test by pulling 10 notes from the most recent SEC/FINRA examination period and confirming they appear correctly in Redtail.

UAT with advisors. Have 2–3 advisors review their top 20 client records in Redtail. They will catch data quality issues that automated checks miss — wrong household groupings, missing notes from specific date ranges, or activities attributed to the wrong advisor.

Rollback plan. Keep your Salesforce org active (read-only) for at least 90 days post-migration. Note: switching an FSC org to read-only does not reduce your Salesforce license cost — you still pay per-seat until the contract term ends or you negotiate a downgrade. Do not decommission until UAT is fully signed off and at least one compliance review cycle has passed. Maintain a full backup of all migrated data independent of both platforms.

Post-Migration Tasks

• Rebuild workflows. Redtail workflows must be recreated manually — they cannot be imported from Salesforce. Prioritize the workflows advisors use daily: client onboarding sequences, review meeting prep checklists, and compliance review reminders. Redtail workflows are linear (step 1 → step 2 → step 3) and do not support conditional branching, so complex Salesforce Flows will need to be simplified or supplemented with manual processes.
• Reconfigure integrations. Reconnect custodian feeds (Schwab, Fidelity), planning tools (eMoney, MoneyGuidePro), and calendar syncs. Test each integration with a live data pull before the team starts using Redtail in production.
• Train the team. Advisors accustomed to FSC's Household views will find Redtail's Contact-centric interface structurally different. Budget 2–4 hours of hands-on training per user. Focus training on: how households work in Redtail, where to find migrated notes and activities, and the new workflow for logging client interactions.
• Monitor for 30 days. Watch for missing records, duplicate contacts created by users who cannot find their migrated clients, broken household links, and activity attribution errors. Assign one person as the migration QA owner for this period.

What You Will Lose

Be explicit with stakeholders about what Redtail cannot replicate:

• Financial Account depth — holdings, transactions, roles, balance history, and multi-party account structures will not transfer with full fidelity. Only account name, number, type, and current value migrate cleanly.
• Custom objects — no equivalent exists; data must be flattened into UDFs/notes or archived externally with reference links.
• Apex automations and Flow logic — must be manually rebuilt as Redtail workflows, which support only linear sequences without conditional branching.
• Multi-household membership — one household per contact in Redtail. Secondary memberships become notes.
• Reporting depth — Salesforce's report builder supports cross-object reporting, custom formulas, and dashboard visualizations. Redtail's reporting is limited to pre-built report templates with basic filtering.
• Household rollup behavior — FSC groups can roll up financial accounts, goals, events, tasks, assets and liabilities, and referrals. Those rollups have no Redtail equivalent.
• Granular security model — Salesforce's profile/permission set/field-level security architecture has no equivalent in Redtail's simpler role-based access.

For most RIAs under 15 advisors, Redtail wins on cost and simplicity — both are purpose-built for advisors and typically cost a fraction of Salesforce FSC's licensing plus admin overhead, though FSC still wins for complex multi-entity household structures.

The right answer depends on whether you are paying for capability you actually use.

Managed Migration Services

If you lack the engineering resources described in the API-based approaches above, a managed migration service handles schema translation, API integration, staging, validation, and rollback planning. This is typically the right choice when:

• Your firm has 5+ years of compliance-critical notes and activity history that must be preserved with author attribution and timestamps intact
• FSC custom objects or Apex logic need to be archived and re-mapped to UDFs/notes
• You have no engineering staff and need the migration completed within a defined timeline
• A failed migration attempt would disrupt client service during a review season

ClonePartner handles CRM migrations across financial services platforms — including Salesforce FSC to Redtail — where household reconstruction, note attribution, and custom field translation are the hardest parts. We build custom ETL pipelines with staging databases, validate data before loading, and deliver completed migrations in days rather than months.