...а не к успешному импортозамещению.

При таком «рывке» игнорируется целая сеть зависимостей, которые работают только в связке. Да, я опять о том, что ИС не ограничивается ИС.

‼️Основные пробдемы:

1. Виртуальное «железо» меняется. Когда на ВМ ставится новая ОС, гипервизор по-своему эмулирует оборудование: тип дискового контроллера, сетевой адаптер, режим загрузки (BIOS/UEFI). Старая ОС «знает» одно вирт железо, а новая может не иметь нужных драйверов «из коробки». Пример: после смены гипервизора система не видит диск (ошибка INACCESSIBLE_BOOT_DEVICE), потому что в ней нет драйвера для нового вирт контроллера. Проблему можно решить установкой драйверов внутри новой ОС, но это требует анализа и времени.

2. Сетевые настройки ломаются. Внутри ВМ могут быть жёстко прописаны статические IP, имена сетевых интерфейсов, правила фаервола, настройки VLAN. После замены ОС эти настройки могут перестать работать: трафик не пойдёт, сервисы станут недоступны. Иногда проблема кроется глубже — в политиках сетевого оборудования хоста или в конфликте MAC-адресов.

3. Загрузчик и низкоуровневые вещи. Процесс загрузки (загрузчик, initramfs, параметры ядра) часто специфичен для комбинации ОС и вирт окружения. После замены ОС этот процесс может сломаться, и система не загрузится.

4. Приложения связаны с инфраструктурой. ОС — это лишь часть картины. Приложения, базы данных, системы мониторинга, политики безопасности (антивирусы, агенты ИБ) настроены под конкретную среду. После замены ОС они могут перестать корректно работать: приложение не найдёт нужные библиотеки, СУБД начнёт вести себя непредсказуемо. Перенесли одну виртуальную машину, а она не видит базу данных, потому что та осталась на старой инфраструктуре))

5. Лицензии и привязки. Некоторые лицензии ПО внутри ВМ привязаны к аппаратным идентификаторам (MAC-адрес, серийный номер виртуального диска, CPU ID). После замены ОС и смены вирт оборудования лицензия может «слететь», и ПО потребует переактивации. Аппаратные ключи (HASP, USB-донглы) нужно отдельно пробрасывать в виртуальную среду.

6. Отсутствие плана отката. Если сделать всё «в одну ночь» и что-то пойдёт не так, отступить будет сложно. Без заранее подготовленных снэпшотов\полных резервных копий вернуть всё назад быстро не получится.

7. Скрытые нюансы платформы. Новая ОС может быть сертифицирована для работы с конкретными российскими платформами виртуализации, и просто «воткнуть» её в старую зарубежную среду не выйдет — могут быть проблемы с совместимостью.

Пример: обновление ночью, когда "никто не работает", потому что "очень надо". Поставили новую ОС, приложения запустились. Утром выяснилось, что новая ОС по-другому настроила фаервол, и база данных перестала видеть сервер приложений. Ну или новая ОС не подхватила аппаратный ключ защиты, без которого программа просто не запускается. Итог: полдня простоя, куча ора и поиск старого образа, чтобы откатиться. И ладно, если он нормально встал, и если он был сделан ночью, когда в системе уже не создавались новые документы. В противном случае часть данных потеряется.

Чтобы импортозаместить ОС, нужен отдельный прям проект: 👉Провести аудит: выписать зависимости (приложения, сети, хранилища,лицензии). 👉Создать тестовую среду, отработать миграцию на тесте. Сделать это на некритичных системах не выйдет: системы очень разные и то, что пошло на одной - не факт, что пойдет на другой. 👉Подготовить план: какие драйверы установить, какие сетевые настройки скорректировать, как обработать лицензии. 👉Обеспечить механизм быстрого отката. 👉После запуска новой ОС тщательно проверить работу всех сервисов.

Именно такой путь показан в моей статье Инфраструктурный проект в критической информационной системе: Манифест интегративного управления ИС. Zenodo. https://doi.org/10.5281/zenodo.23666255

🥶Поэтому если разработчику предлагают вставить в договор на техническую поддержку ИС третьего уровня пункт об импортозамещении в качестве одного из вида работ - это пат и для разработчика (который физически не сможет это сделать), и для владельца системы (который с большой вероятностью потеряет данные).