Most wealth firms migrating to Snowflake are coming from SQL Server, Oracle, on-prem Tableau extracts, or vendor-built reporting databases. The pattern: parallel ingest → shadow rollups → cut over reporting → retire the old warehouse in stages.
Cloud warehouse migration has become a standard project at technology firms, but wealth management is not a standard industry. The regulatory environment, the domain-specific data model, and the operational dependencies that wealth firms have built on legacy systems make migration more complex than it appears. A migration plan that works for a software company's analytics database will not work for a broker-dealer's trading history database.
This playbook covers the wealth-management-specific challenges — what makes migrating a wealth firm's data to Snowflake different from a generic database migration, what can go wrong, and how to sequence the work to minimize risk. For the broader implementation context, see Snowflake for Financial Services and Snowflake Implementation for Wealth Management.
Where Wealth Firms Are Migrating From
The legacy system landscape at wealth management firms is more heterogeneous than it appears from the outside. The source system for a Snowflake migration is rarely a single, well-documented database. It is typically a patchwork that has accumulated over years of growth, acquisition, and technology decisions made by teams that may no longer be at the firm.
SQL Server
SQL Server is the most common legacy source in wealth management — particularly at RIAs, broker-dealers, and TAMPs that grew through the 2000s and 2010s. These databases often contain a decade or more of custodian position history, billing calculation data, and proprietary reporting views built by developers who are no longer at the firm. The schema is rarely documented, and many firms discover that critical business logic lives in SQL Server stored procedures that have not been touched in years.
Oracle
Oracle databases appear more commonly at larger firms — broker-dealers with institutional roots, wire houses, or firms that purchased enterprise risk or portfolio management software built on Oracle. Oracle migrations to Snowflake require translating PL/SQL stored procedures, Oracle-specific date and analytic functions, and sequence-based ID generation logic into Snowflake-compatible equivalents.
Vendor-Built Reporting Databases and On-Prem Tableau Extracts
Many wealth firms have reporting infrastructure built on vendor-provided databases — a Tamarac reporting database, an Orion analytics export, a performance reporting system's back-end — plus Tableau or Looker connected to on-prem extracts. These systems typically cannot be migrated directly; instead, Snowflake replaces them as the data layer, and the BI tools are reconnected to Snowflake while the vendor-managed reporting databases are retired.
Microsoft Access and Legacy Reporting Databases
Smaller firms and family offices frequently have critical business data in Microsoft Access databases or custom-built reporting databases that were created as tactical solutions and became permanent. These are the most fragile migration sources: poorly documented, often the only copy of the data, and frequently running on hardware that is several years past end-of-life. Access migrations to Snowflake require full data extraction before the source system fails, not during a calm migration window.
Why Migration Is Different in Wealth Management
Four characteristics of wealth management data make migrations significantly more complex than a generic database migration, and all four must be addressed in the migration plan before work begins.
Regulatory Data Retention Requirements
Investment advisers and broker-dealers are subject to record-keeping regulations that require certain data to be retained for 3, 6, or in some cases 10+ years. Before decommissioning any legacy system, the firm must confirm that either the full required dataset has been migrated to Snowflake or the legacy system will remain accessible in archive form for the required retention period. Migrating only recent data to Snowflake and immediately decommissioning the legacy system puts the firm at regulatory risk if older records are needed in an examination.
Custodian Feed History
Custodian feeds deliver daily position, transaction, and account data. A legacy system may hold years of this history — often in a proprietary schema that has been modified multiple times as custodians changed their file formats. Migrating this history to Snowflake requires not just copying the data, but normalizing it into Snowflake's target schema, resolving format changes that occurred mid-history, and validating that the migrated history produces the same position and performance results as the legacy system for any given date in the past.
Billing Engine Dependencies
Most wealth firms' billing engines — whether custom-built or vendor-provided — read from the firm's primary data store to calculate management fees. These billing engines have often been tuned over years to handle edge cases: pro-rated fees for accounts opened or closed mid-quarter, blended fee schedules that change at AUM thresholds, household-level fee calculations, tiered billing for different account types. Migrating the underlying data to Snowflake requires either migrating the billing engine too or building new billing logic in Snowflake that produces identical outputs to the legacy billing engine — a validation exercise that typically requires two full billing cycles in shadow mode.
Household Structure Historicization
Household structures in wealth management change over time — accounts are added, removed, transferred between households, and split across advisors. Legacy systems typically store the current household structure and may have limited history of past structures. Performance reporting and billing that depends on the household structure as it existed at a past date requires point-in-time household history, which may not exist in the legacy system and must be reconstructed before migration or accepted as a known gap in the migrated dataset.
The Recommended Migration Sequence
The sequence below applies to most wealth management firms migrating from SQL Server, Oracle, or similar on-prem databases to Snowflake. The phases are designed to minimize risk by keeping the legacy system as the system of record until Snowflake has been validated through live operations.
Parallel Ingest — Custodian + CRM Data
Begin running custodian data pipelines to Snowflake in parallel with the legacy system. The legacy system continues to receive and process custodian feeds as normal; Snowflake receives the same feeds and begins building its position history. This phase validates that the Snowflake pipelines are correctly receiving and normalizing custodian data before any dependency is placed on them. CRM data (Salesforce, Redtail, Wealthbox) is also migrated in this phase — household structures, advisor assignments, and client metadata land in Snowflake alongside position data.
Shadow Rollups — Reconciliation and Performance
With position history accumulating in Snowflake, begin running shadow reconciliation and performance calculations. The legacy system's daily reconciliation output is compared to Snowflake's output for the same date. Discrepancies are investigated and resolved. This phase surfaces schema issues, data normalization gaps, and edge cases in the performance calculation logic before any reporting depends on Snowflake. Two to four weeks of clean shadow reconciliation — within an acceptable discrepancy threshold — is required before proceeding to shadow billing.
Cut Over Reporting — BI Tools Reconnect to Snowflake
After shadow reconciliation is stable, reporting tools — Tableau, Power BI, Looker, Sigma, or internal dashboards — are reconnected to Snowflake. Internal reporting audiences (operations, compliance, management) begin using Snowflake-backed reports. Client-facing reporting remains on the legacy system until shadow billing validation is complete. This phase is low-risk because reporting tools are read-only; a discrepancy in a Snowflake-backed report is annoying but not operationally consequential while the legacy system is still the system of record for billing and compliance.
Retire Old Warehouse — In Stages
After two full billing cycles in shadow mode, the firm proceeds to cutover — Snowflake becomes the system of record and the legacy system transitions to archive or decommission. Retirement happens in stages: billing engine cutover first, followed by compliance data cutover, followed by operational archive. The legacy system remains accessible in read-only mode for the regulatory retention period for any historical records not fully migrated. The parallel run infrastructure is decommissioned last, once the cutover is stable.
Two Clean Billing Cycles Before Cutover
The standard for billing cutover readiness is two consecutive billing cycles in which the Snowflake shadow billing output matches the legacy billing output within a defined tolerance for all accounts. One clean cycle is not sufficient — billing edge cases often appear only in the second cycle, as accounts that were at threshold boundaries in the first cycle move across thresholds. The tolerance threshold is a firm-specific decision, but a common standard is less than 0.01% total fee variance across all accounts.
Wealth-Specific Gotchas
Every wealth management Snowflake migration surfaces surprises. These are the patterns that appear most consistently across firm types and legacy systems.
Account History and Transfer-of-Asset Events
When an account transfers from one custodian to another — for example, a client moves from Fidelity to Schwab — the transaction history at the originating custodian stops, and a transfer-of-asset event begins the history at the receiving custodian. Legacy systems often handle this by stitching the account histories together under a single account ID. Snowflake's data model must replicate this stitching logic, or performance history appears to break at the transfer date. Firms with significant account transfer history — particularly those that grew through acquisitions — frequently encounter this issue.
Fee Schedule Versioning
Fee schedules change. A client negotiates a reduced rate when their AUM crosses a threshold. A firm introduces a new fee tier for institutional accounts. A legacy billing system may store only the current fee schedule or may have inconsistent historical records of past schedules. Billing calculations for past periods depend on what the fee schedule was at the time, not what it is today. Migrating billing history to Snowflake requires either migrating the fee schedule history alongside the billing data or accepting that historical billing cannot be recalculated in Snowflake — a limitation that may not be acceptable to compliance.
Household Changes and Their Impact on Billing
Household structures change when clients divorce, when beneficiaries are added or removed, or when accounts are transferred between advisors. Each change potentially affects the household-level AUM used to determine fee tier. A billing engine that recalculates past billing based on past household structure will produce different outputs than one that uses the current structure. Legacy systems often lack the household history needed to make this determination correctly, and the gap must be documented and addressed in the migration plan.
Cost Basis History Across Custodian Transfers
Cost basis data for a position may have originated at a custodian that no longer holds the position. When an account transfers, cost basis data must transfer with it. Legacy systems that receive cost basis from custodians may have gaps if the originating custodian did not deliver cost basis history at transfer time. Migrating cost basis to Snowflake requires auditing what cost basis data exists and documenting gaps that will require manual remediation or acknowledgment as known limitations in the migrated dataset.
Account Transfer Stitching
Custodian-to-custodian transfers break position history unless the data model includes transfer-of-asset event tracking.
Fee Schedule Version History
Historical billing recalculation requires historical fee schedule data — often not present in legacy systems.
Household Change History
Point-in-time household structure is required for accurate historical billing — legacy systems often store only current structure.
Cost Basis Gaps
Cost basis history may be incomplete for positions that transferred between custodians — gaps must be documented before migration.
Risk Mitigation: Parallel Run Strategy
The parallel run is the single most important risk mitigation tool in a wealth management Snowflake migration. It is also the element most frequently compressed or skipped in projects under time pressure — and the compression almost always results in post-cutover incidents that cost more to remediate than the parallel run would have cost to complete.
A well-structured parallel run has four components: both systems receive the same input data; outputs are compared at position, account, and billing granularity; discrepancies above tolerance trigger a documented investigation workflow; and defined exit criteria — a specific discrepancy rate across a specific time period — must be met before cutover is approved. In practice, parallel runs consistently surface position rounding differences, performance calculation timing differences, billing edge cases, and household structure handling issues. Most are solvable — the parallel run reveals them while the legacy system is still the system of record.
Cost Considerations During Migration
Migration projects carry costs that are easy to underestimate. The full cost of a wealth firm Snowflake migration includes several categories that are often treated as separate line items but are operationally interconnected.
| Cost Category | Traditional DIY Migration | Platform-Led Migration (Milemarker) |
|---|---|---|
| Historical data extraction and normalization | $50K–$200K in engineering time | Included in platform migration service |
| Snowflake data model design | $100K–$400K; 3–6 months | Pre-built wealth data model deployed by configuration |
| Parallel run infrastructure and monitoring | Internally staffed; 1–2 analysts full-time for 60–90 days | Parallel run tooling provided; analyst reviews exception reports |
| Query and report translation | $30K–$150K depending on complexity | Translation guidance included; complex procedures assessed individually |
| Legacy system dual-operation period | Existing license + Snowflake consumption costs | Same dual-operation period; lower total because platform compresses timeline |
| Post-cutover issue remediation | Highly variable; can be significant if parallel run was skipped | Reduced by thorough parallel run; Milemarker support included post-cutover |
The most significant cost driver in a DIY migration is timeline. Each additional month of migration timeline costs the firm in dual-operation expenses, engineering time, and organizational distraction. Platform-led migrations compress the timeline by providing the components — data model, connectors, parallel run tooling — that DIY teams must build. For a detailed cost and timeline comparison, see Snowflake Implementation for Wealth Management.
Where Milemarker Fits — Migration as a Service
Milemarker provides migration as a service for wealth management firms moving from legacy on-prem databases to Snowflake. The service encompasses the full migration lifecycle: historical data extraction, normalization into Milemarker's wealth management data model, parallel run setup and monitoring, shadow billing infrastructure, and cutover coordination.
Pre-Built Wealth Data Model
The most time-consuming and highest-risk component of a DIY Snowflake migration is designing and validating a wealth management data model that correctly represents households, accounts, positions, billing, and custody relationships — and that holds up under real custodian data with all its edge cases. Milemarker's data model has been validated across hundreds of firm implementations. Firms migrating to Milemarker do not design a data model; they configure their firm's data against a production-tested schema.
130+ Pre-Built Custodian Connectors
One of the largest DIY migration cost drivers is building custodian data pipelines from scratch. Milemarker provides pre-built connectors for Schwab, Fidelity, Pershing, Altruist, Northern Trust, BNY Mellon, SS&C, and more. These connectors handle the normalization logic that custodian file format changes require — and Milemarker maintains the connectors as custodians update their formats, so the firm does not inherit ongoing connector maintenance burden. For a full view of how Milemarker compares to alternatives, see Snowflake vs Databricks for Financial Services.
Milemarker augments the firm's existing technology rather than replacing it. Portfolio management systems, CRM, and BI tools continue to operate — Milemarker replaces the legacy data layer beneath them. For firms on the path from SQL Server or Oracle to Snowflake, Milemarker shortens the journey from 12–18 months of DIY to 8–16 weeks of platform-led migration. For TAMP-specific questions, see Snowflake for TAMPs; for RIA-specific context, see Snowflake for RIAs.
- Historical data migration: Full extraction and normalization of legacy position, transaction, and billing history into Milemarker's Snowflake schema.
- Parallel run tooling: Pre-built comparison infrastructure for reconciliation, billing, and performance — the firm reviews exceptions, not raw output.
- Connector maintenance: Custodian format changes absorbed by Milemarker post-cutover — no internal engineering required to maintain pipelines.
- Cutover coordination: Structured cutover process with pre-defined exit criteria, maintenance window planning, and post-cutover monitoring.