Перенесём проект с Firebase

Переезд с Firebase на Payload CMS мы делаем так, чтобы пользователи вошли на новый портал со старыми логинами и паролями, все записи и файлы оказались на месте до дня переключения, а сам день переключения свёлся к смене адреса. Новый бэкенд живёт на сервере в России: Payload 3 внутри Next.js, база PostgreSQL, файлы на диске или в S3. В сентябре 2026 года мы так перевели портал гарантийных заявок ДС Энерджи, и ниже по шагам, как это устроено и что в переезде самое сложное.

Почему с Firebase уезжают в 2026 году

Не из-за блокировок, а из-за денег и лимитов. Бесплатный тариф Spark нельзя расширить: Blaze требует карту, а карты российских банков биллинг Google не принимает, новые аккаунты Google Cloud из России не регистрируются с марта 2022 года. Дальше по сервисам.

Почему Payload, а не другой аналог, мы разбирали отдельно на headless.expert/analog-firebase-v-rossii. Коротко: для веб-портала с ролями, формами и файлами Payload закрывает данные, авторизацию, файлы и админку одной кодовой базой. Актуальная версия на 30 сентября 2026 года Payload 3.90.

Что переносится и как

Данные из Firestore

Firestore хранит документы без схемы, в одной коллекции могут лежать записи с разным набором полей, вложенными объектами и массивами. Payload требует схему: коллекции и поля описываются кодом на TypeScript. Поэтому первый шаг это не скрипт, а таблица соответствия: какая коллекция Firestore становится какой коллекцией Payload, какие вложенные объекты превращаются в группы полей, какие в отдельные коллекции со связями, что вообще не нужно переносить.

Потом скрипт миграции: читает Firestore через Admin SDK, приводит записи к схеме и пишет в Payload через Local API. Ссылки между документами (в Firestore это обычно строки с id или поля-ссылки) превращаются в поля-связи Payload. Скрипт идемпотентный: его можно прогонять повторно перед переключением, чтобы дотянуть записи, появившиеся за время теста.

На портале ДС Энерджи так переехали гарантийные заявки сервисных центров с историей статусов. Комментарии, которые в старой системе жили в одном перезаписываемом поле, стали чатом по заявке: каждая реплика отдельная запись с автором и временем.

Файлы из Storage

Файлы выгружаются целиком и кладутся в коллекцию загрузок Payload с привязкой к тем же записям. Хранить их можно на диске сервера, а для больших объёмов в S3-совместимом хранилище российского провайдера через официальный адаптер @payloadcms/storage-s3. На портале ДС Энерджи это фото к каждой заявке (талон, акт, шильдик), без которых производитель не может проверить гарантийный случай, поэтому файлы переносились и сверялись по количеству с особой аккуратностью.

Если Storage у вас уже отвечает 402, выгрузка усложняется: нужен доступ к проекту с правами владельца и Admin SDK, через публичные ссылки файлы не отдаются. Чем раньше начать, тем проще.

Пользователи и пароли

Самое чувствительное место. Firebase Auth хранит пароли как хэши по своей модификации scrypt. Команда firebase auth:export отдаёт хэш и соль каждого пользователя, а параметры алгоритма (signer key, salt separator, rounds, memory cost) показываются в консоли Firebase в разделе Authentication, пункт Password Hash Parameters в меню над списком пользователей.

Мы переносим пользователей вместе с хэшами и проверяем старый хэш при входе через хук beforeLogin в коллекции пользователей Payload. При первом успешном входе пароль переписывается в родной формат Payload. Для человека это выглядит как обычный вход: те же логин и пароль, никаких писем "задайте новый пароль", которые до российских ящиков и так не доходили.

Что здесь обычно тормозит, по опыту: доступ к Google-аккаунту, на котором заведён проект Firebase (без него нельзя ни выгрузить пользователей, ни сбросить пароль владельца), и почта на корпоративном домене клиента, с которого будут уходить письма нового портала (DNS-записи, попадание в спам).

Письма

Уведомления и сброс пароля уходят с почтового ящика клиента через SMTP, а не с серверов Google. Для пользователей это самая заметная перемена: письма стали доходить.

Cloud Functions

Логика из функций переезжает в хуки коллекций Payload (перед сохранением, после изменения статуса) и в серверные эндпоинты внутри того же приложения. Здесь мы вместе с клиентом перечитываем каждую функцию, потому что часть из них давно никем не вызывается, а часть делает то, что нигде не задокументировано.

Пуши

FCM работает, но отправку мы выносим в свой модуль на бэкенде, чтобы приложение не ходило в Google напрямую. Смена транспорта на RuStore Push или сервис уведомлений Яндекс Облака тогда занимает день.

Как проходит переключение

1. Разворачиваем новый портал на сервере клиента рядом со старым, на своём адресе.
2. Прогоняем миграцию данных, файлов и пользователей. Сверяем количество записей и файлов по каждой коллекции.
3. Клиент тестирует новый портал параллельно со старым. Скрипт миграции время от времени дотягивает новые записи.
4. В день переключения: финальный прогон миграции, смена адреса, старый портал переводим в режим только для чтения.
5. Две недели после запуска следим за логами и чиним то, что всплывает.

На портале ДС Энерджи решение о переезде клиент принял в мае 2026 года, к концу июня данные, файлы и пользователи были перенесены, летом шло тестирование, боевое переключение прошло 17 сентября 2026 года. В день запуска ничего не переносили руками, один баг в форме создания пользователя нашли и починили в тот же день.

Что портал получает сверх переноса

Переезд редко бывает переносом один в один, потому что за годы на Firebase накапливается список того, что хотелось поменять. На ДС Энерджи вместе с переездом появились:

• роли менеджера производителя и сервисного центра с разными правами на уровне коллекций и полей, а не в коде фронта;
• статусы заявок с понятными переходами;
• обязательные фото на уровне схемы: заявку без талона и шильдика нельзя отправить;
• чат по заявке вместо одного поля с комментарием;
• мобильная версия и загрузка фото с камеры телефона, в Payload адаптивная админка и загрузка файлов есть из коробки, а для сервисных центров, которые заполняют заявку у котла, это оказалось важнее всего.

Часть рутины (сопоставление полей, скрипты миграции) делалась с помощью нейросетей под контролем разработчика, и по сравнению с оценкой, которую мы давали в 2025 году, срок заметно сократился.

Что нужно от вас для старта

• Доступ владельца к проекту Firebase (консоль и сервисный аккаунт для Admin SDK).
• Исходники фронта и Cloud Functions, если они есть.
• Сервер в России или согласие, что мы его подберём: обычного VPS с Docker хватает.
• Почтовый ящик на вашем домене для писем нового портала.

Сколько стоит

Цена зависит от четырёх вещей: число коллекций и вложенность данных, число пользователей и способ входа (пароль, телефон, соцсети), объём файлов, наличие и объём Cloud Functions. Мы смотрим проект и на следующий день называем срок и сумму. Хостинг после переезда это VPS в рублях без лимитов на чтения и записи.

Если у вас проект на Firebase, файлы уже не открываются или вы не хотите ждать, когда отвалится следующий сервис, напишите нам. Посмотрим базу, пользователей и функции и за день ответим, сколько займёт переезд и что для пользователей останется без изменений.