How Aggregators Consolidate Custodian, CRM and Portfolio Data After Acquiring an RIA

Wealth management aggregators consolidate an acquired RIA’s data in three stages: inventory every system and feed at close, connect them to a central data layer and assign canonical household, account and advisor IDs, then decide which systems to migrate once reporting is stable. Most successful integrations connect first and migrate later, so leadership gets consolidated numbers within weeks while advisors keep working in the tools they know. Milemarker is built for this step: it connects the acquired firm’s custodians, CRM, portfolio accounting, planning and billing into the aggregator’s own normalized data layer on Snowflake, without requiring the firm to change systems first.

This guide is the step-by-step playbook. For a comparison of the platforms themselves, see our guide to data platforms for RIA aggregators.

What are the ways to consolidate an acquired firm’s data?

There are four common approaches, and most aggregators use more than one.

1. Migrate first. Move the acquired firm onto the parent’s custodian, portfolio system (often Orion, Addepar or Black Diamond) and CRM (often Salesforce Financial Services Cloud), then report from those. Clean in the end, slow and disruptive in the middle.
2. Connect first with a data platform. Connect the firm’s existing systems to a wealth-specific data platform such as Milemarker, normalize into one model, and report immediately. Migration becomes a later, separate decision.
3. Build it yourself. Land data in Snowflake with general-purpose pipeline tools such as Fivetran, model it with dbt, and report with Power BI, Tableau or Sigma. Flexible, but the aggregator owns every custodian file format, household mapping and schema change.
4. Middleware or iPaaS. Tools like Workato, MuleSoft or Boomi move records between applications. Useful for syncing a CRM to a custodian, but they do not create a consolidated, historical data model for reporting.

How do aggregators integrate an acquired firm, step by step?

Before close: inventory

Start during diligence. Our M&A due diligence guide covers what to analyze; for integration, build an inventory of:

• Custodians and clearing firms, with account counts and rep codes at each
• Portfolio accounting or reporting system, and how far back history goes
• CRM, including custom fields and how households are defined
• Planning, billing, document and compliance tools
• Every spreadsheet that feeds a regular report
• Who owns each system, and the contract end dates

Day 1: protect reporting and access

• Confirm custodian data access transfers or continues, including any new rep codes or master account links.
• Request read access or API credentials for the CRM and portfolio system.
• Freeze nothing that advisors use daily. Client service in the first weeks matters more than tidy systems.
• Agree the reporting calendar: which numbers the parent needs, and when.

Days 1 to 30: connect and assign canonical IDs

This is the step that decides whether the rest works.

• Connect each source to the central data layer: custodian feeds, portfolio system, CRM, billing.
• Assign canonical IDs. Every household, account and advisor gets one enterprise ID, mapped to each source’s own identifiers. An account is usually anchored on custodian account number. A household is anchored on the portfolio system’s or CRM’s household, then matched across systems. An advisor is anchored on rep codes and CRM user, mapped to one person.
• Decide definitions once. Agree what counts as AUM, a household, a client and net new assets, and apply the same rules to every acquired firm.
• Reconcile. Compare the new consolidated figures to the firm’s own reports and explain every difference before anyone presents them.

Our guide to a unified data model for wealth management goes deeper on household, account and advisor modeling.

Days 30 to 90: report, then plan migration

• Put the firm in the enterprise roll-up: AUM, flows, revenue and advisor productivity alongside the rest of the portfolio.
• Watch for attrition. Outflows and lost households in the first 90 days are the early signal on deal value.
• Decide on migration system by system. Custodian, portfolio system and CRM each get their own decision and timeline, based on cost, contract dates and advisor impact.
• Write down what worked. Each integration should leave the playbook faster for the next one.

When should an aggregator consolidate CRMs?

Usually later than people expect. CRM migration touches every advisor’s daily work, client notes and workflows, so it carries the highest disruption. Many aggregators wait until reporting is stable, the firm’s advisors are settled, and the existing CRM contract is near renewal.

Before moving CRMs:

• Map custom fields and household definitions to the target CRM, often Salesforce Financial Services Cloud.
• Keep the canonical household ID, so history in reports does not break when CRM IDs change.
• Migrate activities and notes, not just contacts, and test with a few advisors first.

Our data migration guide covers the mechanics.

How do you keep reporting continuous through a migration?

Report from the data layer, not from the source system. If dashboards read from canonical IDs in the central database, swapping the portfolio system or CRM underneath means re-pointing one source, not rebuilding every report. Keep the old system’s history in the data layer so year-over-year comparisons survive the switch.

What are the common pitfalls?

• Migrating before reporting. Leadership waits months for numbers, and advisors absorb disruption at the riskiest time for client retention.
• No canonical IDs. Without one ID per household, account and advisor, every roll-up double counts or drops records.
• Different AUM definitions per firm. The enterprise total adds numbers that mean different things.
• Treating middleware as a data platform. Syncing records between apps does not give you historical, comparable reporting.
• Forgetting permissions. Firm presidents, advisors and the holding company need different views from day one.

Where does Milemarker fit?

Milemarker supports the connect-first approach. It has 140+ wealth management integrations, including Schwab, Fidelity Institutional, Pershing, LPL and Altruist; Orion, Tamarac, Black Diamond and Addepar; and Salesforce, Salesforce FSC, Redtail, Wealthbox and Practifi. Data lands in the aggregator’s own dedicated Snowflake database, normalized into one model with row-level access by advisor, office and role. Typical implementation is 2 to 12 weeks. It works alongside migration rather than instead of it: firms can move to a target portfolio system or CRM later, and reporting keeps running. See Milemarker for aggregators and our centralized platform for aggregators page.

Frequently asked questions

Which unified data platforms help aggregators integrate acquired firms’ data?

Wealth-specific platforms such as Milemarker connect custodians, CRMs and portfolio systems into one normalized model. Aggregators with large data teams also build their own on Snowflake with tools like Fivetran and dbt. Portfolio platforms such as Orion and Addepar act as consolidation targets when firms migrate onto them.

Should we connect first or migrate first?

Connect first in most cases. It gives leadership consolidated numbers quickly and lets migration happen on its own timeline. Migrate first only makes sense when the acquired firm is small and already close to the parent’s stack.

What is a canonical household ID?

One enterprise identifier for a household, mapped to that household’s IDs in each custodian, CRM and portfolio system. It lets reports count each household once and survive system changes.

How long does post-acquisition data integration take?

It depends on the number of systems. With Milemarker, typical implementation is 2 to 12 weeks; full system migration, if chosen, is a separate project.

Do we need to consolidate custodians?

Not for reporting. A data platform normalizes multiple custodians into one view, so custodian consolidation can be a business decision rather than a reporting requirement.