Міграція з Auth0 без виходу всіх користувачів з системи
Від Команда Alt Auth
Причина, з якої команди залишаються на постачальнику автентифікації, з яким переросли, рідко стосується продукту. Це міграція: страх вікна обслуговування, розсилки скидання пароля кожному клієнту, зламаної забутої інтеграції в п’ятницю. Цей страх здебільшого безпідставний, якщо перехід проведено поетапно.
Етап перший: подвійний запис, одиночне читання
Почніть зі створення кожного користувача в новій системі, коли він автентифікується у старій. Ваш застосунок і далі довіряє старому провайдеру; новий тим часом непомітно накопичує ідентичну таблицю користувачів. Після одного повного циклу оплати ви охопите переважну більшість активних користувачів, і жоден з них цього навіть не помітить.
Етап другий: перемкніть шлях читання
Спрямуйте нові сесії до нового провайдера, залишивши старого як резервний для всіх, кого ще не перенесено. Оскільки обидва видають підписані токени, ваш застосунок може перевіряти будь-який з них під час перекриття. Це єдиний справді ризикований крок, і його можна відкотити однією зміною конфігурації.
Етап третій: доопрацюйте хвіст
- Експортуйте решту неактивних акаунтів і імпортуйте їх через CSV.
- Ці користувачі під час першого повернення пройдуть відновлення пароля — звичайний потік, а не масовий лист зі скиданням.
- Тримайте старий тенант живим, лише для читання, ще один цикл перед скасуванням.
- І тільки тоді видаліть резервний шлях перевірки з вашого застосунку.
Уся послідовність виконується у фоновому режимі протягом тижнів. Немає вікна обслуговування, немає листа всім клієнтам і немає моменту, коли вхід зривається через перемикання посеред запиту.