Data Migration for RIAs: Moving CRM, Custodian & Portfolio Data Without Breaking Everything

Data migration is one of the highest-risk operations an RIA undertakes. Whether you're switching CRMs, moving custodians, integrating an acquired firm, or consolidating legacy systems, the same failure modes appear: lost client history, broken account relationships, compliance gaps, and timelines that stretch far beyond the original estimate.

When RIAs Need to Migrate Data

Most RIAs encounter at least one major data migration every three to five years. The trigger is usually a technology change, a business event, or accumulated technical debt that finally demands resolution.

Switching CRM Platforms

The most common migration scenario. A firm moves from Redtail to Salesforce, from Wealthbox to Redtail, or from a custom-built system to any commercial platform. The challenge is that every CRM stores relationship data differently. Redtail organizes data around households with specific relationship types. Salesforce models the same data as accounts and contacts with custom objects. What maps neatly in concept often requires weeks of field-by-field reconciliation in practice — and interaction history, meeting notes, and activity logs rarely survive cleanly.

Changing Custodians

The TD Ameritrade-to-Schwab transition affected thousands of RIAs simultaneously and illustrated how dependent advisory operations are on custodian data infrastructure. When an RIA changes custodians voluntarily — moving from Pershing to Fidelity, for example — the challenge is not just moving client assets (handled through ACAT transfers) but migrating the data infrastructure that sits on top: performance history, tax lot records, cost basis data, fee billing configurations, and reporting relationships. New custodian portals do not import history from the previous custodian. That data has to come from the firm's own records.

Post-Acquisition Integration

When a larger RIA acquires a smaller one, both firms arrive with their own CRM, their own custodians, their own portfolio management system, and their own data conventions. The acquiring firm needs to integrate the acquired firm's client data — but usually cannot afford to disrupt operations at either firm during the transition. This is the most complex migration scenario in the industry, and it is becoming more common as consolidation accelerates.

Consolidating Legacy Systems

Many firms built data infrastructure over decades: a CRM from 2010, a portfolio system from 2015, a reporting tool added in 2019, and a collection of spreadsheets bridging the gaps. Consolidating these into a modern stack requires migrating data from each system, reconciling conflicting records across them, and preserving historical data that may not have a clean destination in the new system.

Moving to a Data Warehouse

An increasing number of RIAs are moving data into centralized Snowflake or BigQuery warehouses to support analytics, AI, and custom reporting. This migration does not replace source systems — it complements them. But it still requires extracting, transforming, and loading data from every integrated system, establishing a normalized schema, and maintaining ongoing synchronization as source systems continue to change.

What Makes RIA Data Migration Hard

Financial services data migration is harder than most technology migrations because the data is both deeply relational and legally significant. Losing a customer record in a retail e-commerce platform is inconvenient. Losing it in an RIA is a compliance violation and a client relationship failure simultaneously.

Client History Is Irreplaceable

A client relationship accumulates years of meeting notes, interaction logs, financial plan versions, risk tolerance updates, and communication records. This history exists in the CRM as a mix of structured fields and free-text entries. Structured fields — phone numbers, addresses, account numbers — can be mapped relatively cleanly. Free-text notes are unpredictable in length, format, and content. They reference people, accounts, and events by name rather than by system ID. A migration that exports notes as blobs and re-imports them loses the relationship context that made those notes useful.

Account Relationships Are Complex

RIA data models are built around households — the organizational unit that groups related clients, accounts, and relationships under a single advisory relationship. Household structures include: the primary client, co-clients and dependents, related entities (trusts, LLCs, foundations), linked accounts across custodians, and advisor-of-record and team assignments. Each system implements household structures differently. When you migrate, every relationship in the source system must be explicitly mapped to the target system's relationship model. Missing even a fraction of these links creates orphaned accounts — accounts that exist in the new system but have no household, no advisor, and no client to connect them to.

Compliance Records Cannot Be Lost

SEC-registered RIAs are required to retain books and records under Rule 204-2 of the Investment Advisers Act. This includes correspondence with clients, trade records, client agreements, supervisory procedures, and financial statements. Some records must be retained for five years; others for the life of the firm. A migration that destroys or renders inaccessible any of these records creates regulatory exposure. The safest approach is to maintain read access to legacy systems for the full retention period while migrating operational data to new systems.

