Почему разработчики задержались с импортозамещением СУБД?

Согласитесь, что несмотря на все предупреждения, такой реально осязаемой необходимости срочно переходить на отечественный софт, которая сложилась сегодня, не ожидали ни банки, ни разработчики.

Согласитесь, что несмотря на все предупреждения, такой реально осязаемой необходимости срочно переходить на отечественный софт, которая сложилась сегодня, не ожидали ни банки, ни разработчики.

Помню скепсис, с которым в 2020 году, когда доработанный проект Указа Президента Российской Федерации «О мерах по обеспечению информационной безопасности в экономической сфере при использовании программного обеспечения и оборудования на объектах критической информационной инфраструктуры» стал обсуждаться банковским сообществом, ИТ-руководители банков оценивали необходимость и возможности реализации самой идеи импортозамещения.

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

1. Во-первых, переход на новую СУБД предполагает очень большой пласт работ. Повторюсь, еще несколько лет назад банки не воспринимали импортозамещение всерьез. И все происходило по закону маркетинга: если у продукта отсутствует потенциальный потребитель, то вкладываться в разработку смысла нет. Задачу миграции ИТ-компании, конечно, исследовали, но двигаться не торопились.
2. Во-вторых, никто не ждал полного ухода с рынка иностранных поставщиков. Поэтому гипотетические проблемы импортозамещения СУБД планировали решать по мере поступления. Но они поступили слишком неожиданно.
3. В-третьих, до последнего времени, буквально до середины сентября, когда Кабинет Министров заявил о намерении директивно определить для каждой отрасли системы, подлежащие импортозамещению, и назначить им срок предельного перехода на отечественный софт, банки ориентировались на плавный сценарий перехода, когда иностранный софт заменяется на отечественный по мере истечения лицензий или завершения сроков амортизации ПО. Похоже, что реальный сценарий будет совсем другим.

Каким? 1-1,5 года? 3-5 лет? И в 10 не уложиться? Ваши прогнозы?