iOS subscription product ID migration: what happens to existing subscribers and how to manage the switch

When you need to change iOS subscription product IDs — to restructure tiers, fix naming mistakes, or consolidate after an acquisition — existing subscribers don't automatically follow. This guide explains Apple's rules, what happens to active subscribers, and how to plan a clean migration.

At some point, most iOS subscription apps hit the same wall: a product ID that made sense when you shipped it no longer fits the product you've built. Maybe you restructured your tier names, merged two apps, corrected a typo in the product identifier, or changed your subscription architecture entirely. Whatever the reason, the problem is the same — App Store product IDs are permanent, and existing subscribers don't automatically follow you when you create new ones.

This post covers everything you need to know before you start a product ID migration: what Apple allows, what happens to subscribers on your old product, and how to design a migration path that minimises churn and confusion.

Why product ID changes happen

The most common triggers for a subscription product ID migration:

• Tier restructuring. You launched with three tiers and now want two (or vice versa). The pricing and entitlements are changing enough that a new product makes cleaner sense than patching the old one.
• Naming or namespace mistakes. A product ID like com.myapp.monthly_99 becomes embarrassing the moment you change the price. Product IDs are customer-facing in some contexts and team-visible in all of them.
• App acquisition or merger. You acquired another iOS app and want to consolidate subscribers under a single product family. Or you split one app into two and now subscribers are in the wrong place.
• Subscription group reorganisation. Moving products between subscription groups is not possible without creating new products. If you want different upgrade and downgrade paths, you'll need new product IDs.
• Consolidating entitlement logic. If you originally shipped a non-consumable lifetime purchase and later added recurring subscriptions, you might want to unify the access-granting code — which can require new subscription products in a structured group.

Apple's rules on product ID permanence

Apple's App Store Connect documentation makes the constraints clear. Once a subscription product is created, the product ID is permanent and cannot be changed. You can update the following after creation:

