I've gone ahead and added these notes to the Sync v1 wiki page here: https://wiki.mozilla.org/User_Services/Sync/v1#Migration_strategy
We can change anything in there as needed, I just wanted to keep everything in the same place for now. I'll work on user stories for the "Migrating from Old Sync" section today/tomorrow and send those around for review when ready. Thanks! ~ d ----- Original Message ----- > Notes from today's migration meeting. > > In attendance: Asa, Deb, Karen, Crystal, Tauni, mfinkle, Lloyd, Warner, > ckarlof, myself, and I think I saw Vlad in the room. > > Strategy: > > * We want to encourage existing Sync users to migrate to a Firefox Account, > without harming the experience of users who aren't ready to move. > > * We're aiming for an overlap period between Sync and Sync.next. This will > reduce the risk of users having partitions in their devices, reduce problems > with upgrade/downgrades and staged releases, etc. The exact duration of this > overlap period will depend on several factors: complexity, cost, time to > market, and market parity. > > * Delayed upsell. We want to sell Sync.next and Firefox Account once users > are ready to upgrade -- that is, they have the right version of Firefox on > each of their devices. > > * Forcing function. As we ramp up, we'll remove the ability to set up an old > Sync account from each product. Eventually we will force users off the old > service and decommission it. See overlap period. > > > Migration mechanism: > > * Detect specific states. > * Non-email Sync account name. No migration possible. > * Single device. Encourage migration! No partitioning possible! > * Self-hosted. Offer to migrate to Mozilla's system if there's no locked > pref to indicate that that's not desirable, provide docs to support > continued self-hosting, inform the user of decommissioning plans so they > can make an informed choice. > > * Offer to set up a new Firefox Account using their same email address. Enter > the normal account setup flow, which will take care of email verification. > Don't reuse the password -- it's gone over the wire, many users won't > remember it, and it's probably neither strong nor memorable. > * Preserve data syncing preferences, also allowing user to make new decisions > at this point. > * Write decommissioning sentinel into the old Sync account. (Bug 895526, Bug > 895518.) > * Disable or delete local Sync.old account. > * Clean up local prefs for sanity. > * Configure to intercept old account hooks e.g., Send Tab intents. > > > Non-goals: > > * Migration of data. > * Simultaneous syncing to Sync.old and Sync.next. > > > Open issues and action items: > > * [lloyd] How long is the overlap period? Need to know some operational > costs. > * [rnewman, mfinkle] What's the client engineering burden to having an > overlap period? > * [rnewman] Send Tab isn't in the PICL IdP. We're trying to find out how > important a feature this is for parity. > * [product] We know we plan to disable the account setup UI during ramp-up. > At what point do we want to disable *login*, for those poor suckers who > reinstalled Windows and want to get their data back from Sync? > * [product] When should we kill the Sync promo on Android? Depends on how > valuable it is and how long our roadmap is for Sync.next. > * [?] Add-ons that provide sync engines will be screwed. > > > Original etherpad for notes: > > https://services.etherpad.mozilla.org/sync-migration > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
