The recent, unannounced reduction of Google Analytics 4 (GA4) export limits for the BigQuery linking feature has introduced a critical, non-obvious point of failure for data migration projects. Specifically, the daily export limit for free GA4 properties is now capped at **1 million events**, a figure easily exceeded by medium-traffic sites. For those planning a migration *away* from GA4—be it to a self-hosted Postgres/ClickHouse analytics stack, a commercial platform like Snowplow, or a data warehouse like Snowflake—this limit now dictates the entire migration strategy's feasibility and timeline.
Previously, one could rely on a continuous, full-fidelity sync during a transition period. Now, any migration that cannot be completed within a single day's quota (or that of a few days, if historical data is partitioned) risks data loss. This forces a fundamental shift from a "trickle sync" cutover to a "big bang" historical export, followed by a hard cutover to a new collection method.
**Proposed Migration Walkthrough for a Mid-Sized E-commerce Site (~5M events/month)**
* **Pre-Migration Analysis:**
* Audit your current GA4 event volume via the `event_count` metric in the GA4 Data API or via existing BigQuery exports. Calculate the number of days required to export historical data given the 1M/day limit.
* Example: 24 months of history at 5M events/month = 120M events. This requires 120 days of export cycles, which is untenable. Therefore, scope reduction is mandatory.
* Decision: Export only the last 3 months (15M events) for historical reporting, requiring a 15-day sequential export process. Pre-aggregated metrics must be calculated for older data via alternative means.
* **Data Migration Approach:**
1. **Parallel Collection:** Deploy the new analytics collection pipeline (e.g., Snowplow trackers, custom events to your backend) at least 30 days prior to cutover. Store this data in your new target system (e.g., a PostgreSQL `raw_events` table).
2. **Historical Export Script:** Implement a idempotent, fault-tolerant script to manage the GA4 BigQuery export. It must handle the daily limit, resume from failures, and track which date partitions have been successfully copied.
```sql
-- Example: Query to check daily event count for a partition
SELECT
PARSE_DATE('%Y%m%d', event_date) as export_date,
COUNT(*) as event_count
FROM `your-ga4-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20240101' AND '20240331'
GROUP BY 1
HAVING COUNT(*) > 1000000; -- Identify days that hit the limit
```
3. **Transform & Load:** Stream or batch-load the exported BigQuery data into your target schema, aligning the data model with your new pipeline's output.
* **Cutover Plan:**
* **Day T-30:** Enable parallel collection. Begin validation by comparing key metrics (daily active users, conversion rate) between GA4 and the new system for a subset of traffic.
* **Day T-15:** Start sequential historical export for the last 90 days.
* **Day T-1:** Validate 90-day export is complete and metrics are within an acceptable variance (<2% discrepancy).
* **Cutover Day:** Disable GA4 tagging on the site/app. Redirect all analytics traffic to the new collection endpoint. Maintain GA4 data import for a final 72-hour reconciliation period before decommissioning.
* **Actual Transition Timeline:**
* **Planning & Development:** 2 weeks (building export orchestrator, parallel collection pipeline).
* **Parallel Run & Validation:** 4 weeks.
* **Historical Data Export:** 15 days (constrained by the 1M/day limit, process is mostly passive).
* **Final Cutover & Reconciliation:** 1 week.
* **Total Elapsed Time:** ~10 weeks. The critical path is dictated by the GA4 export throttle, not by your engineering capacity.
The key takeaway is that GA4 is no longer a reliable *source of truth* for a migration unless your data volume is minimal. The migration project must now center around establishing the new, independent collection pipeline first and treating GA4 as a limited, secondary historical source. This fundamentally alters the risk profile and technical approach.