Firms that acquire practices, firms moving to Financial Services Cloud, and Salesforce partners who need someone to own the data. Pick the one that sounds like you. Each opens in a new tab.
You close two, four, six deals a year, and every one arrives with a different CRM, different household logic and a decade of notes. I bring each one into your Salesforce the same way every time, so your team isn’t relearning the process with every acquisition.
See the Acquisition Data Migration offer ↗ 02 · FSCFSC isn’t Sales Cloud with a nicer logo. Households, relationship groups, financial accounts and roles have to be modeled before a single record loads. I do FSC migrations specifically, not “Salesforce migrations that happen to be FSC.”
See the FSC migration service ↗ 03 · PARTNERSYour team is great at build. Nobody wants to own the data. I slot into your implementation as the migration lead, work under your SOW or mine, and hand your client a clean org on go-live day.
See how I work with partners ↗Not one of the three? I also do standalone migrations into Salesforce and FSC from any source: legacy orgs, org-to-org consolidations, SQL and Access databases, spreadsheets. Book a call →
This is the part that took years. Not a project plan on a slide: a sequence where every step produces a real artifact your team reviews and keeps, and where nothing moves forward until the step before it reconciles. It runs the same way whether you’re absorbing an acquired book, moving to FSC, or handing me the data workstream on your own implementation.
Every table, every column, every record count in the source system, mapped before anyone talks about Salesforce fields. This is where we find out what the export actually contains, rather than what the vendor’s brochure says it contains.
People split from businesses, trusts and entities identified, every lookup code resolved to the thing it actually means. Get this wrong and every household, relationship and rollup built on top of it is wrong too.
Before anything loads, every incoming contact is matched against what you already have and given a disposition: new, match, possible match, type mismatch. Your team adjudicates the ambiguous ones. This is the step that prevents the thousands of duplicates that make people distrust a new org.
Duplicates inside the source itself, clustered and scored, with the survivor logic applied consistently instead of advisor by advisor. You review the clusters; I don’t merge anything you haven’t seen.
Every source field to a target field, or a documented decision not to migrate it. Picklist mismatches surfaced and resolved before load, not discovered during it. This is the document your admin inherits and the one that makes the org explainable a year later.
Load-ready files generated in strict dependency order — parents before children, batched to avoid row locks — and client documents and attachments prepared to land on the right record rather than in a folder called “Old CRM.”
Sandbox first, then production. Record counts matched, spot checks run, and a delta load for anything that changed while the migration was in flight. Then I stay on through the first week, because the real bugs show up when advisors start clicking.
The work is done by deterministic scripts that run locally against your extract, read-only, making no network calls. Client records are never pasted into a chatbot, never uploaded to an AI vendor, and never leave your machine or your org. Anything that does travel carries masked identifiers. Your CCO can be told exactly where the data went, because the answer is “nowhere.”
“3,412 in, 3,412 out, 0 duplicates, 0 dropped.” Every file that later steps depend on gets checked before and after it changes, and a check that doesn’t balance stops the migration rather than quietly passing a broken file downstream. You see that line, not just the finished workbook.
Which export was authoritative, how type mismatches were adjudicated, which target data model we chose and why — recorded in a decision register with the numbers that justified each one. It’s what makes the project resumable weeks later, and it means the migration isn’t living only in my head.
One fixed-fee engagement that takes an acquired practice from “here’s their Redtail export” to “their clients are in our Salesforce and the advisors are using it.”
Most firms handle each acquisition like it’s the first one: a scramble, a spreadsheet, a consultant billing by the hour, and a quiet decision three months later to just not migrate the notes. I’ve done this enough times that it’s a repeatable process with reusable tooling, which is why I can scope it, price it once, and finish it faster than an hourly engagement would.
Fixed fee, scoped after a 30-minute call.
What it’ll take, what it’ll cost, and whether you even need me. Sometimes you don’t.
