Visual Studio App Center: Fix Migration Issues & Retire Safely

The absolute first thing to do, before touching any pipeline or SDK, is document what you had. If you still have portal access, go to appcenter.ms, open each app, and screenshot or copy down every configuration: build branch settings, environment variables, signing certificate names, distribution group compositions, and any webhook URLs you had configured. You cannot re-import what you don't have on record.

For the Build service specifically, Microsoft built an Export feature before shutdown. If you used it while the portal was live, it would have produced a ZIP archive containing your build definitions and variable references. If you didn't do this in time, you'll need to recreate from memory or from your app's own repository, but the good news is Azure Pipelines uses YAML that you store directly in source control, so you won't lose it again.

For Analytics data, pull any historical reports you want to keep. The extended window to June 30, 2026 applies to ongoing data collection, but once that window closes, historical data in App Center's servers is gone. Export CSVs from the Analytics Overview page while you still can. Navigate to your app, click Analytics in the left rail, then look for the export option on each metrics view.

For Distribution, note every distribution group name and the email addresses in those groups. Recreating tester groups in TestFlight or Google Play Console is manual work, and if you have 50 or 200 external testers, you'll be glad you have that list.

If your portal login is already dead, you get a blank screen or an auth error, reach out to support@appcenter.ms before assuming the data is unrecoverable. Microsoft's support team was still handling data export requests for a transition period after retirement.

Azure Pipelines is the official recommended replacement for App Center Build, and honestly, it's more capable. The migration itself isn't a one-click job, but it's straightforward if you work through it methodically.

Start by creating an Azure DevOps organization at dev.azure.com if you don't already have one. Then create a new project. Link your GitHub, Azure Repos, Bitbucket, or other source repository under Project Settings > Service Connections. Once the connection is live, go to Pipelines > New Pipeline and select your repository. Azure DevOps will offer to auto-detect your project type and scaffold a starter YAML file.

For an iOS build that matches what App Center was doing, your pipeline YAML will look something like this:

trigger:
  - main

pool:
  vmImage: 'macos-latest'

steps:
  - task: InstallAppleCertificate@2
    inputs:
      certSecureFile: 'YourDistributionCert.p12'
      certPwd: '$(P12Password)'

  - task: InstallAppleProvisioningProfile@1
    inputs:
      provisioningProfileLocation: 'secureFiles'
      provProfileSecureFile: 'YourProfile.mobileprovision'

  - task: Xcode@5
    inputs:
      actions: 'build'
      scheme: 'YourSchemeName'
      sdk: 'iphoneos'
      configuration: 'Release'
      xcodeVersion: 'default'
      signingOption: 'manual'
      signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
      provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)'

Your signing certificates and provisioning profiles go into Azure Pipelines' Secure Files library under Pipelines > Library > Secure Files. Upload them there and reference them by filename in the YAML above. Once the pipeline runs green, confirm your IPA or APK artifact is being published correctly under the pipeline run's Artifacts section.

App Center's Distribute service had a tidy unified interface. Replacing it is a bit more fragmented because the replacement is platform-native, Apple for iOS, Google for Android, but each platform's native tooling is actually more powerful for what it's designed for.

For iOS production releases, your target is the Apple App Store via App Store Connect. For iOS test distribution, use TestFlight, which is built directly into App Store Connect. You can add internal testers (up to 100 from your Apple Developer team) and external testers (up to 10,000), no more hunting for a distribution group size limit. Navigate to appstoreconnect.apple.com, select your app, and use the TestFlight tab to create testing groups and add testers by email.

To automate TestFlight uploads from Azure Pipelines, use the AppStoreRelease@1 task:

- task: AppStoreRelease@1
  inputs:
    serviceEndpoint: 'AppleAppStoreConnection'
    appIdentifier: 'com.yourcompany.yourapp'
    appType: 'iOS'
    ipaPath: '$(Build.ArtifactStagingDirectory)/**/*.ipa'
    releaseTrack: 'TestFlight'
    shouldSkipWaitingForProcessing: true

For Android production and beta, use Google Play and Google Play Console respectively. Azure Pipelines has a GooglePlayRelease@4 task that handles the upload. You'll need a Google Play service account JSON key, which you generate under your Play Console's Setup > API access section.

For Windows / Microsoft Store apps, the recommendation is Partner Center's Package Flights feature for test distribution, it mirrors the beta testing concept from App Center. Microsoft Store developers also get access to analytics and diagnostics data directly through the Partner Center Dashboard, which is worth setting up before the App Center Analytics window closes.

This is the one that I've seen cause the most panic in React Native teams. If your app's over-the-air updates stopped working after March 31, 2025, CodePush is almost certainly the reason. Your app is still making update check requests to App Center's CodePush endpoint, and getting nothing back.

The fix is Microsoft's standalone CodePush server, which they specifically prepared for exactly this situation. The source code and full deployment documentation live on GitHub, search for "microsoft/code-push-server" to find the official repository. This isn't a community fork; Microsoft built and published this specifically as the migration path. Read the README carefully because it outlines both a Docker-based deployment and a manual Node.js deployment option.

At a high level, the migration process is:

1. Deploy the self-hosted CodePush server to your own infrastructure (Azure App Service works great here, and the setup docs reference it directly).
2. Update your React Native app's CodePush SDK configuration to point to your new server URL instead of the App Center endpoint.
3. Re-publish your JavaScript bundles to the new server using the CodePush CLI, pointing it at your server.
4. Release the updated app binary to your users through TestFlight or Google Play.

The SDK change in your React Native code is minimal, it's a server URL override in the CodePush configuration object. But step 4 is non-negotiable: until your users are on the binary that points to your new server, they cannot receive updates. So run both servers in parallel during the transition and don't decommission the old setup assumptions until your analytics confirm most users have updated.

One thing I want to call out: test your self-hosted server's update delivery on a real device on a cellular connection, not just Wi-Fi on a simulator. Network timeout and certificate errors show up in production that never appear in development.

You have until June 30, 2026 for this one, but "you have time" doesn't mean "you can ignore it." Every week you wait is another week of data going into a system you're about to lose. Start the migration now so you have overlapping data collection before you cut over, that overlap period is your safety net for validating that your new setup is capturing everything correctly.

Microsoft recommends three Azure Native ISV services for Analytics and Diagnostics replacement: Datadog, Dynatrace, and New Relic. All three have mobile SDKs that cover session tracking, event logging, crash reporting, and user metrics. The advantage of going through Azure Native ISV is that these tools integrate directly into your Azure subscription and can monitor your backend infrastructure alongside your mobile app, something App Center never did.

Additionally, Microsoft and the Azure Monitor team are actively building native mobile analytics support directly in Azure Monitor. The formal announcement for that will come separately, but the infrastructure work is happening in parallel with the extended App Center Analytics window. If you want to stay entirely within Microsoft's ecosystem, waiting to evaluate Azure Monitor's mobile support is a reasonable option, just don't wait past mid-2026 or you'll be doing an emergency migration.

To remove the App Center SDK from your app once you've switched, you'll reverse the SDK installation steps for your platform. For React Native:

# Remove App Center packages
npm uninstall appcenter appcenter-analytics appcenter-crashes

# Then remove the native linking artifacts
# iOS: remove AppCenter pods from Podfile, then pod install
# Android: remove AppCenter gradle dependencies and AppCenter.start() call

Verify your new analytics SDK is firing events correctly before removing App Center entirely. Check your new dashboard for the first 24 hours after adding the new SDK to confirm session starts, custom events, and crash reports are all appearing. Only then should you remove App Center's SDK in a subsequent release.