Можно ли потом сменить подрядчика по разработке?

Обычно да, и стоимость различается на порядок в зависимости от уже принятых решений. Определяет её не код. Определяют её то, у кого аккаунты, можно ли выгрузить данные в пригодном виде, способен ли кто-то за пределами текущей команды развернуть систему и написано ли в договоре, что происходит при выходе. Закройте эти четыре вопроса сейчас — и вопрос перестанет быть страшным.

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

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

Установите, чем вы уже управляете

Репозиторий, облако, домен, выгрузка базы, резервные копии, сторонние аккаунты. Здесь весь вопрос в одну строку: то, чем вы управляете, — это то, что останется у вас без переговоров.

Проверьте выгрузку до того, как она понадобится

Сделайте полную выгрузку и восстановите её в другом месте. Выгрузка, которую ни разу не восстанавливали, не говорит ни о чём, а выяснять это в момент перехода — худшее время из возможных.

Выясните, может ли систему запустить кто-то ещё

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

Прочитайте тот пункт о выходе, который у вас есть

Сроки уведомления, что передаётся, за какие деньги и что происходит с поддержкой в переходный период. Если пункта нет — это и есть ответ, и узнать его лучше заранее.

Сначала данные, потом функциональность

Пользователи, балансы, транзакции, документы, права, история изменений. Что должно переехать, что можно заархивировать, как это будет сверяться и что обязано сохраняться по закону.

Перечислите все интеграции и их владельцев

Идентификация, платежи, выплаты, банк, отчётность. У каждой — свой аккаунт, свой договор и своё повторное подключение. Сроки обычно задают интеграции, а не код.

Решите, какая непрерывность вам действительно нужна

Выходные в режиме чтения, поэтапный переезд или период параллельной работы. У каждого варианта своя цена, и это требование должно быть решением бизнеса, принятым заранее, а не следствием того, что получилось при переходе.

Спланируйте переключение, включая возврат назад

Определённая последовательность, шаг сверки, критерии приёмки и откат, продуманный тогда, когда думать о нём ещё дёшево.

• Насколько заметной окажется замена, зависит от исходной системы, данных, интеграций и операционных ограничений. Никто не может назвать результат, не изучив их, а требования к непрерывности закрываются планированием миграции и переключения, а не обещанием исхода.
• Часть зависимостей действительно нельзя перенести: проприетарный компонент, отношения с провайдером, оформленные на подрядчика, лицензия, которая не передаётся. Раннее обнаружение меняет план, а не отменяет его.
• Здесь описано, что нужно выяснить. Это не юридическая консультация, и то, на что вы имеете право, определяет ваш договор.
• FinMV поддерживает проекты замены, в которых может потребоваться перенос пользователей, проектов или инвестиций, данных и интеграций. Объём миграции и способ переключения определяются для конкретной исходной системы.