ARA-C01 Question 179
Single answerMigrationA global retailer is migrating a 120 TB on-premises data warehouse to Snowflake. The source system contains 8 years of historical data, but business users only query the most recent 18 months regularly. The migration team must minimize cutover risk, keep the target available for user acceptance testing before go-live, and reduce unnecessary compute during the migration window. Which approach is the MOST appropriate?
- A
Perform a single full load of all 8 years of data into the production Snowflake schema during the cutover weekend, then validate afterward to avoid maintaining multiple environments.
- B
Load the most recent 18 months first into Snowflake for testing and early validation, then backfill older history separately while using a CDC-based incremental process to keep current data synchronized until cutover.
- C
Migrate only metadata objects first and delay loading any data until after users sign off on the target design, because user acceptance testing should not use real production data.
- D
Replicate the source warehouse continuously into Snowflake using a 5XL warehouse for the full migration period so that all historical and current data are loaded as quickly as possible, regardless of query patterns.
Show answer and explanation
Correct answer: B
Explanation
For large-scale warehouse migrations to Snowflake, a phased approach is generally preferred when the business accesses recent data far more frequently than older history. Loading the hot or recent subset first enables earlier validation, user acceptance testing, and lower-risk cutover planning. Using change data capture or another incremental synchronization method keeps source and target aligned until go-live, which is a standard migration pattern for minimizing downtime. Historical backfill can then be completed separately, often with lower-priority compute. This approach aligns with Snowflake migration best practices around phased cutover, workload-based prioritization, and elastic compute sizing rather than overprovisioning for the entire migration period. Relevant Snowflake guidance typically emphasizes minimizing downtime, validating incrementally, and using appropriately sized warehouses for load operations rather than relying on a single large cutover event.
- A. Incorrect.
This is not the best approach. A single big-bang load of all historical data during the cutover window increases risk, reduces time for meaningful validation, and can extend downtime. It also ignores the stated requirement to keep the target available for user acceptance testing before go-live. In practice, phased migration patterns are preferred when only a subset of data is actively queried and when minimizing cutover risk is important.
- B. Correct.
This is correct. Prioritizing the most frequently queried 18 months supports early testing and user validation while limiting unnecessary compute and elapsed time during the initial migration. A CDC-based incremental synchronization process keeps the Snowflake target current until cutover, reducing business disruption. Historical backfill can proceed separately, which is a common migration best practice when older data is needed for compliance or occasional access but not for immediate operational workloads.
- C. Incorrect.
This is incorrect. While metadata-first migration can be part of a broader plan, delaying all data loading until after sign-off prevents realistic user acceptance testing and validation of performance, data quality, and reporting behavior. In real migrations, representative or production-like data is typically required for meaningful testing, subject to governance and masking requirements.
- D. Incorrect.
This is not the most appropriate choice. Continuous replication of all history and current data with an oversized warehouse may complete faster, but it conflicts with the requirement to reduce unnecessary compute. It also does not take advantage of the fact that most queries target only recent data. Right-sizing compute and phasing historical loads are better aligned with cost-efficient Snowflake migration design.