A Redtail export looks complete right up until you try to load it. Households are a link, not a record. Email lives somewhere else entirely. The notes are HTML soup. This page walks through exactly how I move a Redtail practice into FSC: what breaks, how each piece gets rebuilt, and what you get to keep at the end.
Already working with me? Your four Redtail action items, with screenshots →
You’ve outgrown Redtail, or your broker-dealer or custodian relationships are pulling you toward Salesforce. The whole book has to come with you, households and history included, and the advisors need it to work on day one.
Your org is already on FSC and the acquired practice isn’t. Their clients have to land in your structure, matched against the clients you already have, while the selling advisor watches closely. How acquisition migrations work →
Your team is implementing FSC and the Redtail workstream needs a lead who has done it before. I slot in under your project plan. Migration lead for partners →
If FSC isn’t the right destination for your size, I’ll tell you on the first call. What FSC needs from your data →
None of these are exotic. They show up in every Redtail migration I’ve run. The difference between a smooth move and a six-month cleanup is whether someone planned for them before the first record loaded.
Redtail groups people into families, but FSC needs a real household account with members, roles and a primary contact. Some families in the export are complete. Some are a husband with no wife attached. Some are two households that share a last name and nothing else.
What I do: rebuild households from the family links plus address, email and naming signals, and hand your team a review file. Nothing becomes a household in Salesforce until someone at your firm has approved it.
Redtail’s email history isn’t in the standard export. It comes as its own archive, through its own request and its own download, and it’s the piece that most often gets forgotten until an advisor asks where ten years of correspondence went.
What I do: request it at kickoff, so it’s on its way while the rest of the work starts. Then I match it to the right person and household in Salesforce. (How to request the email archive)
Years of notes come out wrapped in markup: tags, styling fragments, encoded characters. Load them as they are and every note in Salesforce reads like a web page that fell down the stairs.
What I do: clean them into readable text that keeps the paragraphs, the author and the original date. Then I attach each one to the right person and household.
Recurring review meetings, task owners, and which advisor “has” which client don’t come through cleanly. Redtail users have to become Salesforce users, and recurring activities have to be rebuilt rather than copied.
What I do: map every Redtail user to a Salesforce owner before load, using a user list your team pulls from Redtail (how to locate Redtail User Ids). Then I decide with you which history comes over as completed activity and which recurring work gets set up fresh.
Client documents live in Redtail’s Imaging account, not in the data backup. They come as their own export, organized in a way that made sense inside Redtail and nowhere else, and have to be tied back to the right client before they mean anything in Salesforce.
What I do: flatten and index the folders into a load sheet that links each file to its client. The original folders are never renamed, moved or touched. (How to request the documents archive)
The same client entered twice by two advisors, a maiden name and a married name, a trust listed as a person. Businesses, trusts and people also sit in one contact list, and FSC needs them separated.
What I do: find duplicates inside the export, and against your org if it already holds clients. You get a merge file to approve. Nothing merges on my say-so alone.
Doing this for your firm? The client checklist walks through all four requests step by step, with screenshots and an email you can copy to Redtail support.
Getting your data out of Redtail takes three requests, not one: the database backup, the documents archive and the email archive. Send them all on the same day and nothing holds up the start of the migration.
Someone on your team with Redtail administrator permissions requests a database backup from inside Redtail. Redtail’s Database Backups article →
It’s a quick turnaround, usually within an hour. The backup arrives as a single .sql file. Send it to me as it arrives. Don’t open it, convert it or tidy it up first.
Redtail calls its document storage Imaging, and it isn’t part of the data backup. The backup includes a Documents table that references your files, but the files themselves live in the Imaging account. They need their own backup, requested from Redtail support.
Without it, Salesforce gets a list of documents with nothing attached. Step by step, below →
Stuck? Email support@redtailtechnology.com and ask how to request a backup of your Imaging account. If you acquired the practice, the selling firm’s Redtail administrator makes both requests, and I’ll give them this same checklist at kickoff.
Every record in the backup says who created it, using a numeric user id. The added_by field is one example. But the backup doesn’t include a users table, so on its own, 48213 is just a number.
Redtail support has confirmed that the only way to get these ids is to copy them by hand from the User Management screen. Do it on the same day the backup is requested, so the list matches the data exactly, before anyone is added, disabled or renamed.
For each user, record:
| User Id | First Name | Last Name | Username | Status | |
|---|---|---|---|---|---|
| 5-digit id | Active or Disabled |
What I do with it: every Redtail user id gets mapped to a Salesforce user before anything loads. That might be the same person’s new login, an active user who takes over a departed advisor’s clients, or an inactive user record that preserves who did what. Either way, “created by” and ownership history land on a real name instead of a number.
Redtail keeps attached documents in a separate storage system it calls Imaging (support cases call it Document Storage). The database backup has a Documents table listing every file, but not the files themselves. Those come from Redtail support, as their own archive.
Every document your team ever attached in Redtail: PDFs, spreadsheets, scanned forms. They’re organized the way Redtail stored them, which made sense inside Redtail and nowhere else.
That link lives in the database backup’s Documents table, not in the archive. The two backups only make sense together, which is why this request goes out the same day as the database backup.
What I do with it: I match every file to its row in the Documents table, and through that to the right client. Then I build a load sheet that attaches each document to the person and household in Salesforce. The archive itself is read-only: nothing in it is renamed, moved or deleted, and the file count in matches the file count out.
Redtail email runs on its own mail system, separate from the CRM. That means it’s not in the database backup and not in the Imaging backup. It’s a third request with its own download, and it’s the part most likely to eat a week if nobody planned for it.
Unzipped, every email is its own .eml file, organized into a folder per mailbox, with attachments inside each message. Expect a lot of files: one mailbox folder in a recent migration held more than 400,000.
An email export from most systems comes with a key: a list of every message with its date, sender, recipients and subject. Redtail’s doesn’t. Without one, nobody can tell which client an email belongs to without opening it.
What I do with it: I build the missing index by reading each message’s headers (date, sender, recipients, subject, attachments) into a workbook your team can review. Then I match the addresses to clients in Salesforce. Your compliance team decides which messages load into Salesforce on the right person and household, and which stay in a compliance archive. Either way, timestamps, senders, recipients and attachments come through intact. Your books-and-records obligations don’t end at cutover.
Every Redtail migration goes through the same seven steps. Each one produces a file your team can open, question and approve, so you can see the work instead of taking my word for it.
Every table in the backup is counted and profiled: what’s there, how it connects, what’s missing. This is where the gap report comes from, and where the fixed fee gets set.
People and businesses are separated and every contact is mapped into the shape FSC expects: person accounts, business accounts, and the details that go with each.
The incoming clients are matched against the clients you already have, so an acquired book doesn’t arrive as 4,000 new duplicates. Every match you’d want a human to look at goes to your team for a decision.
Duplicates inside the Redtail export are grouped, with the evidence for each group shown, and your team approves the merges.
Every Redtail field is mapped to its FSC destination, with transformation rules and picklist translations, reviewed by your team before anything is built.
Households, people, relationships, financial accounts, activities, notes and documents become load-ready files in dependency order, so parent records always exist before their children.
Sandbox first, then production. Every object is counted in and counted out, and anything that didn’t load is explained, not just logged.
The clock starts when the Redtail data arrives, not when the contract is signed. Multi-office books, a large document archive or a Salesforce org that isn’t ready yet get their own schedule in the gap report.
The Redtail data backup and Imaging backup requests go out, along with the separate email archive. We agree on the FSC data model and who at your firm approves what.
Source analysis, contact mapping and the gap report. You know what’s in the export and what isn’t before anything else happens.
Households, dedupe, cross-match, field mapping and load files. Your team reviews and approves each file. The sandbox load is tested end to end.
Production load in dependency order, the reconciliation report, and a delta load for anything that changed in Redtail while we worked.
Advisors find their clients, households, notes and email in Salesforce. A 30-day fix window covers anything that surfaces once real people start using it.
Most migrations hand over a Salesforce org and a goodbye. You get the org and every file that went into building it, which matters when your CCO, an examiner or your next admin asks how the data got there.
They’re watching whether you treat thirty years of client history as an asset or a data dump. That’s usually the real reason an acquisition migration stalls, and it’s why the notes, the email and the households matter as much as the contact records.
Every month the acquired book sits in Redtail, advisors work two systems and the compliance trail is split across two vendors. Meanwhile the acquired clients are deciding whether this merger was done for them or to them.
What your export will contain, what it won’t, how your households should land in FSC, and a fixed fee once I’ve seen the data.
