Docs

App Center Analytics Migration Tracking

How to track telemetry continuity as Visual Studio App Center's Analytics and Diagnostics wind down and teams migrate to a new SDK.

Analytics

Visual Studio App Center’s core services were retired back in March 2025, but Analytics and Diagnostics were given a stay of execution — support that’s now scheduled to end, pushing every team still on App Center toward a hard migration deadline. If your crash reporting and session telemetry have been quietly running on App Center for years, this isn’t a minor SDK bump. It’s a full swap of your event pipeline, and if it’s handled casually, you lose weeks of comparable historical data right when you need continuity most.

The real danger isn’t the migration itself — it’s the gap it creates. Teams that cut over to Firebase, Mixpanel, Amplitude, or Azure Monitor’s new mobile solution without running both SDKs in parallel end up with a broken time series: pre-migration data in one format, post-migration data in another, and no reliable way to compare retention or crash-free rates across the cutover date.

Data Points to Track

  • SDK source tag: an explicit property on every event (sdk_source: app_center vs sdk_source: firebase) so dashboards can filter out the transition period from trend calculations
  • Parallel-send confirmation rate: percentage of sessions successfully reporting to both the old and new SDK during the overlap window
  • Crash-free session rate, split by SDK: tracked separately per source until you’re confident the new pipeline matches App Center’s historical baseline
  • Event schema mapping gaps: any custom App Center events or properties that don’t have a direct equivalent in the destination tool
  • Cutover date and build number: stamped in a config or remote-config flag so any anomaly can be traced back to the exact release that switched SDKs

Setup Steps

  1. Inventory every App Center Analytics and Diagnostics call in the codebase, including custom event properties and crash handler hooks, before touching any code.
  2. Pick a destination — Firebase, Mixpanel, Amplitude, or Azure Monitor’s mobile solution — based on which one your team already uses elsewhere, to avoid running a third telemetry stack indefinitely.
  3. Run both SDKs in parallel for at least one full release cycle, tagging every event with its source so you can validate the new pipeline against the old before removing App Center calls.
  4. Rebuild crash-free rate, session count, and retention dashboards against the new SDK’s data model, since field names and session-boundary definitions rarely match exactly.
  5. Set a hard removal date for the App Center SDK in your release calendar so the parallel-tracking period doesn’t quietly become permanent.

Actionable Insights

The parallel-run period is where you actually learn whether your new analytics setup is trustworthy — not after you’ve deleted the old SDK. Comparing crash-free rates and session counts side by side during the overlap tells you whether the new pipeline is under- or over-counting relative to what App Center reported, and catches schema gaps (a custom event that silently stopped firing, for instance) while there’s still time to fix them without a permanent hole in your historical data.

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