Active Integrations Break When You Move

Modern RIA technology stacks are deeply integrated. The CRM feeds the portfolio system. The portfolio system feeds the financial planning tool. The billing system pulls from both. When you migrate the CRM, every downstream integration breaks until it is reconfigured against the new system. Firms frequently underestimate how many integrations they have — and discover additional ones during migration when things stop working unexpectedly.

Migration Exposes Hidden Data Quality Problems

The source system looks clean until you try to move it. Then you discover: duplicate client records created by different advisors over the years, account numbers that reference custodians the firm no longer uses, email addresses that no longer exist, household structures that were never consistently maintained, and custom fields filled with inconsistent or free-form values. Every data quality problem in the source system becomes a migration blocker or a manual cleanup task. The audit phase of a migration almost always reveals more problems than expected.

The 6-Step RIA Data Migration Framework

Successful RIA data migrations follow a structured process. Firms that skip steps — typically to save time — consistently experience the most disruption. The steps are not bureaucratic overhead; they are where the actual migration problems get caught before they affect clients.

Audit Current Data

Before writing a single mapping rule, understand what you actually have. Export the source system and profile every field: completeness rates, value distributions, duplicate records, orphaned relationships, and referential integrity violations. This audit will surface every hidden data quality problem that would otherwise appear mid-migration. Plan two to three weeks for a thorough audit of a typical mid-size RIA CRM with 500 to 2,000 clients.

Define the Target Schema

Document exactly how data will be organized in the target system. For a CRM migration, this means defining the object model (how households, contacts, accounts, and relationships will be structured), required fields, field types, validation rules, and naming conventions. For a data warehouse migration, this means the table schema, primary keys, foreign key relationships, and normalization logic. The target schema is the specification against which all mapping work is validated.

Build Mapping Rules

For every field in the source system, document exactly where it goes in the target system and what transformation (if any) is required. Many fields are direct copies. Others require transformation: date format conversion, value normalization (standardizing state abbreviations, for example), concatenation of multiple fields into one, or splitting a single field into multiple. Some source fields have no target equivalent and must be stored as notes, custom fields, or archived separately. Document every decision.

Test Migration on a Subset

Run a full migration against a representative sample — typically 10 to 20 percent of records, chosen to include the most complex households, the most active accounts, and the longest-tenured clients. Validate the output against source data manually for every record in the sample. This step will reveal mapping errors, transformation failures, encoding issues, relationship reconstruction problems, and integration breaks that would otherwise only appear after migrating the entire dataset.

Execute with a Rollback Plan

The full migration should have a defined cutover window (typically a weekend), a freeze date after which no new data enters the source system, and an explicit rollback plan specifying what triggers a rollback, who makes that decision, and how long parallel operation continues before the legacy system is decommissioned. Compress the migration window as much as possible — the longer both systems are running simultaneously, the more data synchronization complexity accumulates.

Validate and Reconcile Post-Migration

Compare record counts between source and target: total clients, total accounts, total transactions, total notes. Identify any records that failed to migrate and investigate each one. Run validation queries against the target system to verify relationship integrity — every account should have a household, every household should have an advisor, every client should have valid contact information. Plan at least two weeks of parallel operation during which the legacy system remains accessible and staff can verify data against it before relying solely on the new system.

Migration Pitfalls That Cost Firms Most

Every RIA data migration fails in one of the same ways. Knowing the failure modes in advance is the most reliable way to avoid them.

Common Migration Failures

Losing historical data — Interaction logs, meeting notes, and document links that don't map to target fields are silently dropped. Advisors notice months later when client history is missing.
Breaking household relationships — Household structures that existed in the source system don't survive migration because the target system models them differently and no explicit mapping was defined.
Orphaned accounts — Accounts that migrate successfully but arrive without an advisor assignment, household link, or client connection. They exist in the system but can't be found or operated on normally.
Duplicate records — Source system duplicates that were tolerable before migration create confusion and operational problems when both copies arrive in the new system.
Compliance gaps during transition — The cutover period between systems creates a window where new activity is being recorded in the new system while historical records are only in the legacy system. If the legacy system is decommissioned before the retention period expires, compliance records are lost.
Underestimating timeline — Most RIA data migrations take two to three times longer than originally estimated. The audit and data quality remediation phases alone routinely consume half the migration timeline.
Integration cascade failures — Cutting over the CRM without mapping and testing every downstream integration first results in billing errors, portfolio system data gaps, and reporting failures that take weeks to resolve.

