> Dating app migration plan | Dating API: https://www.datingapi.io/migration Product / Migration plan # Moving to DatingAPI. Planned, rehearsed, reversible. 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. [Ask about a pilot](https://www.datingapi.io/contact#preview) [Download the plan (PDF)](https://www.datingapi.io/assets/docs/DatingAPI-Migration-Plan.pdf) 6 to 10 weeks from pilot sign-off to switch day 1 live database at any time 2 full rehearsals before switch day 60 days to go back, at no charge How every move works ## Four rules. No surprises. Most of a good migration is preparation. By switch day almost everything has moved, been checked and been rehearsed twice. 01 ### See it first Your app, rebuilt on our platform, in your team's hands in TestFlight before you commit. 02 ### Heavy lifting first Everything before a cutoff date moves weeks ahead. Switch day moves only the last few days. 03 ### One live database An early bridge update lets every member be asked to update at the switch, so nothing needs keeping in sync. 04 ### Always a way back A stop point before every step, and your old system kept intact for 60 days after the switch. The timeline ## Switch day lands 6 to 10 weeks after pilot sign-off. The work runs side by side, so the switch waits only for the slowest part: usually the bridge update reaching enough members. Weeks after pilot sign-off Pilot Before week 1: your app rebuilt on DatingAPI, about two weeks to build and four weeks of testing. [Plan and paperwork Weeks 1 to 2 Weeks 1 to 2](#plan)[Bridge update Weeks 1 to 3 Weeks 1 to 3](#bridge)[Heavy transfer Weeks 2 to 5 Weeks 2 to 5](#transfer)[Photos and videos Weeks 2 to 6, or later Weeks 2 to 6, or later](#media)[Rehearsals and notices Weeks 4 to 9 Weeks 4 to 9](#rehearse)[Switch day window Week 6 to 10 Week 6 to 10](#switch) Aftercare After the switch: 30 days of close watch, the 60-day way back and 90 days of the performance promise. The idea that keeps switch day short ## One cutoff date. Two moves. 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. Before the switch ## Six steps, each with a check. What happens and when. Every step ends with a written check before the next one starts. 01 Pilot, weeks 1 to 6 ### See your app working - Rebuilt from your screens and brand, in TestFlight about two weeks after we have your materials. - Runs on our shared database with network members, so you see real activity. None of your data is needed. - Your video, ads and analytics connected; load tested at twice your peak. 02 Weeks 1 to 2 ### Plan and paperwork - A field-by-field data map and an agreed cutoff date. - Data processing agreement, US or EU hosting, privacy review. - A written runbook, named leads and a go or no-go owner on each side. 03 Weeks 1 to 3 ### Bridge update - Your team adds a remote update switch to your current app, from our specification. - We aim for 90% of active members on it before we set the date. 04 Weeks 2 to 5 ### Heavy transfer - Everything before the cutoff copied into your own ring-fenced database, in the region you choose. - Read from a replica, so your live app doesn't slow down. Encrypted, logged, time-limited access. - Counts and checksums on every table, and members sampled end to end. 05 Weeks 2 to 6, or later ### Photos and videos - Served from your storage or CDN, moved now, or moved later. You choose. 06 Weeks 4 to 9 ### Rehearse and tell people - Two full rehearsals of the freeze and final move, timed and checked. - Member notices and your updated privacy notice at least 30 days ahead. We draft them. - New app version approved by Apple and Google and held a week early. Step 03 in detail ## The bridge update. One small release that keeps the move clean. 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. - Built by your team from our short specification, and tested with us. - Can show an “upgrading soon” notice, switched on remotely. - A setting, not a release, so it can be undone in minutes before the new platform opens. - Members on very old versions get a “please update” reply, an email and a push message. Step 05 in detail ## Photos and videos. Move them when it suits you. 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. Switch day ## A rehearsed hour, not a leap. At your quietest hour, following the runbook we timed twice. Until the new platform opens, stopping means reopening the old one, with nothing lost. **30 days** ### Close watch A daily check-in, revenue reconciled daily against the stores, and a named engineer on call. **60 days** ### A way back Your old system stays intact. If you go back, we move new data across at no charge. **90 days** ### Performance promise On the measures we agreed at pilot sign-off. What moves ## Everything a member would miss. History before the cutoff moves weeks ahead; the rest follows on switch day. Data your retention policy says to delete stays behind. ### Accounts and sign-in Email, phone, Apple and Google sign-in. Most members stay signed in. ### Profiles and photos Every field, badge and photo setting. ### Likes, matches, blocks Both members' side of every connection. ### Messages Full history and read status. Older first, newest on switch day. ### Subscriptions Same store products and renewal dates. Credit balances too. ### Safety records Bans, reports and signals, so banned members can't return. ### Consents Unsubscribes and bounces, so nobody gets mail they opted out of. ### Age checks Keep existing status, or re-check on next visit. Your choice. ### Notifications Devices register again when the new version opens. For your CFO ## No lost revenue. Nobody pays twice. - Same App Store and Google Play listings, so subscriptions, renewals and reviews carry on. You stay the billing party. - Store payment notifications point at the platform at the switch; revenue is reconciled daily for 30 days. - Platform fees start on switch day. The $50,000 build covers the move and comes back as credit if you sign within 60 days of pilot sign-off. - For 90 days, if an agreed measure falls more than 10% for a month, you pay no paying-member fee that month. The move Included in the $50,000 build Platform fees From switch day Bridge update Your team Old system for 60 days You (read-only, can be scaled down) Moving media out of your cloud You, only if you move it For your CTO ## What could go wrong, and what we do. **Data arrives incomplete** Counts, checksums, member samples, two rehearsals. *Stop at go or no-go 3; the old platform reopens.* **Activity lost after the cutoff** The final move carries every new or changed record, including deletions and bans. *Stop at go or no-go 3.* **Old and new apps both writing** Bridge update switch; old platform read-only from the freeze. *Writes blocked at the server.* **App store review delay** New version approved and held a week early. *Only the date moves.* **Subscriptions not recognised** Checked after the switch; store notifications tested in rehearsal. *Restored from the store record the same day.* **A problem after launch** 30 days of close watch, engineer on call. *The 60-day way back, at no charge.* Go or no-go ## The switch goes ahead only when every box is ticked. And both decision makers, yours and ours, agree. - Accounts, subscriptions and safety records match exactly; 99.9% of everything else, every gap explained - Two full rehearsals passed - Sign-in and test purchases work on iOS, Android and web - A sample of 1,000 photos and videos loads - Load test at twice your peak passed - 90% of active members on the bridge update - New version held; notices sent; data processing agreement signed - On-call people named on both sides Who does what ## We do the moving. You make the calls. DatingAPI - Rebuild your app and connect your services - Write the data map, runbook and bridge specification - Run the transfer, the media move and the rehearsals - Draft member and privacy notices - Run switch day and 30 days of close watch Your team - Name a migration lead and a decision maker - Build and release the bridge update - Give read-only access to a replica, media storage and store accounts - Approve the notices and your privacy wording - Make each go or no-go call Website only No bridge update: we point your web address at the new site after the final move. API plan Your engineers point your app at our API; we still run the data move. Several brands One brand first, then the rest in turn, each with its own switch day. Migration questions ## What your CTO and CFO will ask. How long is the app unavailable? 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. Why force an update? 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. Will members have to sign in or subscribe again? 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. Will our members end up on other apps? No. Your ring-fenced database is private, and the shared network stays off until you switch it on, brand by brand. Who can see our data during the move? Only the named engineers on your move, with time-limited, logged access. What happens to our old system? It stays read-only for 60 days as the way back. Then you switch it off and we delete every working copy. Start with the pilot ## See your app working before anything moves. 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. [Ask about a pilot](https://www.datingapi.io/contact#preview) [Download the plan](https://www.datingapi.io/assets/docs/DatingAPI-Migration-Plan.pdf) - 1 **Free cost review** Your figures, a fixed quote and a dated plan. - 2 **Pilot** Your app on our platform, tested by your team for four weeks. - 3 **The move** 6 to 10 weeks later, rehearsed twice, with a way back.