Migrating from a custom pipeline
If you already send conversions to Meta, Google, or anywhere else with your own code, this is about replacing that, not running alongside it forever.
List what you actually have, not what you think you have
Every destination with its own hand-rolled integration: which event types it sends, which fields it maps, and anything destination-specific bolted on over time. This list is usually longer and messier than expected, that’s the whole reason to migrate.
Map each one to a single event shape
Your existing code likely builds a different payload per destination. Toplu collapses that into one event_type/user_data/destinations shape, see Sending your first event. Map your existing fields onto it once, not once per destination.
Run both pipelines at once, on test keys, before touching anything live
Send the same conversions through Toplu with a test key alongside your existing pipeline still running for real. Compare what Toplu would have sent against what your old code actually sent, field by field, before either one is trusted alone.
Cut over one destination at a time, not all of them together
Move the destination you’re most confident about first. Watch its real delivery-status responses for a real send cycle before retiring that destination’s old code. Repeat per destination, not as one big-bang switch.
Delete the old code once, not gradually
Once every destination is confirmed on Toplu, remove the old per-destination integrations outright. Keeping both running indefinitely is exactly the double-maintenance cost migrating was meant to remove.
Need a hand?
Coding is hard sometimes, and that's okay. Visit our help center or reach out directly, we're here to help.