Лев

Сначала делаем backup.
При наличии root доступа штатно linux переносится даже простым tar!

Хостер может добавить своих утилит, свои скрипты и особенности настройки сети, свой способ загрузки (например нет /boot а загрузка ядра и initramfs идет 'снаружи'), это все в принципе восстанавливается, скрипты хостера чистятся и т.п... в основном только тут могут быть проблемы но все просто решается.

Затем восстановление - и тут могут быть проблемы.
Универсально все будет работать только с не openvz/lxc/docker системами виртуализации, так как такие могут тупо не позволить работать с версиями системных библиотек (очень редко), отличных от хоста... а у тебя древняя ubuntu (я запускал в chroot просто утилиты, развернув образ с помощью debootstrap еще до появления docker, так что технически шансы проблем - минимальны). Дело в том что хостер может запретить, а точнее не дать инструментов для подмены системных файлов, а из самой работающей системы заменить ее саму нельзя (очень сложно).

p.s. я помню, поднимал систему, загрузив ее внутри user mode linux на машине даже без админовских прав, каскадно на системе с openvz (по умолчанию может не хватать некоторых модулей ядра, особенно для настроек сети, но там все решаемо), народ забыл про этот способ контейниризации без наличия аппаратной поддержки виртуализации, но она есть, старейшая, мощнейшая и удобнейшая из всех (по поводу производительности спорно - числодробилки быстро, но системные вызовы медленее)
--------------

Если виртуальная машина kvm/vbox/vmware/... то проблем не будет от слова совсем. Чтобы развернуть бакап, понадобится на новом месте загрузиться в консоль восстановления (лучше с iso образа), отформатировать файловую систему и тупо распаковать архив с бакапом (обычно /dev в архив не складывают, но если его не будет на новой системе то я помню старые версии ubuntu ругались на отсутствие null, это все решается ручным копированием тут же), затем переустановить загрузчик

grub-install /dev/sdX --root-directory=/path/to/mounted/root/

Ну и само собой архитектура исходной машины и новой должны совпадать, т.е. нельзя смешивать ни тип процессора (x86/arm ни битность x86/x64), правда особых проблем с запуском x86 на x64 быть не должно.

Перенос установленной винды с железа на виртуалку все равно, что перенос харда с виндой с одной машины на другую: часто грузится без проблем (машины одинаковых поколений + доля везения), но иногда сваливается в BSOD. Причина - набор драйверов и их настройки заточены под конкретное железо, а без необходимых драйверов система не может загрузиться. В общем случае Windows предполагает загрузку только на том железе, на которое ставилась.

Настройки виртуалки крутил по-разному.

Типичные решения (в порядке убывания вероятности):

1. Storage -> Controller: SATA заменить на Controller: IDE.
   
2. System -> Enable I/O APIC выключить или включить.
   

Гораздо менее вероятно, но стоит попробовать:

1. System -> Chipset: сменить.
   
2. Storage -> Attributes -> Type: сменить.
   

Посмотри по коду ошибки BSOD, может что-то прояснится. На настоящем компе в первую очередь IDE-AHCI смотреть в БИОС надо, на виртуалке может тоже переключить где-то надо их. Без кода ошибки ничего сказать нельзя.

Есть идея переснять образ системы, на виртуальный диск формата .vmdk, То есть сперва создать такой диск, затем на него с помощью утилиты, к примеру: www.macrium.com/reflectfree.aspx (на мой взгляд очень удобная тем что тащит загрузочный сектор), далее на гипервизоре выдаете те же мощности, что и на физике и должно по сути взлететь.