The Data Platform Alternative to Traditional Migration

Traditional data migration asks: how do we move data from system A to system B without losing anything? The data platform approach asks a different question: what if we didn't have to move the data at all?

Traditional Migration Approach

Move data out of old system and into new one

Source system decommissioned after cutover

All-or-nothing cutover creates maximum disruption risk

Historical data must be transformed to fit new system schema

Every integration must be rebuilt for new system

Data Platform Approach

Connect all systems to a central data warehouse — old and new

Source systems keep running; data unified in Snowflake

Migrate individual systems on your schedule, or not at all

Historical data preserved in source system; normalized in warehouse

Analytics and reporting continue uninterrupted throughout any system change

Instead of migrating data from systems, a data platform connects systems to a central Snowflake warehouse. The Milemarker platform maintains live connections to 130+ integrations — CRMs, custodians, portfolio systems, planning tools, and operational applications — and normalizes their data into a unified wealth management data model.

When a firm is migrating from Redtail to Salesforce, Milemarker connects to both. Redtail data flows in during the legacy period. Salesforce data flows in after the transition. From the analytics and reporting layer, the migration is invisible — all client history, account relationships, and activity data continues to be available in a consistent schema regardless of which CRM is the system of record at any given moment.

The key insight: a data platform does not eliminate the need to migrate operational systems. It eliminates the risk. Your CRM migration can happen on your schedule, with a proper rollback plan, without any impact on your analytics, reporting, or compliance data infrastructure — because none of those depend on the CRM migration succeeding cleanly.

Post-Acquisition Migration: The Most Complex Scenario

RIA acquisition activity has accelerated significantly over the past decade. Acquirers frequently discover that the technology and data integration work following a deal is more complex and time-consuming than the deal itself. The acquired firm has a different CRM, different custodians, a different portfolio management system, and years of data organized according to different conventions. Forcing an immediate migration creates disruption for the acquired firm's clients and advisors at exactly the moment when retention is most critical.

The Integration Sequence That Works

The most successful post-acquisition integrations follow a deliberate sequence:

Week 1-4 — Connect everything to the data platform. Connect the acquired firm's CRM, custodians, and portfolio system to the central data warehouse alongside the acquiring firm's systems. This establishes a unified view of all clients and assets within weeks, even before any system migration occurs.
Month 2-3 — Normalize and reconcile. Identify duplicate clients across both firms (cross-firm household overlaps are common in local markets), reconcile account relationships, and establish a normalized client identifier that works across all connected systems.
Month 3-6 — Migrate custodians. Move the acquired firm's client assets to the acquiring firm's preferred custodians if the deal economics require it. This is operationally disruptive for clients; the data platform ensures reporting continuity before and after the custodian change.
Month 6-18 — Migrate the CRM. Move the acquired firm's CRM data into the acquiring firm's CRM on a deliberate, validated schedule. With the data platform already connected to both CRMs, historical data is preserved throughout the transition.
Month 12-24 — Consolidate portfolio systems. Portfolio system migrations are the most technically complex. With a data platform in place, the timing is flexible — consolidate when it is operationally convenient, not when the deal forces it.

This sequence decouples business continuity from migration timeline. The acquiring firm gets a unified view of all client data within the first month — long before any system migration is complete. Individual migrations then proceed at a pace that minimizes operational disruption rather than the pace dictated by integration complexity.

What Acquirers Consistently Underestimate

The three things acquirers consistently underestimate in post-acquisition data integration:

Data quality in the acquired firm's systems. The acquired firm's CRM looks clean from the outside. Inside, it has the same years of accumulated inconsistencies every CRM accumulates. Budget for substantial data remediation work.
The complexity of household mapping across firms. Matching a client in firm A's CRM to the same client in firm B's CRM requires probabilistic name matching, address matching, and manual review. It is not an automated process.
Staff retraining time. Acquired firm advisors who have used their CRM for ten years will resist migrating to a new system. The technology integration timeline should account for training and adoption work, not just data migration work.

Frequently Asked Questions

How long does a typical RIA data migration take?

