Docs

Segment Analytics-Kotlin Migration Tracking

Segment's Analytics-Android SDK hit end-of-support in March 2026 — track event parity as you migrate to Analytics-Kotlin before data quietly drifts.

Analytics

Segment’s original Analytics-Android SDK reached end-of-support in March 2026, with all future development concentrated on Analytics-Kotlin. That’s a bigger migration than a version bump: Analytics-Kotlin isn’t a drop-in replacement, it’s a different architecture — Kotlin-first, coroutine-based, with its own plugin model for enrichment, destinations, and middleware. Teams that built custom logic on top of the old SDK’s plugin architecture — event enrichment, consent gating, destination filtering — have to re-implement that logic against a different API surface, not just swap a dependency version.

The risk isn’t that the migration fails outright; unsupported SDKs keep compiling and keep sending events for a long time after end-of-support. The risk is quieter: a plugin that behaved slightly differently gets rewritten with a subtly different execution order, a destination that was filtered out under the old SDK suddenly receives events under the new one, or a batch of events silently double-fires during the transition window while both SDKs are live in different app versions. None of that throws an error. It just makes your event data wrong in ways that take weeks to notice, because nothing in the pipeline complains — the numbers just start being harder to trust.

Data Points to Track

  • Event volume and event-name parity between Analytics-Android and Analytics-Kotlin builds running side by side, matched event-for-event rather than compared in aggregate
  • Plugin/middleware execution outcomes — enrichment, consent gating, destination filtering — verified individually against the old SDK’s behaviour, not assumed to carry over
  • Duplicate-event rate during the transition window, specifically for users who upgrade through an app version where both SDKs could theoretically fire
  • SDK version distribution across your install base, so you know in real time what share of traffic is still running the unsupported SDK versus the migrated one
  • Destination-level delivery confirmation — did each downstream tool (warehouse, ad platform, CRM) receive the same events post-migration it received pre-migration, at the same volume

Setup Steps

  1. Inventory every custom plugin, middleware, and destination filter built on the old SDK before writing any new code, since these are the pieces most likely to be reimplemented incorrectly.
  2. Run both SDKs in parallel on a staged rollout — a percentage of builds on Analytics-Kotlin, the rest on the legacy SDK — rather than a single hard cutover, so parity can be measured against a live comparison.
  3. Log a migration-cohort property on every event (legacy SDK vs. new SDK) so downstream dashboards can be split by SDK version without waiting for a full cutover to evaluate the new one.
  4. Write an automated event-parity check that diffs event names, properties, and volumes between the two SDK cohorts on a rolling basis, not just as a one-time pre-launch test.
  5. Confirm consent and privacy-gating logic explicitly, since a regression here doesn’t just corrupt analytics data — it can mean events firing for users who opted out.

Actionable Insights

Tight event-name and volume parity between cohorts during the staged rollout is the clearest signal the migration is safe to accelerate; any divergence there is worth resolving before increasing the Analytics-Kotlin rollout percentage, not after. A destination that stops receiving events — or starts receiving noticeably more — under the new SDK usually traces back to a filter or enrichment plugin that wasn’t reimplemented faithfully, and it’s far cheaper to catch that with a parity check than with a confused conversation with whichever team owns that downstream tool.

The duplicate-event rate during the transition window deserves its own alert threshold: it’s the failure mode most likely to inflate every metric that touches event counts, and the one most likely to go unnoticed until a stakeholder asks why numbers jumped for no obvious reason.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert