On moving a firm's memory
When a wealth-management firm changes systems, twenty years of client history changes hands. Every household, every note from every review meeting, every relationship that explains why the book looks the way it does. Most migrations treat that as a data-entry problem. We treat it as custody.
Migrations rarely fail loudly. The load finishes, the row counts look plausible, the project closes, and everyone moves on. The failure surfaces later, in fragments: a household that arrives split in two, a client whose decade of meeting notes simply isn't there, a referral relationship nobody can reconstruct. By then the old system is dark and the people who knew its quirks are gone.
We have spent years inside these projects, on both the rescue end and the right end. The failure modes are not exotic. They are the same four, every time.
Head-of-household logic that lived in the old system's quirks doesn't survive a flat export. Spouses arrive as strangers. A dependent becomes the primary. The org chart of a family, rebuilt wrong, in front of the people it describes.
Notes, tasks, and workflow history get descoped because they're "too messy to map." The new CRM opens clean and empty, like a house with no photographs, and every advisor starts their relationships over from zero.
We once audited a draft migration in which a single leftover WHERE clause quietly excluded every contact who had a servicing advisor. Which is to say: most of the book. Nothing errored. Every report looked fine. That is the texture of how these projects go wrong — not crashes, omissions.
Ownership mapping gets deferred until the deadline, and then every account belongs to the admin who ran the load. Six months of "wait, who covers this household?" follows, billed in advisor hours.
Nobody notices a migration failing. They notice it failed — months later, mid-meeting, with the client on the other side of the desk.
After enough of these engagements, we stopped improvising and built Monarch — named for the only migration in nature that reliably arrives. It is not an ETL tool and not an integration platform. It is purpose-built for the one-time, high-stakes move.
Monarch doesn't move data in bulk and hope. It moves records one at a time, and writes down what happened to each one: inserted, updated, failed and why, deliberately skipped and why. The ledger lives in its own database, beside the run, for as long as you want to keep it.
Because the ledger is the source of truth, re-runs are boring — successes are skipped, failures are retried, and nothing is ever loaded twice. A migration stops being a weekend of held breath and becomes a process you can interrogate.
The number that matters is the last one. At any moment, on any run, every source record is either loaded, failed with a written reason, or deliberately excluded with a written reason. "Unaccounted for" is structurally zero.
A complete export of the source system before any decisions are made. No filtering, no transformation. The raw history is preserved and queryable for the life of the project.
What goes, what stays, and how records relate — modeled explicitly in SQL, reviewed with your team. Scope changes ripple through the whole graph instead of hiding in someone's spreadsheet.
Every field mapping and value translation is an explicit, typed rule. When a rule is wrong, it fails on a named record with a named reason — not somewhere in a 40,000-row CSV.
Bulk loads with record-level accounting. Migrations have no transactions and no rollback, so resumability is engineered in — a failed batch is a fact in the ledger, not a crisis.
Two details we consider non-negotiable. Rehearsal: every pipeline runs in dry-run mode, then against a sandbox, then production — identical code, three dress rehearsals, with your team clicking through real converted data before go-live. The thread back: every record we create is stamped with a durable ID tying it to the source row it used to be. Years from now, an auditor can pick any account and walk it home.
Every source system has its own dialect — how it models households, where it hides the spouse, what it does to a note when nobody's looking. Our work spans CRMs, Salesforce orgs, document platforms, and cloud data handoffs; the pattern is always the same: make the route explicit, then account for every record.
Folding an acquired firm's book into your live org without disturbing the org. One client environment we work in carries forty-nine prior acquisitions; each migration lands as a clean, stamped, auditable layer.
Multiple systems, multiple data dialects, one target. The hard part is not the loading — it's reconciling three different opinions about what a household is.
A new Financial Services Cloud org, modeled correctly from day one — person accounts, household relationships, reciprocal roles — with your history arriving intact on opening day.
Moving the file layer — statements, agreements, correspondence — out of Salesforce into SharePoint or Egnyte, with every attachment's parentage preserved.
Loaded, failed with a reason, or excluded with a reason. There is no fourth category, and there is never a record nobody can speak for.
A contact list is trivial to move. Households, spouses, trusted contacts, attorney and CPA networks, advisor teams — that web is the actual asset, and it's where we spend our care.
Meeting notes, tasks, workflows, emails — the texture of a twenty-year relationship. "Too messy to migrate" usually means "nobody built the tooling." We built the tooling.
Dry run, sandbox, production: the same pipeline, three times, with your team reviewing real converted data in between. Go-live should be the least interesting day of the project.
Data keeps changing while you cut over. We run delta loads for what moved during the transition and stay through hypercare until the questions stop coming.
Every engagement ends with a structured retrospective that feeds our per-system playbooks and the framework itself. You are never our first time on the route.
Full raw export, loaded into an analytical workspace. We learn your data's actual shape — not the vendor's documentation of it — before anyone maps a field.
Working sessions with the people who use the system. Every field gets a destination, or a documented reason it stays behind. Decisions are recorded, not remembered.
Dry runs, then sandbox loads of the full book. Your advisors click through their own clients in the new system and tell us what's wrong while it's still cheap to fix.
The production run, with the ledger live and every record accounted for in real time. By this point the pipeline has already made the trip without incident, twice.
Whatever changed in the old system during cutover follows the same tracked path. We stay until the new system is simply the system.
Callaway Cloud · Migrations Practice
Tell us what you're moving from, and what's at stake in the move. We'll start consulting in the first conversation — including telling you honestly what your data will and won't survive.
Jackson Hole, Wyoming ◊ 307.200.7224 ◊ Salesforce partner since 2012