Вопросы импортозамещения касаются нас часто, как интегратора и известной своим опытом команды.

Но часто вопросы ставятся перед нами некорректные, по причине недальновидности частичного замещения ПО.

Давайте рассмотрим два постулата:

1. переезд всей рабочей ИТ-среды разом не может быть моментальным - не получиться здесь и сразу в день "П"  отказаться.
   например, от vmware, microsoft и veeam, просто переключившись на подготовленное кошерное ПО. Не получиться потому, что потребуется конвертация данных.
2. частичное замещение учитывает ТЕКУЩИЕ ИТ решения, но не факт, что покрывает будущие изменения/замены текущих ИТ решений. Например, системы резервного копирования которую заменили с проприетарной на open source Bacula может быть подобрана и оправдана, и даже прекрасно  настроена на резервное копирование баз данных среды виртуализации hyper-v. Но при переезде через полгода среды виртуализации на open source ovirt - внедрение и переезд на эту систему резервного копирования окажутся безполезными, и повторно придется решать задачу подбора софта под изменяющиеся инфраструктуры.

Часто, смотря на заменяемую часть в своей неизменной инфраструктуре, заказчики не учитывают, что решения которыми мы "заткнём дыры" и переедем в состоянии как есть с изменением лишь части ИТ-инфраструктуры, окажутся нерабочими при переезде остальной части ит инфраструктуры на новый свободный софт. И это ошибка планирования.

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

1. NetBackup, BE, Veeam, Acronis как примеры виртуализации
2. Hyper-V, RHEL virtualization, VmWare как примеры виртуализации
3. MS SQL, Oracle DB, IBM DB2 как примеры СУБД
4. MS Windows, Debian base, RHEL... как примеры ОС

итд.

Все они при единичной замене одного элемента в разнородной ИТ среде могут быть заменены на OpenSource решения. 

У OpenSource решений был задел на конкуренцию и работу с... ЭТИМИ ПРОПРИЕТАРНЫМИ СИСТЕМАМИ от больших вендоров: все лезли, чтобы стать частью коммерческого Enterprise сегмента. И никак не было интереса "точить" под другой open source, который редко когда использовался массово и в коммерции.

У OpenSource решений, за редким исключением, нету хорошей совместимости с другими OpenSource решениями, ввиду заточки друг друга под коммерческие продукты и существенно меньшего финансирования этих проектов в сравнении с коммерческими продуктами.

У всех - коммерческих и коммерческих ОТЕЧЕСТВЕННЫХ, opensource,  - есть плагины, лицензии итд... Но сейчас время такое, что и при желании не все могут позволить купить и продлить себе лицензию, а некоторые лицензии при изменении составляющих системы с канонично сложенных оказываются безполезны. Поэтому когда систему резервного копирования хотят заменить на Open Source, нужно понимать, что при замене, например, системы резервного копирования, нужно учитывать не только и не сколько то, что сейчас объекты резервного копирования живут в vmware, а то, что 

1. Сейчас объекты будут жить в vmware 
2. А условно "завтра" будут смигрированы в oVirt или ProxMOX, где решение принятое ранее будет неуместно.

И это понимание (в данном примере, намерено введена провокационная ошибка в планировании) в корни меняет подход к постановке задачи и порядок рассмотрения аспектов в переезде своей ИТ-инфраструктуры.

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

Я показал в этой заметке основную проблему в подходе, подробнее развитие ожидайте в будущих статьях.
 

За консультациями и помощью в переезде на open source и отечественное ПО с проприетарного обращайтесь к нам , а также за обучением Astra-linux и типовым решениям.