Migrating FSC to Redtail is a schema flattening problem — you must convert Person Accounts, ACR junction objects, and custom objects into Redtail's flat contact model without losing note attribution or household integrity.
Migrating from Salesforce Financial Services Cloud (FSC) to Redtail CRM is fundamentally a schema flattening problem: FSC organizes client data in a multi-object relational hierarchy — Person Accounts, Household Accounts, Account-Contact Relationship junction objects, and custom objects — while Redtail uses a flat, contact-centric model where households are simple grouping labels and no true custom objects exist. There is no native migration path or official tooling between the two platforms; all data movement requires custom extraction via Salesforce Bulk API or REST API, programmatic transformation of the relational graph, and record-by-record loading into Redtail's REST API. Custom work is required for every non-trivial data entity: household structures must be reconstructed, financial account data must be archived or discarded, notes must be reformatted for Redtail's append-only model, and FSC custom objects have no target equivalent. Teams without in-house developers experienced in both Salesforce SOQL and the Redtail API should expect to engage a managed migration service to avoid compliance-critical data loss.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not migrate if your compliance team or broker-dealer custodian specifically requires Salesforce
Check whether you rely on FSC-specific features like Actionable Relationship Center (ARC), Financial Deal Management, or custom Apex automations — Redtail has no equivalent. Also verify that your firm's SEC Rule 17a-4 and FINRA 4511 recordkeeping obligations can be met by Redtail's note and activity architecture before committing to migration.
Redtail UDFs support text, list of values, number, true/false, yes/no, and date types
That covers many FSC custom fields but not arbitrary child tables or multi-level relationship graphs. If a custom object has multiple child records per contact (e.g., multiple estate plan beneficiaries), it cannot be represented as a single UDF. Archive it externally and store a lookup reference on the Redtail Contact.
Data-loss zones with no workaround
Household rollups, Financial Account hierarchies, and custom-object child tables have no true 1:1 Redtail destination. FSC groups can roll up financial accounts, goals, events, tasks, assets and liabilities, and referrals. If those rollups drive compliance reporting or client review workflows, design an archive or external reporting solution before go-live. Do not proceed with cutover until stakeholders have signed off on what will not be available in Redtail.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Agree scope, pipeline design and success criteria before touching data.
Objective A scope covering every object in the revenue model, with sales leadership signed up to the pipeline design.
Keep these open
-
Inventory every object in Salesforce Financial Services Cloud
Count accounts, contacts, leads, deals or opportunities, activities, notes, emails, files, products and quotes. Activity and email history is usually the largest object by an order of magnitude and the one people forget to size.
Data Profiler Get real record counts instead of estimating from memory -
Map the current pipeline and agree the target model
Document every pipeline, stage, probability and required field, then agree the Redtail CRM model with sales leadership. Migrating a broken pipeline faithfully is a wasted opportunity; redesigning it mid-migration is a wasted migration.
Stage changes alter historical conversion rates. Agree how you will restate reporting before you change the model.
-
Catalogue integrations and automation
List every system touching Salesforce Financial Services Cloud: marketing automation, quoting, billing, ERP, data enrichment, dialler, BI. Each is a separate cutover task with its own owner, and each can silently write bad data into your new CRM.
-
Capture the reporting that must survive
Interview the people who actually live in the dashboards — forecast, pipeline coverage, rep activity, cohort conversion. Every one of these needs the underlying fields to migrate, which frequently expands the scope.
-
Build the business case and pick the go-live date
Model licence delta, implementation effort and productivity dip. Then choose the date deliberately: mid-quarter is disruptive, quarter-end is worse. Most teams land on the first week of a new quarter.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
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.
-
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.
-
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.
Salesforce Financial Services Cloud → Redtail CRM specifics
- 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.
Don't move on until
- Object counts confirmed for accounts, contacts, deals and activities
- Target pipeline and stage model agreed with sales leadership
- Reporting requirements captured from the people who use the reports
02 Data Audit CRM data is usually dirtier than anyone expects. Find out how dirty.
Objective A profiled export with duplicates, ownership gaps and relationship integrity all quantified and triaged.
Keep these open
-
Export and profile every object
Profile null rates, distinct values and type consistency across all objects. Pay attention to fields sales reps were supposed to fill in: an 80% null rate on a field your forecast depends on is a business finding, not a data one.
Data Profiler Profile the Salesforce Financial Services Cloud export for nulls, outliers and type drift -
Quantify duplicates and agree the merge policy
Measure duplicate accounts (same company, different spellings and suffixes) and contacts (same email, or same person at a renamed company). Agree survivorship rules before merging: which record wins, which fields, and what happens to the activity history on the loser.
Merging before you have agreed survivorship rules destroys history irreversibly. Decide first, merge second.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Verify relationship integrity
Check every deal has a valid account, every contact a valid account, every activity a valid parent. Referential breaks are the defect that turns a clean-looking load into a CRM where the pipeline report does not tie to the account list.
-
Resolve ownership and the user map
Build the Salesforce Financial Services Cloud user → Redtail CRM user map, including leavers. Every record needs a valid owner: records assigned to deactivated users either fail to load or land unassigned, and unassigned pipeline is pipeline nobody works.
Records owned by deactivated users are a top cause of load failures. Decide the reassignment target before you start.
-
Scan for PII and regional compliance
CRMs hold marketing consent, lawful basis and unsubscribe state. Confirm these fields migrate intact and that consent provenance survives — losing consent records is a regulatory problem, not a data-quality one.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Clean, normalise and archive the pre-state
Normalise country and state values, phone formats, currencies and casing, and standardise all timestamps to UTC. Keep an untouched copy of the raw export — it is your only reference if a mapping decision turns out wrong.
-
Audit FSC data
Run SOQL queries to count records by object:
-
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.
Don't move on until
- Duplicate rate quantified per object with a merge policy agreed
- Every record has a valid owner mapped to a target user
- Relationship integrity verified — no orphaned deals or contacts
03 Field Mapping Map objects, relationships and picklists — in that order.
Objective A signed mapping spec that covers objects, relationships, picklist values and currency handling.
Keep these open
-
Map objects and their relationships first
Establish how Salesforce Financial Services Cloud objects correspond to Redtail CRM objects before any field work. Leads-versus-contacts, accounts-versus-organisations and deal hierarchies differ structurally between CRMs, and a field map built on the wrong object model has to be redone.
Schema Mapper Opens pre-loaded with the Salesforce Financial Services Cloud → Redtail CRM field pair -
Generate and then hand-review the field map
Auto-match both schemas, then review every row. Look hardest at anything named "type", "source", "stage" or "status", where names match and meanings do not.
-
Map every picklist value, including retired ones
Enumerate all values on both sides — deal stages, lead sources, industries, statuses — and map each explicitly, including values no longer offered but still present on old records. Unmapped values either fail the row or land as blanks that quietly break segmentation.
Historical records often carry picklist values that were retired years ago and no longer appear in the UI.
-
Decide currency, amount and date handling
If you sell in multiple currencies, confirm how Redtail CRM stores amounts, exchange rates and dated conversion rates. Recalculating historical deal values at today's rate silently rewrites your revenue history.
Multi-currency deals re-converted at current rates will not tie to your historical reporting or your finance system.
-
Determine the load order
Sequence the load so parents exist before children: users, then accounts, then contacts, then deals, then activities and notes. Keep source IDs in custom fields so relationships can be rebuilt by lookup rather than guesswork.
-
Freeze the spec and sign off
Version-control the mapping, walk RevOps and sales leadership through the decisions that change reporting, and get written sign-off before the pilot.
Don't move on until
- Object and relationship model mapped and reviewed
- Every picklist value explicitly mapped, including dead values
- Load order determined so parents always exist before children
04 Test Migration Pilot with related records, not a flat sample.
Objective A pilot load whose relationships, ownership and roll-up reporting all verify against source.
Keep these open
-
Configure the Redtail CRM sandbox to match the agreed model
Build the pipelines, stages, custom fields, record types and user roles first. Load into a default configuration and you will only discover the configuration defects at full scale.
-
Select a connected pilot slice
Take complete account trees — 50-100 accounts with all their contacts, deals, activities and files — rather than a flat random sample. Relationship defects are the whole point of a CRM pilot and a flat sample cannot expose them.
-
Run the load in dependency order with full logging
Load users, accounts, contacts, deals, then activities, logging every request against its source ID. Note which failures are transient (rate limits, timeouts) and which are structural (validation, missing parent).
-
Verify relationships and roll-ups
Confirm every deal sits on the right account with the right owner and stage, and that pipeline totals per account and per rep match Salesforce Financial Services Cloud exactly. Roll-up mismatches almost always mean a relationship or currency defect upstream.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Measure throughput and project the full load
Record actual records-per-hour under Redtail CRM's API limits and extrapolate, remembering activity history usually dominates volume. If the projection exceeds your window, split the load or trim activity scope now.
-
Let reps work the pilot data
Put two or three reps in the sandbox against their own accounts. They spot missing context, wrong owners and unusable notes far faster than any reconciliation script, and their buy-in is what makes adoption work.
Don't move on until
- Relationships intact across the whole pilot slice
- Pipeline roll-ups match source for the pilot accounts
- Reps have worked pilot records and confirmed they are usable
05 Cutover Switch the revenue system with the pipeline intact.
Objective All in-scope CRM data live in Redtail CRM, integrations repointed, and reps selling on day one.
Keep these open
-
Pre-load history ahead of the freeze
Load closed deals, historical activities and inactive accounts while Salesforce Financial Services Cloud stays live. Only open pipeline and the final delta need to move inside the window.
-
Publish the cutover runbook
A timed sequence with owners and abort criteria: freeze, final export, delta load, integration switch, smoke test, go/no-go, rep enablement. Pick a window that avoids quarter-end and month-end close.
-
Freeze Salesforce Financial Services Cloud and take the final delta
Set Salesforce Financial Services Cloud read-only and export everything changed since the pre-load. Reps updating deals during an unenforced freeze is the classic way to lose the most recent — and most valuable — pipeline changes.
A rep who updates a deal in the old CRM during the freeze will lose that update permanently.
-
Load the delta and reconcile the pipeline
Run the delta, then verify open pipeline value and count per rep against Salesforce Financial Services Cloud before anything else. If the pipeline number is wrong on day one, reps stop trusting the system and never fully come back.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint every integration and verify with real records
Switch marketing automation, quoting, billing, enrichment, dialler and BI connections, then push a live record through each path. An unrepointed integration writing into the old CRM causes divergence that gets harder to reconcile every day.
Two-way integrations left pointing at the old CRM will keep writing there. Disable them before you switch, not after.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Go/no-go, then enable the reps
Call the decision explicitly against the exit criteria. Run enablement on real data with their own accounts on screen, and keep Salesforce Financial Services Cloud read-only rather than cancelled until validation closes.
Salesforce Financial Services Cloud → Redtail CRM specifics
- 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.
Don't move on until
- Historical load complete and reconciled before the freeze
- All integrations repointed and verified end to end
- Reps logged in with pipeline visible and correct
06 Validation Prove the revenue numbers tie out, then close the project.
Objective Reconciled data, forecast parity with pre-migration reporting, and signed acceptance.
Keep these open
-
Reconcile every object
Compare counts and values across accounts, contacts, deals, activities and files, plus field-level spot checks on a random sample. Produce a single report suitable for audit and for finance.
Migration Validation Tool Reconcile Salesforce Financial Services Cloud and Redtail CRM record-for-record -
Tie the pipeline and forecast to baseline
Rebuild forecast, pipeline coverage and win-rate reporting and compare to pre-migration figures. Every variance needs an explanation — most trace back to stage or currency mapping decisions made in Field Mapping.
Stage-model changes will legitimately shift historical conversion rates. Restate the baseline rather than chasing the difference as a defect.
-
Verify ownership, visibility and permissions
Confirm every record has the right owner and that sharing rules, territories and role hierarchy give each rep exactly the visibility intended. Over-broad visibility in a CRM is a data-protection issue as much as a config one.
-
Re-profile for field completeness
Compare loaded null rates against the source profile per field. A field that arrived empty while counts matched is the failure counts alone cannot detect.
Data Profiler Prove field completeness held up through the load -
Test automation and integration write-back
Fire every workflow, assignment rule, sequence and notification, and confirm each integration writes correctly in both directions. Automation is rebuilt rather than migrated, so it is unproven until observed.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, keep Salesforce Financial Services Cloud read-only for 30-90 days with a final archive export taken, then diarise cancellation so the contract does not auto-renew.
-
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.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
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.
Salesforce Financial Services Cloud → Redtail CRM specifics
- 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.
Don't move on until
- Full reconciliation report complete across all objects
- Forecast and pipeline reports tie to pre-migration baselines
- Acceptance signed and Salesforce Financial Services Cloud decommission scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Salesforce FSC Redtail CRM
| Salesforce Financial Services Cloud field | Redtail CRM field | Notes |
|---|---|---|
| Person Account (FirstName, LastName) | Contact (first_name, last_name) | Direct map. Strip the Account portion. |
| Person Account.PersonEmail | Contact.email | Map primary email only; Redtail supports one primary |
| Person Account.Phone | Contact.phone | Map to primary phone |
| Person Account.PersonMailingAddress | Contact.addresses [] | Map street, city, state, zip |
| Household Account.Name | Family Name | Create household, then link contacts |
| ACR (Account-Contact Relationship) | Household member link | Flatten — set household_id on each contact |
| Contact-Contact Relationship | Family group member | Map relationship type (spouse, child, etc.) |
| Lead.Status | Contact.Status (Prospect category) | Redtail has no separate Lead object; map to Contact with specific Status and Category |
| Opportunity.Name, Amount, StageName | Opportunity (name, value, status) | Redtail's opportunity stages are simpler — map or merge |
| Task.Subject, Status, ActivityDate | Activity (subject, type, date) | Map Task to Activity; set activity_type from Redtail lookup |
| Event.Subject, StartDateTime | Activity (subject, date) | Merge Events into Activities; preserve datetime |
| ContentNote / Note.Body | Note (body, note_type) | Attach to contact_id; notes are append-only in Redtail |
| FinServ__FinancialAccount__c | Account (manual tracking) | Redtail's account object is limited — expect significant data loss |
| FinServ__FinancialAccount__c.Balance__c | Account Value | Linked to specific Contact; no historical balance tracking |
| Custom Object fields | UDF (User Defined Field) | Create UDFs manually in Redtail UI first, then write via API |
| Campaigns, Cases | No equivalent | Archive or exclude from migration |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Contacts (Person Accounts) | medium | Person Account records map reasonably well to Redtail Contacts at the field level, but the FSC Person Account is a merged Account-Contact object, so extractors must correctly identify IsPersonAccount = true records and avoid conflating them with business or household Account records. |
| Households | high | The FSC household model relies on ACR junction objects that have no Redtail equivalent, meaning household membership and relationships must be entirely reconstructed in the transform layer or household structure will be silently lost during migration. |
| Notes | high | FSC distributes notes across ContentNote, Enhanced Notes, and legacy Note objects with varying attribution models, while Redtail's Notes are append-only and cannot be patched after creation, making it impossible to correct errors or preserve original authorship metadata post-load. |
| Activities (Tasks and Events) | high | FSC Tasks and Events are separate objects with distinct schemas and compliance implications, while Redtail merges all activities into a single object differentiated by Type and Category fields, requiring careful normalization to avoid orphaning advisor-critical compliance activity records. |
| Opportunities | medium | FSC Opportunities support multi-stage pipelines and custom FSC-specific fields that Redtail's simplified flat Opportunity object cannot accommodate, requiring field consolidation decisions that may result in pipeline stage history being lost or collapsed. |
| Financial Accounts | high | Redtail has no equivalent for FSC's FinServ__FinancialAccount__c object with its holdings and transaction history, meaning all financial account detail will be lost from the CRM unless it is archived to an external system prior to migration. |
| Custom Objects and Fields | high | Salesforce FSC supports unlimited custom objects with no Redtail equivalent, and UDFs must be manually created in the Redtail UI before migration begins since they cannot be provisioned programmatically, making pre-migration setup a hard dependency for any custom field data. |
| Relationships (ACR, AAR, CCR) | high | FSC's three distinct relationship junction objects (Account-Contact, Account-Account, Contact-Contact) model complex advisor-client and household webs that Redtail can only approximate through family group links on contact records, with no guaranteed one-to-one mapping fidelity. |
| Picklist and Lookup Values | medium | FSC picklist values are fully customizable and may not align with Redtail's fixed lookup tables, requiring every FSC picklist value to be manually mapped to a Redtail category equivalent before migration begins or data will fail validation on load. |
| Email Attachments and Documents | medium | FSC stores files and email attachments via ContentDocument and ContentVersion objects linked through ContentDocumentLink, while Redtail's document handling is limited, meaning document migration scope must be explicitly defined and compliance-critical attachments may require external archival rather than CRM migration. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Household Structure Reconstruction
FSC models households as Business Account records linked to Person Accounts via ACR junction objects, while Redtail treats households as a flat grouping label directly on the contact record, requiring custom transform logic to reconstruct household membership and relationships without a native junction equivalent.
No Self-Service CSV Import
Redtail does not support self-service CSV imports; all file-based imports must be submitted to Redtail's support team via email, removing control over field mapping and error handling, and introducing 3–10 business day turnaround delays that make iterative testing impractical.
Single-Record API Write Constraint
Redtail's REST API v1 has no batch or array endpoint for bulk record creation, requiring every contact, note, and activity to be written in a separate HTTP call, which — combined with observed throttling at 60–80 requests per minute — dramatically limits load throughput for large datasets.
Custom Objects Have No Target
FSC supports unlimited custom objects and fields, while Redtail only offers User Defined Fields (UDFs) and categories, meaning all custom object data must be either mapped to UDFs, archived externally, or formally abandoned before migration can proceed.
Note and Activity Model Incompatibility
FSC stores notes across multiple objects (ContentNote, Enhanced Notes, legacy Note) and separates activities into Tasks and Events, while Redtail consolidates everything into a single append-only Notes object and a unified Activity object, requiring normalization logic and making retroactive edits impossible post-load.
Financial Account Data Loss
FSC's FinServ__FinancialAccount__c object supports holdings, transactions, and account roles, none of which have equivalent fields in Redtail's manually tracked account structure, meaning all financial account detail must be archived outside of Redtail rather than migrated.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I import CSV files directly into Redtail CRM?
No. Redtail does not offer self-service CSV import. You must email CSV files to Redtail's customer service team for processing, and you have no control over field mapping or error handling. Notes, activities, and opportunities cannot be imported via this channel. For programmatic import, use the Redtail REST API.
What data will I lose migrating from Salesforce FSC to Redtail?
You will lose custom object structure (Redtail has no custom objects), financial account holdings and transaction detail, multi-household membership (Redtail allows one per contact), Apex/Flow automations, and Salesforce reporting depth. Household rollup behavior also has no Redtail equivalent. Archive critical data before migration.
What are Redtail CRM API rate limits?
Redtail doesn't publish official rate limits, but throttling typically starts around 60–80 requests per minute. Add 150–200ms delays between bulk requests and implement exponential backoff for HTTP 429 responses. For a firm with 5,000 contacts and full history, the load phase alone takes approximately 10 hours.
How do Salesforce FSC Households map to Redtail?
FSC uses Household Accounts linked to Person Accounts via Account-Contact Relationship (ACR) junction objects. Redtail uses simple household labels on contact records. You must flatten the ACR relationships into direct household assignments on each contact. Multi-household membership in FSC must be reduced to a single household in Redtail.
Does Redtail CRM support custom objects from Salesforce?
No. Redtail has no custom object support. You must map Salesforce custom object data into Redtail User Defined Fields (UDFs) on the contact or account record, concatenate it into formatted notes, or archive it outside the CRM. UDF definitions must be created manually in the Redtail UI before you can write to them via API.