Migration Playbook
From GTM SS / Segment / Tealium to Datafly Signal — in four weeks.
A phased migration that runs Signal alongside your existing stack before cut-over. No big-bang switches, no lost attribution, no week-long data blackout.
Week 0: Discovery & sign-off
Goal: Confirm scope, inventory current tags, and get deployment sign-off from your cloud ops team.
- Run a Live Tag Scan on your production URLs to produce an inventory of every currently-firing tag.
- Identify the vendor destinations that must be preserved (the shortlist is usually 5-15, not everything).
- Confirm cloud provider, region, and VPC target for deployment.
- Agree a success criteria: typically event-count parity ±2% with your current stack over a 7-day window.
Week 1: Deploy Signal in your VPC
Goal: Stand up Datafly Signal in a Kubernetes namespace inside your own cloud account.
- Run the Helm chart against your cluster. ~30 minutes for a standard install.
- Point a subdomain (e.g. data.example.com) at the Ingestion Gateway.
- Configure at least one pipeline workspace mirroring your current production setup.
- Verify health dashboards: events flowing, Kafka consuming, no delivery errors.
Week 2: Mirror existing tags
Goal: Configure Signal blueprints for every vendor currently firing, in dry-run mode.
- Enable blueprints for each of your target vendors (GA4, Meta CAPI, TikTok Events API, etc.).
- Map your event taxonomy (e.g. product_viewed → view_item for GA4) via the blueprint preset or custom transformations.
- Turn on PII handling rules: hash emails, strip sensitive fields, enforce consent.
- Run Signal in "dry-run" mode — events flowing but NOT delivered to vendor endpoints yet. Verify via the event debugger.
Week 3: Parallel delivery
Goal: Signal delivers to vendors alongside your existing stack. Compare.
- Enable delivery on Signal. Your existing stack (GTM, Segment, Tealium) continues to run unchanged.
- Compare event counts side-by-side in each vendor’s dashboard (GA4 Realtime, Meta Events Manager, etc.).
- Reconcile any discrepancy: typically Signal counts higher by 15-25% because it recovers ad-blocker-hidden conversions.
- Validate for a full 7 days across weekday and weekend patterns.
Week 4: Cut over
Goal: Turn off the old stack. Signal is now the sole delivery path.
- Remove the old vendor scripts from your pages (gtag.js, Meta Pixel, TikTok pixel, etc.).
- Keep the old server-side container running for one more week as a fallback.
- Monitor delivery success rates, vendor API error rates, and attribution reports.
- Decommission the old stack. Archive its configs for audit.
What can go wrong and how to handle it
- Event counts don\u2019t match the old stack in parallel
- This is expected. Signal recovers 15-25% of conversions that ad blockers hide from client-side pixels. Look at the shape of the delta: Signal should be higher on conversion counts but broadly identical on unique users and session counts. If the shape is off, pipeline mapping has a gap.
- Meta CAPI EMQ drops after cut-over
- Check that the browser Meta Pixel has been fully removed. Duplicate events from both browser pixel and server CAPI without matching event_id values look to Meta like two distinct events and blow up EMQ. Signal\u2019s blueprint dedupes via
messageIdwhen the pixel is still present. - A vendor doesn\u2019t yet have a Signal blueprint
- Build one in YAML using the generic HTTP destination spec. Most vendor APIs are reachable in under a day of transformation work. Priority vendors can be promoted to a first-class blueprint in a future release at no extra cost.
- Rollback
- Because Week 4 keeps the old stack running for another seven days as a dormant fallback, rollback is a one-line DNS change in the unlikely case of a production issue. We have never needed it, but it is there.
Get a migration plan tailored to your current stack
Send us your current tag inventory (or run a Live Tag Scan and we'll infer it) and we'll come back with a week-by-week migration plan specific to your environment.