Skip to content
All services
Industry · E-commerce

The warehouse bill should not triple every November.

Holiday peak compute costs, fragmented customer identity across web and mobile, product catalog data at scale, and reverse-ETL pipelines feeding marketing tools. Platform migrations for e-commerce companies sequence around the trading calendar — peak windows are a planning input, not a surprise.

What is different about e-commerce platform migrations

Two structural factors set e-commerce migrations apart. First, the trading calendar: a migration that causes degradation during Q4 peak is a business event, not just an engineering incident. Every execution plan is built around that constraint, with blackout windows explicit in the timeline before execution begins.

Second, the data topology is unusually broad. An e-commerce warehouse typically feeds four distinct downstream consumer tiers — product analytics, marketing attribution, personalization models, and operational reporting — each with different latency tolerances and different ownership. Discovery maps all four before any wave planning begins.

The migration shapes that appear most often

  • Peak compute scaling architecture. Moving from a warehouse where peak capacity is baked into the steady-state configuration to one where slots, serverless compute, or autoscaling decouples peak from baseline. The slot or commitment model for the target platform is designed in Discovery based on observed compute patterns, not estimated — the Discovery Sprint pulls actual workload metrics from the source.
  • Customer 360 event stitching. Customer identity scattered across web clickstream, mobile app events, email engagement, and in-store transaction tables is one of the most migration-sensitive components because the stitching logic is often buried in views or dbt models that reference source-specific syntax. Discovery enumerates every identity resolution join, classifies it by complexity, and translates it as a named object in execution.
  • Product catalog data model migration. Catalog hierarchies stored as relational tables migrate differently from catalog data stored in semi-structured columns. The rule library covers Snowflake VARIANT to BigQuery STRUCT and Redshift SUPER to Snowflake VARIANT as standard patterns. Where catalog feeds a real-time serving layer, the serving-layer dependency is mapped in Discovery so it does not break silently at cutover.
  • Reverse-ETL to marketing tools. Pipelines that push computed segments back to a CRM, CDP, or email platform are enumerated as a named consumer tier. Each pipeline migrates after the warehouse cutover — not simultaneously — to reduce the blast radius. Segment outputs are verified in parallel before the source-side pipeline is decommissioned.
  • Personalization model retraining. Where recommendation or personalization models retrain on warehouse data, the retraining pipeline's data dependency is in scope. Discovery inventories the training data path, and execution verifies that the post-migration training pipeline produces output within an acceptable drift range relative to the source-side baseline.

What an e-commerce Discovery Sprint surfaces

  • Observed compute cost by month, with peak-to-baseline ratio and the slot or serverless model that would flatten the curve.
  • Customer identity resolution inventory: every join, every stitching model, classified by migration complexity.
  • Downstream consumer map: product analytics, marketing attribution, personalization, operational reporting — each with its latency tolerance and migration sequencing.
  • Reverse-ETL pipeline inventory: every segment-push pipeline, its target tool, and the cutover sequence relative to the warehouse wave plan.
  • Peak-window blackout dates and the wave plan built around them.
  • Execution scope and fixed-fee quote.

Related reading

How to start

The fast path is a Cloud Cost X-Ray — 5 business days, names the top-20 cost drivers including the peak compute shape, before any commitment. The fee credits 100% against Execution signed within 60 days. If the situation is past the diagnostic phase, book a 30-minute call and we will quote the Discovery Sprint directly.

Questions buyers actually ask

Before you book a call.

What typically forces an e-commerce company to migrate its data platform? ▾
The most common forcing function is the Q4 cost spike. When a warehouse bill that runs at 20k a month hits 180k in November and December, finance asks why the platform team cannot size for peak without paying for peak year-round. The answer is usually that the current warehouse does not have a clean autoscaling or slot-commitment model that decouples peak capacity from steady-state cost. The second common trigger is personalization: when the recommendation or marketing team needs a customer 360 view that the existing warehouse cannot serve with low enough latency for real-time use cases.
How does the migration handle holiday peak periods — we cannot have downtime in November. ▾
Peak periods are a first-class constraint in the execution timeline, not a scheduling note. Discovery establishes a migration blackout window that covers peak season. Execution waves are sequenced to complete the cutover either before the blackout opens or after it closes. If the estate is too large to migrate before peak, the plan stages the migration so that the highest-traffic workloads are on the new platform before peak and lower-risk workloads migrate in the post-peak window. The timeline is explicit in the execution plan; you sign off on it before any execution work begins.
Our customer identity is fragmented across web, mobile app, email, and in-store. How does migration handle that? ▾
Identity stitching logic is one of the most migration-sensitive components in an e-commerce warehouse — because it is often encoded in view logic, dbt models, or stored procedures that reference the source warehouse directly. Discovery enumerates every place where customer identity resolution logic lives, classifies each by complexity (simple join vs probabilistic match vs third-party graph), and produces a translation path for each. The parallel-run window specifically verifies that the unified customer counts and attribution totals match between source and target before any marketing pipeline is cut over.
We run reverse-ETL to push customer segments back to our CRM and marketing tools. Does that need to migrate too? ▾
Reverse-ETL pipelines — where computed segments or aggregates are written back to Salesforce, HubSpot, Klaviyo, or a CDP — are enumerated in Discovery as a named consumer tier. Each pipeline gets a migration path: the query that produces the segment translates to the target warehouse, the reverse-ETL connector is reconfigured to point at the target, and the segment outputs are verified in parallel before the source-side pipeline is decommissioned. Reverse-ETL cutover happens after the warehouse cutover, not simultaneously, to reduce the blast radius.
Our product catalog has complex hierarchies and variant structures. Is that just a data shape problem or does it affect the migration architecture? ▾
Product catalog complexity affects the migration in two ways. First, the physical storage model varies: some teams store catalog in a relational hierarchy, others use semi-structured columns (JSON blobs, VARIANT types in Snowflake, STRUCT arrays in BigQuery). Semi-structured catalog data requires explicit schema mapping during migration, and the rule library carries the common Snowflake VARIANT to BigQuery STRUCT conversions. Second, catalog data often feeds both the warehouse analytics path and a real-time serving layer. Discovery maps both paths and ensures the migration does not break the serving-layer dependency.
How is reconciliation handled for an e-commerce warehouse given the volume of SKU and order data? ▾
Row-count parity and schema parity run per table as standard. For e-commerce specifically, we add business-metric reconciliation on top: GMV totals per date range, order counts per channel, and unique customer counts per cohort period must match between source and target within a defined tolerance before any wave is signed off. These are deterministic checks written in plain SQL, run against both environments in parallel, and included in the co-signed reconciliation evidence.