SQL Server, Oracle, on-prem reporting databases — the wealth-management-specific gotchas, sequencing, and parallel-run strategy for a successful cutover.

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.

SQL

Server is the most common legacy source in wealth management

10+

Years of historical data commonly held in legacy wealth databases

60

Days — typical minimum parallel run before cutover

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.

Generic Database Migration

✕Schema mapping and data copy

✕Query translation

✕Application reconnection

✕Performance validation

Wealth Management Snowflake Migration

✓Schema mapping + domain-specific data normalization

✓Query translation + billing logic validation

✓Application reconnection + shadow billing cycles

✓Performance validation + regulatory retention review

✓Household structure historicization assessment

✓Custodian history normalization across format changes

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.

1

Weeks 1–4

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.

2

Weeks 4–10

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.

3

Weeks 8–16

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.

4

Weeks 12–20+

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.

Critical Milestone

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.

01

Account Transfer Stitching

Custodian-to-custodian transfers break position history unless the data model includes transfer-of-asset event tracking.

02

Fee Schedule Version History

Historical billing recalculation requires historical fee schedule data — often not present in legacy systems.

03

Household Change History

Point-in-time household structure is required for accurate historical billing — legacy systems often store only current structure.

04

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.

Historical data extraction and normalization

• Traditional DIY Migration: $50K–$200K in engineering time

• Platform-Led Migration (Milemarker): Included in platform migration service

Snowflake data model design

• Traditional DIY Migration: $100K–$400K; 3–6 months

• Platform-Led Migration (Milemarker): Pre-built wealth data model deployed by configuration

Parallel run infrastructure and monitoring

• Traditional DIY Migration: Internally staffed; 1–2 analysts full-time for 60–90 days

• Platform-Led Migration (Milemarker): Parallel run tooling provided; analyst reviews exception reports

Query and report translation

• Traditional DIY Migration: $30K–$150K depending on complexity

• Platform-Led Migration (Milemarker): Translation guidance included; complex procedures assessed individually

Legacy system dual-operation period

• Traditional DIY Migration: Existing license + Snowflake consumption costs

• Platform-Led Migration (Milemarker): Same dual-operation period; lower total because platform compresses timeline

Post-cutover issue remediation

• Traditional DIY Migration: Highly variable; can be significant if parallel run was skipped

• Platform-Led Migration (Milemarker): 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.

Frequently Asked Questions

How long must a wealth firm retain historical data when migrating to Snowflake?

SEC and FINRA regulations generally require investment advisers and broker-dealers to retain trade records, account statements, and order records for 3–6 years, with some categories of records required for up to 10 years or indefinitely. When migrating to Snowflake, firms must either migrate the full required historical dataset to Snowflake or maintain the legacy system in a read-only archive state for the regulatory retention period. Most wealth firms opt for a hybrid approach: migrate the working dataset to Snowflake and maintain the legacy system in cold storage for older records, with a documented process for retrieving legacy data if required in an examination. Consult your compliance team before decommissioning any legacy system that holds records subject to regulatory retention requirements.

What is a parallel run and why does every wealth migration need one?

A parallel run is a period — typically 30 to 90 days — during which both the legacy system and Snowflake are receiving live data and producing outputs simultaneously. Operations teams compare outputs from both systems daily, investigate discrepancies, and build confidence that Snowflake is producing correct results before cutting over. In wealth management, parallel runs are essential because billing discrepancies, performance calculation differences, and reconciliation breaks discovered post-cutover are operationally disruptive and potentially client-facing. A parallel run surfaces these issues while the legacy system is still the system of record, so they can be corrected without impacting advisors or clients.

What does the parallel run cost — are we paying for two warehouses simultaneously?

During a parallel run, the firm is operating two systems simultaneously: the legacy on-prem system (existing license and infrastructure costs) and Snowflake (consumption-based costs). Snowflake costs during the parallel run are typically modest — the warehouse is receiving data and running shadow calculations, but it is not yet serving production reporting workloads, so compute consumption is lower than it will be post-cutover. The more significant cost consideration is the internal and external resources required to compare outputs daily, investigate discrepancies, and make corrections. Most firms find that a well-structured 60-day parallel run costs meaningfully less than the operational disruption of a post-cutover billing or reconciliation break.

