Directions we cover
| Into Tealium | Out of Tealium |
|---|---|
| Google Tag Manager to Tealium | Tealium to Google Tag Manager |
| Adobe Launch to Tealium (DTM legacies included) | Tealium to Adobe Launch / Tags |
| Segment to Tealium | Tealium to Segment |
| mParticle to Tealium | Tealium to mParticle |
| RudderStack to Tealium | Tealium to RudderStack |
The three linked guides are the most-requested inbound directions and carry the direction-specific mapping detail. The others follow the same skeleton - the engagement adapts the mapping tables, not the method.
The method, in five stages
- 1. Runtime inventory. Capture what the current platform actually fires - every tag, event, and destination, per template, per consent state. The configuration export is the map; the wire is the territory.
- 2. Taxonomy mapping. Old events and variables mapped to the target event specification. This is the moment to fix naming debt - migrating a broken taxonomy faithfully is preserving the disease.
- 3. Parallel build. The target platform collects alongside the old one. Nothing is switched off.
- 4. Reconciliation. Destination by destination, old and new numbers are compared and every delta explained - collection differences, consent behavior, deduplication. This stage is the project; everything else is preparation.
- 5. Cutover and decommission. Destinations cut over one at a time; the old container is emptied deliberately, tag by tag, so nothing dies by surprise.
What decides the timeline
Estate size, taxonomy health, and how many destinations need reconciliation - not the platform pair. A disciplined single-property migration and a multi-brand estate with years of tag debt are different projects wearing the same name; the inventory stage is what tells you which one you have.
The one rule: reporting continuity beats migration speed. Nobody remembers a migration that ran a month long; everybody remembers the quarter attribution could not be trusted.