• Display names (per localisation)
• Descriptions (per localisation)
• Price tier (within Apple's tier table)
• Whether the product is active or "Developer Removed from Sale"

You cannot:

• Change the product ID string after creation
• Delete a product ID that has ever had a transaction
• Automatically move active subscribers from one product to another
• Merge or alias product IDs

When you "remove a product from sale" in App Store Connect, the product is retired from the storefront. New subscribers cannot sign up for it. However, existing active subscribers continue to renew at their current price and billing cycle indefinitely — until they cancel or the subscription lapses. Apple does not force existing subscribers off a retired product.

This is mostly good news — it means you won't accidentally churn your entire subscriber base by creating new products. But it also means you'll be running two product families in parallel for months or years while the old cohort winds down, which creates operational complexity in your analytics, entitlement logic, and customer support flows.

Understanding the migration scenarios

How you approach the migration depends heavily on whether your old and new products are in the same subscription group and whether you want to offer any pricing incentive to encourage subscribers to switch.

The same-group scenario is the most manageable. If your old and new subscription products are both in the same subscription group, a subscriber on the old product is already in a relationship with the group. They can upgrade or downgrade to the new product, and if they do so via a promotional offer, they can receive a discounted first period. Apple handles the proration logic automatically based on the relative position of the products in the group hierarchy.

The cross-group scenario is substantially harder. From Apple's perspective, a subscriber on product A in group 1 and a subscriber on product B in group 2 have no relationship. Moving someone from A to B means they cancel A and start a fresh subscription on B — with a potential coverage gap, with their trial eligibility potentially reset, and with no guarantee they'll actually complete the switch. RevenueCat's engineering documentation has noted that cross-group migrations are one of the leading sources of subscriber data fragmentation in production apps, because entitlement systems must track two entirely separate transaction histories for what is effectively the same subscriber.

How to migrate subscribers using subscription offers

For same-group migrations, the recommended approach uses Apple's promotional offer mechanism. Here's the general flow:

1. Create the new product in App Store Connect within the same subscription group as the old one. Set your new pricing tier and display name, and position the product correctly in the group upgrade hierarchy.
2. Retire the old product by setting it to "Developer Removed from Sale." New subscribers will no longer see it; existing subscribers are entirely unaffected and continue to renew normally.
3. Create a promotional offer on the new product — typically a free or heavily discounted first period. Promotional offers require an active subscription within the same group to be eligible, which your legacy subscribers satisfy automatically.
4. Surface the offer in-app with a signed SKPaymentDiscount (original StoreKit API) or by presenting the offer through the appropriate StoreKit 2 purchase flow. The offer signature must be generated server-side using your promotional offer key — never on device.
5. Track acceptance. In StoreKit 2, look for a Transaction.offerType of .promotional on incoming transactions. App Store Server Notifications will carry the offerIdentifier field in the signed transaction payload, letting your backend update its subscriber records in real time.

Research from Phiture on subscription lifecycle messaging suggests that in-app prompts delivered at high-engagement moments — the session after a user completes a core workflow, or just before their upcoming renewal date — produce meaningfully higher offer acceptance rates than background push notifications. A mid-session modal explaining the benefits of the new plan and the time-limited promotional pricing tends to outperform a generic "we've updated our plans" banner, particularly when it acknowledges that the subscriber's existing access is uninterrupted.

For cross-group migrations, offer codes are the most practical tool available. You can generate offer codes tied to your new product's introductory offer and distribute them via email or targeted push notification to subscribers on the old product. See our full guide to iOS subscription offer codes for the generation flow, redemption UX options, and the App Store Connect limits on code batches.

Running two product families in parallel

Regardless of how smoothly your migration campaign executes, you'll almost certainly have a tail of subscribers on the old product for an extended period. Some are on annual plans and won't see any migration prompt until their renewal. Others won't accept the promotional offer when it's shown. A few simply never open the app again but continue paying on the existing billing cycle.

Here's what you need to get right for the parallel-operation period:

• Entitlement logic. Your server — or your subscription SDK — must continue to grant access to the same features for subscribers on both the old and new product IDs. If you're using RevenueCat, Adapty, or Purchasely, this typically means adding the old product to your entitlement mapping and keeping it there indefinitely. See our comparison of iOS subscription management SDKs for how each handles multi-product entitlement mapping across a migration.
• Analytics segmentation. Your subscription dashboards should segment old-product and new-product subscribers separately, at least during the first 12 months. Mixing the cohorts will skew your churn and retention metrics because the old-product cohort has self-selected — it's composed of users who didn't accept the migration offer, which often correlates with lower engagement and higher eventual churn.
• Customer support scripts. Train your support team — or update your help centre — to explain why some users see one product name in their App Store subscription settings and others see a different one. Subscribers who notice a different product name than what your current paywall shows are a consistent source of "am I being charged correctly?" support tickets after a migration.
• Server notification routing. If your App Store Server Notifications handler uses the product ID to route events, make sure both the old and new product IDs flow correctly through your renewal, cancellation, and refund logic. A silent routing failure on the retired product can cause entitlement outages for long-tail subscribers.

Timing and communication

The migration offer window matters. Apple limits promotional offers to a fixed number of periods, set when you create the offer, and each offer ID can only be used once per subscriber. That means you get one organised campaign window per subscriber before the promotional pricing is exhausted — making your first in-app prompt the highest-leverage moment in the entire migration.

A practical calendar for a typical same-group migration:

• Week 1: Create the new product in App Store Connect, retire the old one, and configure the promotional offer. No user-facing communication yet — validate the StoreKit flow in sandbox first.
• Week 2: Ship an app update with the new paywall showing the new product. Include a contextual in-app prompt for existing subscribers explaining the promotional offer on the new plan.
• Week 4: Email or push follow-up to subscribers who haven't accepted, prioritising those with upcoming renewal dates on the old product — they have the most immediate reason to switch.
• Week 8: Final in-app reminder. After this point, let the old-product cohort wind down naturally over their remaining billing cycles.

Apple requires that subscription price increases go through a specific consent flow with mandatory user notification — covered in detail in our guide to raising iOS subscription prices without killing your renewal rate. Product ID migrations are handled differently: because you're not changing what existing subscribers pay, Apple's mandatory consent mechanism doesn't apply. The communication responsibility falls entirely on you, which is both a flexibility and a risk.

The flexibility: you can frame the migration however fits your product best — a feature upgrade, a simplification, a fresh start. The risk: if subscribers feel surprised or misled, the cancellation rate on the old product tends to spike in the weeks following the campaign, because confused subscribers often cancel before they investigate. Clear, proactive communication about what is changing and what is staying the same is the most reliable lever you have.

Sources and further reading

• Apple Developer: Subscriptions overview and developer resources
• Apple Developer Documentation: StoreKit In-App Purchase
• App Store Connect Help Center: Manage subscriptions and products
• RevenueCat Blog: Engineering and growth articles on iOS subscriptions
• Phiture Mobile Growth Stack: Lifecycle messaging and subscription growth research