We copy your members across weeks before the switch, rehearse it twice, and keep a way back for 60 days. Your members just see an app update.
Most of a good migration is preparation. By switch day almost everything has moved, been checked and been rehearsed twice.
Your app, rebuilt on our platform, in your team's hands in TestFlight before you commit.
Everything before a cutoff date moves weeks ahead. Switch day moves only the last few days.
An early bridge update lets every member be asked to update at the switch, so nothing needs keeping in sync.
A stop point before every step, and your old system kept intact for 60 days after the switch.
The work runs side by side, so the switch waits only for the slowest part: usually the bridge update reaching enough members.
Message history is the biggest part of a dating app. We agree a cutoff a few days before the switch. Everything older moves weeks ahead; switch day moves only what was created or changed since.
We time the freeze in two rehearsals and set the cutoff to keep it short. The final move carries edits, deletions and bans as well as new records.
What happens and when. Every step ends with a written check before the next one starts.
Before the switch, your team ships an update to your current app with a remote update switch. On switch day we raise the lowest allowed version: every old copy asks to update, and nobody can write to the old database.
Media is usually most of your data, and copying it out of a cloud provider can be expensive. So you choose when, and whether, it moves.
Keeping media where it is means nothing to transfer: the app loads photos from your storage or CDN and everything else from DatingAPI. Approval and privacy settings carry over whichever you choose.
At your quietest hour, following the runbook we timed twice. Until the new platform opens, stopping means reopening the old one, with nothing lost.
A daily check-in, revenue reconciled daily against the stores, and a named engineer on call.
Your old system stays intact. If you go back, we move new data across at no charge.
On the measures we agreed at pilot sign-off.
History before the cutoff moves weeks ahead; the rest follows on switch day. Data your retention policy says to delete stays behind.
Email, phone, Apple and Google sign-in. Most members stay signed in.
Every field, badge and photo setting.
Both members' side of every connection.
Full history and read status. Older first, newest on switch day.
Same store products and renewal dates. Credit balances too.
Bans, reports and signals, so banned members can't return.
Unsubscribes and bounces, so nobody gets mail they opted out of.
Keep existing status, or re-check on next visit. Your choice.
Devices register again when the new version opens.
And both decision makers, yours and ours, agree.
It stays open but read-only during the freeze, at your quietest hour. We time it in the rehearsals and set the cutoff to keep it short.
Two live databases have to be kept in sync, which is where moves usually go wrong: duplicate messages, lost likes, double billing. One live database removes that risk.
Usually not. For most partners, members open the new version already signed in; anyone who isn't signs in again as normal. Subscriptions stay with Apple, Google and your payment provider.
No. Your ring-fenced database is private, and the shared network stays off until you switch it on, brand by brand.
Only the named engineers on your move, with time-limited, logged access.
It stays read-only for 60 days as the way back. Then you switch it off and we delete every working copy.
A $50,000 pilot puts your app on DatingAPI in TestFlight about two weeks after we have your materials, credited back in full if you go ahead.