A straightforward CRM migration with clean source data can take 4 to 8 weeks. A custodian transition like TD to Schwab typically takes 3 to 6 months when accounting for data mapping, testing, and reconciliation. Post-acquisition integration involving multiple systems at two firms can take 12 to 24 months for a complete migration. The data platform approach — connecting systems to a central warehouse rather than migrating between them — can deliver a unified view in 8 to 16 weeks regardless of the underlying migration timeline.

What data is at risk during a CRM migration?

The most commonly lost or corrupted data during a CRM migration includes: years of meeting notes and interaction logs (often stored in free-text fields with no standard schema), household and family relationship structures, advisor-to-client assignments, custom fields your firm created in the source CRM, email and activity history, document links and attachments, and workflow or pipeline stage history. Each source CRM stores this data differently, and target CRMs rarely have a direct field-for-field match.

How do RIAs migrate data when changing custodians?

Custodian migrations require coordinating account transfer paperwork (ACAT transfers or in-kind transfers), data extraction from the departing custodian's reporting systems, and mapping that data to the receiving custodian's account structure and reporting formats. Historical performance data, tax lot history, and cost basis records are the most critical and often the hardest to transfer cleanly. Many firms retain historical data in a separate reporting system or data warehouse rather than relying on the new custodian to carry it forward.

What happens to compliance records during a data migration?

Compliance records — including suitability documentation, trade rationale, client acknowledgments, and communication records — must be preserved continuously throughout a migration. SEC rules require RIAs to retain books and records for specific periods (typically 5 to 7 years depending on record type). Migrating off a system does not relieve a firm of its obligation to retain those records. Best practice is to maintain read access to the legacy system for the required retention period while operating the new system in parallel during transition.

What is the biggest mistake firms make when migrating data?

The most common and costly mistake is underestimating data quality issues in the source system. Migrations expose years of accumulated inconsistencies: duplicate client records, missing account relationships, malformed addresses, unmapped custom fields, and orphaned accounts with no advisor assignment. These issues are invisible until you attempt to load the data into a new system. Firms that skip the audit and mapping phases to save time consistently experience the most disruption during and after migration.

Can a data platform replace the need for data migration?

In many scenarios, yes. A data platform connects all of your systems — old and new — and normalizes their data in a central warehouse. Rather than migrating data out of your current CRM into a new one, you can connect both systems to the platform and get a unified view immediately. Individual system migrations can then happen on your timeline, or not at all if the legacy system still serves a functional purpose. This approach decouples analytics and reporting from migration risk.

How do RIAs handle data migration after an acquisition?

Post-acquisition data integration is the most complex migration scenario. The acquired firm typically has a different CRM, different custodians, different portfolio management system, and different data conventions. Attempting to immediately force everything into the acquiring firm's systems creates maximum disruption. The data platform approach is to connect all systems from both firms to a central warehouse first, establish a normalized unified view, and then migrate individual systems one at a time — preserving operations throughout and migrating on the firm's own schedule.

What should an RIA's migration rollback plan include?

A rollback plan should include: a full export of all source data before migration begins (stored in a format you can re-import), a documented freeze date after which no new data enters the source system during migration, a parallel operation period where both systems run simultaneously, clear criteria for what constitutes a migration failure that triggers rollback, and a defined escalation path with vendor support contacts. Most migration failures occur in the first 48 to 72 hours of cutover — parallel operation for at least two weeks substantially reduces risk.

Conclusion

Data migration is an unavoidable reality for RIAs operating in a consolidating industry with evolving technology requirements. Whether you're switching CRMs, moving custodians, or integrating an acquired firm, the fundamentals are the same: audit before you migrate, map every relationship explicitly, test on a subset before running the full migration, and keep a rollback plan ready until post-migration validation is complete.

The firms that migrate most successfully are the ones that treat data quality remediation as part of the migration project, not as a prerequisite to it. They budget for the cleanup work, they run parallel systems long enough to validate fully, and they maintain access to legacy systems through the compliance retention period.

For firms navigating significant technology transitions — particularly post-acquisition integrations or multi-system consolidations — a data platform changes the migration calculus entirely. Instead of migrating data as a precondition to analytics and reporting, connect all systems to a central warehouse immediately and migrate individual systems on a schedule that prioritizes operational continuity over technical convenience.

Data Migration for RIAs