How are wealth-firm billing engine dependencies handled during migration?

Billing engines are typically the highest-risk dependency in a wealth migration because they produce client-facing outputs on a quarterly schedule with zero tolerance for error. The migration approach for billing is to run Snowflake shadow billing in parallel with the legacy billing engine for at least two full billing cycles before considering cutover. Shadow billing means Snowflake calculates fees using the same inputs and fee schedule logic as the legacy system, and the outputs are compared account by account. Discrepancies — often caused by fee schedule edge cases, AUM calculation timing differences, or household structure handling — are corrected in the Snowflake logic until shadow billing consistently matches legacy billing within an acceptable tolerance. Only after two clean billing cycles does the firm consider cutting over billing to Snowflake.

When is the right time to cut over from the legacy system to Snowflake?

The cutover decision should be driven by three criteria: the parallel run is producing consistent results with acceptable discrepancy rates across all key workloads; the Snowflake system has successfully completed at least one full billing cycle in shadow mode; and the operations team has built sufficient proficiency with Snowflake tools to handle day-to-day questions without relying on the legacy system. The timing of cutover matters too — most firms choose to cut over at the start of a new quarter, after a billing cycle completes and before the next one begins. This minimizes the risk of a billing disruption and gives the operations team a full quarter to work through any post-cutover issues before the next billing cycle.

How does Snowflake handle the SQL Server or Oracle queries that wealth firms have built up over years?

Snowflake uses ANSI SQL as its query language, so most SQL Server and Oracle queries migrate with modest modifications. The most common translation issues are SQL Server-specific functions (GETDATE() → CURRENT_TIMESTAMP(), TOP n → LIMIT n), Oracle-specific syntax (ROWNUM, Oracle-specific analytic functions), date handling differences, and stored procedure logic that uses T-SQL or PL/SQL procedural extensions. Stored procedures must be rewritten in Snowflake Scripting, JavaScript, or Python. Most wealth firms have a mix of simple reporting queries (easy to migrate) and complex billing and performance calculation stored procedures (require careful rewriting and validation).

Does migrating to Snowflake require downtime?

A well-planned Snowflake migration does not require planned downtime for the legacy system during the migration period. The parallel run approach keeps the legacy system fully operational throughout. The actual cutover typically involves a scheduled maintenance window of 4 to 8 hours to ensure a clean handoff: completing any in-flight processes on the legacy system, performing a final data sync to Snowflake, validating the final state, and redirecting reporting and operational tools to Snowflake. This maintenance window is typically scheduled on a weekend or after market hours to minimize operational impact.

What does Milemarker's migration service cover and what does the firm still need to do?

Milemarker's migration service covers: historical data extraction from the legacy system, normalization into Milemarker's wealth management data model in Snowflake, parallel run setup and monitoring, shadow billing and reconciliation comparison tooling, query translation guidance, and cutover coordination. The firm is responsible for: final compliance approval to decommission legacy systems, communicating the migration timeline to relevant stakeholders, internal staff training on Snowflake tools and Milemarker's platform, and engaging the firm's IT team on infrastructure decommission. Milemarker does not make compliance decisions on behalf of the firm regarding regulatory data retention requirements.

RELATED RESOURCES

Pillar Snowflake for Financial Services & Wealth Management Implementation Implementing Snowflake at a Wealth Firm: 8 Weeks vs 18 Months By Segment Snowflake for RIAs Comparison Snowflake vs Databricks for Financial Services Architecture Wealth Management Data Lakehouse Data Platform What is a Wealth Management Data Platform?

Related guides

Part of the Snowflake for Wealth series:

• Snowflake for Financial Services & Wealth Management

• Snowflake vs Databricks for Financial Services

• Snowflake Cortex for Financial Services. AI Where Your Data Already Lives.

• Snowflake for RIAs

• Implementing Snowflake at a Wealth Firm: 8 Weeks vs 18 Months

• Snowflake vs BigQuery for Wealth Management