If you've updated your app's pricing since launch, some of your customers are probably still on an older pricing version, paying what they paid before you added features, expanded the value you deliver, or your investment in building and improving the app has grown significantly.
As a marketplace partner, you haven't had a way to move customers to your latest published pricing version. We're opening a beta for upgrading customers to your latest pricing version, a feature that automatically migrates customers on older pricing to your latest published version at their next subscription renewal.
How it works
When you create a new pricing version, you're asked to map each legacy pricing version to the corresponding plan in the new version. After that mapping is in place, customers on older pricing versions move to your latest published version at their monthly or yearly subscription renewal date. Each customer transitions on their own renewal schedule, so the new price applies at the start of their next billing period (not mid-cycle).
Customer notifications
Customers whose price is increasing receive an automated email notification sent to their account admins and designated billing contacts, 60 days before the new pricing takes effect. Customers whose price stays the same or decreases don't receive a notification.
For monthly subscriptions, the new price takes effect on the first monthly renewal date that allows the full 30-day notification window. For yearly subscriptions, price changes are scheduled for accounts whose renewal falls within a 60-day window; if a yearly account renews sooner than that window, the upgrade is applied at the following renewal cycle so they still receive the full notice period.
If your app has changed pricing model types, the migration behavior depends on the direction of the transition. A pricing model type is the billing structure your version uses, for example, feature-based pricing (charges tied to usage or tiers) versus seat-based pricing (charges tied to licenses).
Migration Logic
Automatic migration occurs for all customers on versions that share the same model type as your newly published version. Additionally, we now support automatic migration for customers moving from feature-based pricing to seat-based pricing.
However, the reverse scenario, moving from seat-based to feature-based pricing, is currently not supported. Customers on a seat-based version will remain on their current version if the new version is feature-based, until a supported path for that specific cross-model migration is released.
Example
Your app has six existing pricing versions: Versions 1-3 are feature-based, and Versions 4-6 are seat-based.
- If you publish Version 7 as seat-based: All subscribers on Versions 1-6 can be migrated to Version 7. This includes those on the same model (v4–6) and those transitioning from feature-to-seat (v1-3).
- If you publish Version 7 as feature-based: Only subscribers on Versions 1-3 (the same model type) can be migrated. Subscribers on seat-based versions (v4-6) will remain on their current version.
What to expect
Asking customers to pay more, even for an app that's grown significantly since they first subscribed, takes some adjustment and clear communication. Some will have questions, and the share of customers who push back depends on how many people are still on legacy pricing versions, your pricing delta, and your customer mix.
A subset may cancel or request a refund after receiving the notification or when the new price takes effect at renewal. That's part of re-pricing, and there are concrete ways to manage the transition.
A few things worth preparing for before you enable this:
- Churn will vary, and we'll help you understand it
How customers respond depends on your pricing delta, how long they've been on legacy pricing, and your customer mix. We don't have a universal benchmark yet, that’s part of what this beta is for. As patterns emerge, we'll share aggregated learnings with participants so you can compare signals (exact dashboards and metrics are still being defined for the beta). - Set up your discounts before enforcement starts
Discounts are tied to the plan SKU (appPlanId). If your new pricing version uses the same plan IDs, existing discounts carry over automatically. If the plan IDs change, you'll need to re-grant them via API or the Developer Center—ideally before the migration kicks in, so customers don't see a gap. Customers should see the discounted price reflected in their renewal path and notifications where applicable; if you grant discounts outside that flow, plan how you'll communicate the net price to avoid confusion. - Targeted discounts can reduce churn proactively
You can use our discount-granting functionality to offer price incentives to customers you think are at risk, before or after migration. [link to discounts announcement and docs] - Monitor notifications and webhook events
Use AMP and webhooks (covered in the technical documentation) to see which customers received pricing notifications and may be at higher risk, so you can follow up proactively.
Who can join
Your app must meet all three criteria:
- Pricing model: Your app uses the feature-based or new seat-based pricing model. (Link to the new pricing model announcement). If you're still on the legacy seat-based model, you can participate by publishing a new seat-based pricing version. Customers are mapped to the correct buckets in the new model (bucket sizes may differ from legacy tiers, which can change what customers pay and affect ARR). [link to seat-based pricing docs]
- Pricing history: You have at least two published pricing versions (your current live version and at least one older version)—a beta requirement so we can validate mapping flows—and you currently have active customers on a legacy version.
- Beta participation: You'll have a direct line to the team during the rollout, and your feedback shapes how the feature works at GA.
How to get started
1. Apply
Submit your application using this form, including your app ID so we can verify eligibility, enable the pricing mapping flow, and turn on the feature for your account.
2. Map your pricing versions
Once eligibility for beta participation is confirmed, we'll open the feature in your account. You'll create or publish your latest pricing version if needed, then map each legacy plan to the corresponding plan in that version using the Developer Center. This mapping tells the system how to move each customer.
3. Let us know you're ready
When mapping is complete, notify us. We'll review your setup and enable automatic migration for customers on legacy pricing, switching on the upgrade flow for your app after approval. [I will update them by email/slack message]
4. Keep us in the loop
After your new pricing version and the mapping from older versions have been approved by our review team and the upgrade flow is active, track how your customers respond and share what you're seeing, positive or negative. Your experience during the beta directly shapes how this feature works at GA.
Full technical documentation, including the webhook events your app will receive during migration and the customer email template will be shared with participants before your migration starts.
Ready to join? Apply now
