# CodePush alternatives and Pakta migration

Compare standalone CodePush, EAS Update and Pakta after App Center retirement. Plan SDK replacement, native releases, targeting and recovery.

## What replaces App Center CodePush? {#answer}

Pakta is a React Native OTA option for teams willing to replace their update SDK and ship a new native build. It is not a drop-in CodePush server: `rn-update`, `.ppk` artifacts and Pakta application/channel targeting use a different integration contract. Existing CodePush binaries cannot receive Pakta updates just by changing a deployment key.

Microsoft retired App Center CodePush on March 31, 2025. Microsoft also published a standalone server, so the hosted-service retirement does not mean all CodePush-based options disappeared. See the [retirement notice](https://learn.microsoft.com/en-us/appcenter/retirement) and [standalone CodePush server](https://github.com/microsoft/code-push-server).

## Compare migration paths {#options}

| Path | What changes | What to validate |
| --- | --- | --- |
| Standalone CodePush | Hosting, endpoint and potentially client configuration | Server operations and exact SDK/runtime compatibility |
| Expo EAS Update | Move to `expo-updates` and the EAS workflow | Native integration, runtime versions and channels |
| Pakta | Move to `rn-update`, register native baselines and publish `.ppk` updates | Native integration, target identity and device recovery |

Microsoft's original [React Native CodePush repository](https://github.com/microsoft/react-native-code-push) is archived and states that it does not support the New Architecture. Check the exact fork and version if retaining a CodePush client. For the Expo path, use [Expo's migration guide](https://docs.expo.dev/eas-update/codepush/).

## Map concepts before changing code {#mapping}

| CodePush concept | Pakta workflow | Migration consequence |
| --- | --- | --- |
| Deployment key | Application `appKey` plus native channel identity | Credentials and identifiers cannot be reused |
| Target binary version | Registered native package and channel/version target | Register the exact new installer first |
| Release bundle | CLI-generated `.ppk` | Rebuild from source; do not upload old CodePush artifacts |
| Install mode and readiness notification | Update strategy and health confirmation | Recheck activation and startup health behavior |
| Rollout and rollback | Target percentage and recovery deployment | Test device behavior, not just console state |

This is a workflow mapping, not API compatibility. Read [SDK integration](/docs/integration) and [channels](/docs/channels) for the actual contracts.

## Migrate to Pakta in stages {#migration}

1. Inventory your React Native version, native modules, Hermes configuration, installed binary versions, deployment keys and startup hooks. Retain the source and sourcemaps of the last stable release.
2. On a migration branch, remove CodePush's JavaScript wrapper and native bundle-loading integration. Follow [Pakta native setup](/docs/getting-started) or [Expo setup](/docs/expo). Give one update system ownership of bundle selection.
3. Create Pakta applications for the target platforms. Configure an internal native channel and connect the root provider, activation strategy and [health confirmation](/docs/integration#health).
4. Build and install a new Release binary. Register that exact APK/IPA as described in [first release](/docs/publish#register-native).
5. Publish a one-label update to the internal channel. Verify the update hash, cold startup, offline startup and recovery to a stable package.
6. Distribute the new native build through your normal release process. Track adoption separately from the old CodePush population, then gradually publish compatible Pakta updates.

## What happens to existing installations? {#existing-users}

An app that only contains CodePush still needs a native upgrade to include `rn-update`. Do not count those devices as eligible for Pakta releases. Keep an explicit plan for users who have not upgraded, including the supported recovery route available to their installed binary.

Cancelling a Pakta rollout does not remove updates already installed. See [recovery behavior](/docs/channels#lifecycle) before the first production deployment.

## How should you decide? {#next}

Preserving a client protocol, adopting Expo's update ecosystem and choosing Pakta's release workflow are different requirements. Verify one Release build end to end before migrating production. Continue with [React Native OTA fundamentals](/docs/react-native-ota-update), [Expo Updates vs Pakta](/docs/expo-updates-vs-pakta) or [Quick start](/docs/introduction).