Bumble
Match Group
Tinder
Hinge
Plenty of Fish
Meetic
EliteSingles
On this page · 8 sections
A dating app can move to new technology without losing members, but only if members barely notice the move. That means three things. Ship the new app as an update to the same App Store and Google Play listing, so reviews, ratings and installs stay put [1][2]. Carry over everything a member has built: profile, photos, matches, conversations, and the blocks and reports that keep them safe. And keep subscriptions inside the same app and subscription products, so renewals continue without anyone being asked to pay again [3].
Everything else in a migration is risk management: release in stages, keep a way back, and tell members what is changing before they see it. This guide sets out the rules from Apple's and Google's developer documentation, what the big groups have said about their own platform moves, and a checklist you can work through.
Keep the same listing and app identity
The single most expensive mistake is publishing the rebuilt app as a new app. A new listing starts with no ratings, no reviews and no installed base, and every existing member has to find it, download it and log in again.
The store rules make the case for staying put:
- Apple: the bundle ID "can't be changed once a build has been uploaded for the app" [1]. If the app moves between Apple developer accounts, for example to a new operating company, it keeps its bundle ID and "retains its reviews and ratings", and members keep receiving updates [1].
- Google: the package name is, in Google's words, "the unique identity of the application forever more", and an update signed with a different key is treated as a different application [6]. When an app moves between Play developer accounts, its members, ratings, reviews and subscriptions move with it, though orders created before the transfer stay in the original account [2].
- Sign in with Apple: member identifiers are tied to the developer team. If the app changes Apple account, you must generate a transfer identifier for each member through Apple's endpoint before the transfer, or those members cannot log back in to the same account [1].
So the rebuilt app should be a new version of the old one: same bundle ID, same package name, same signing key on Android, and the same login methods working on day one.
The data that must carry over
Members judge a migration by whether their stuff is still there. In dating, "stuff" is more than a profile.
| Data | Why members care | What to test before launch |
|---|---|---|
| Account and login | No re-registration, no new password | Every login method works: email, phone, Apple, Google |
| Profile and prompts | Hours of effort, often written carefully | Field mapping, character limits, emoji and other languages |
| Photos and their order | The first thing other members see | Order, cropping, verified photo badges kept |
| Verification status | Members paid for or worked for it | ID and photo verification flags carried, not reset |
| Matches and likes | The current pipeline of people | Counts match old system per member |
| Conversations | Ongoing chats and shared history | Full history, read status, media in messages |
| Blocks | Safety: blocked people must stay blocked | Zero blocked pairs able to see each other |
| Reports and moderation history | Bans and warnings must persist | Banned accounts stay banned, notes kept for moderators |
| Preferences and settings | Distance, age range, notifications | Defaults not silently reset |
| Subscription and purchase state | Paying members keep what they paid for | Entitlements match store records for every payer |
Blocks and reports deserve special care. A migration that drops a block list can put a member back in front of someone they blocked for a reason. Treat any mismatch in blocks or bans as a launch blocker, not a bug to fix later.
A practical method is to run a full copy of the data into the new system weeks before launch, then reconcile counts per member: matches, messages, blocks and entitlements. Repeat until the numbers agree, then run a final incremental sync at cutover.
Subscriptions: the continuity rules
Subscriptions are where a migration can lose money quietly. The rules differ slightly by store.
On the App Store, subscriptions belong to subscription groups inside an app, and "days of paid service are specific to each subscription group" [3]. That matters because Apple's proceeds rate rises to 85% after a subscriber has a year of paid service [3]. If you keep the same app and the same group, renewals carry on and that year of paid service keeps counting. If you create a new group, or a new app, members who resubscribe start again: Apple notes that cancelling in one group and buying in another resets the renewal date and the days of paid service [3].
Apple has no button that moves a live subscriber from one app to another. Its own guidance for an app you are sunsetting is to "distribute one-time-use codes" in the old app to move subscribers across to the new one [3]. That is a workaround, and every member who has to act is a member who might not.
Two other Apple rules are worth building around. Failed renewals are retried for 60 days, and you can turn on a billing grace period so members keep access while a payment issue is fixed [3]. And if the migration includes a price rise, some increases require subscribers to opt in, and those who do not agree lapse at the end of their billing period [3]. Do not combine a platform migration with a price change.
On Google Play, subscriptions are tied to the app, and they move with it in an account transfer [2]. Keep the same subscription product IDs in the new app so existing purchases are recognised.
The test before launch is simple: for every paying member, the new backend's view of their entitlement must match what Apple and Google report.
Staged rollout and a way back
Both stores let you release an update to a share of members first.
| App Store phased release | Google Play staged rollout | |
|---|---|---|
| Who gets it | Random sample with automatic updates on | Random share of devices |
| Schedule | 1%, 2%, 5%, 10%, 20%, 50%, then 100% over seven days | Percentage you set, raised by hand |
| Pause or halt | Pause up to 30 days in total | Halt: no further devices get it |
| Catches | Anyone can still download it manually | Can't remove countries once started; updated devices keep the version |
Source: Apple [4], Google [5].
Neither store has a true rollback. Devices that already updated keep the new version, and Google's advice is to fix forward with a new release [5]. So the real way back has to live on your side:
- Run old and new backends in parallel until the new one is proven. Bumble's chief financial officer said its move to a new platform meant "some duplication of costs for a portion of 2026" [9]. Budget for it.
- Keep the API backward-compatible, so the old app version keeps working if you need to slow down.
- Put risky features behind server-side switches, so you can turn them off without a store release.
- Watch the right numbers daily during rollout: crash rate, login failures, messages sent per active member, purchase success and support tickets.
What the big groups have said
Platform migrations are now routine at the largest operators, which gives a useful reference point for timing.
- Match Group said in February 2025 that its E&E brands, the group of brands outside Tinder and Hinge, planned to complete "platform consolidation efforts in 2025", with Salams due to migrate to the shared platform by the end of the second quarter and Plenty of Fish and Meetic later in the year [7]. By August 2026 it reported: "With the major platform migrations now complete, the portfolio has a stronger foundation to execute from" [8].
- Bumble said in March 2026 that it was "rearchitecting the entire Bumble experience" on "a fully new platform", and that rolling the new version out to all members would be "a multi-week thing, not a multi-month thing" [9]. In August 2026 its chief executive said it was "completing our platform migration" [10].
- EliteSingles is the counter-example. After it closed and relaunched under a new owner, the new service ran on "an independent member database", so members could not necessarily carry over accounts or connections [11]. That is what a migration without data continuity looks like from the member's side.
Tell members before they see it
Members tolerate change much better when they are told about it first.
- Two weeks before: an in-app message and email saying a new version is coming, what stays the same (matches, chats, subscription) and what will look different.
- On update: a short first-run screen in the new app, not a long tour.
- For payers: a separate note confirming their subscription continues with nothing to do.
- For support: a script and a known-issues list, and extra staff for the first two weeks.
Keep a feedback route in the app during rollout. Early complaints are the cheapest warning you will get.
Migration checklist
| Stage | Check | Done when |
|---|---|---|
| Plan | Same bundle ID, package name and signing key | Confirmed in App Store Connect and Play Console |
| Plan | Sign in with Apple transfer plan, if changing accounts | Transfer identifiers generated |
| Data | Full trial migration | Per-member counts reconcile |
| Data | Blocks, bans and reports | Zero mismatches |
| Payments | Same subscription groups and product IDs | Entitlements match store records |
| Payments | Billing grace period on, no price change | Settings checked |
| Release | Phased release and staged rollout set up | First stage live to a small share |
| Release | Old backend running, API backward-compatible | Old app version still works |
| Release | Server-side switches for new features | Tested on and off |
| Members | Pre-launch messages and payer note | Sent |
| After | Daily dashboard for crashes, logins, messages, purchases | Stable for two weeks after full release |
Questions
Can I keep my App Store listing when I rebuild my dating app?
Yes, if you ship the new app as an update to the existing app record. The bundle ID can't be changed once a build has been uploaded, and an app transferred between Apple accounts keeps its bundle ID, reviews and ratings.
Do subscriptions carry over when a dating app is rebuilt?
They do when the rebuilt app is an update to the same app and uses the same subscription products. Apple's own guidance for an app being sunset is to give subscribers offer codes to move them to the new app, which shows a separate app does not inherit them.
How long does an App Store phased release take?
Seven days, rising from 1% of automatic-update members on day one to 100% on day seven. You can pause for up to 30 days in total.
Can I roll back a Google Play release?
You can halt a staged rollout so no more devices receive it, but devices that already updated stay on that version. Google advises a new release with a fixed bundle.
