@Aleksey Filatev
In response to
Unfortunately, it does not work so perfectly: legacy Migration and Transfer Manager has a lot of issues, that was fixed in Plesk Migrator.
I have to apologize: it is true.
In particular, cross-version migration (12.0.18 to 12.5.30) has a lot of issues and some of them are related to the legacy migration manager.
Moreover, I realised after typing my comment that it does not make any sense to have "an old CLI utility" in a new Plesk environment (12.5.30), that does require something else.
With respect to
Thank you for feedback! We will investigate this issue. Could you please provide us some details? Which OSes was affected? Unix, Windows or both? As I understand, you have Plesk 12.5 Update 11, then install Plesk Migrator 1.4 on it and see, that Update 13 was not installed yet?
note the following:
- test environment: linux, with ubuntu and centos (both with various OS versions) test/development servers (we have 4 to 6 servers to reproduce alleged bugs and find bug fixes)
- exclude: centos (all versions), due to the fact that we were testing some (other) bugs and, as such, micro-updates were enforced when running autoinstaller or reproducing bugs,
- exclude: ubuntu, as far as one of the ubuntu test servers was used to reproduce the alleged bug, by toggling Plesk migrator on and off,
and, hence, the only reliable reproduction of the issue was on a Ubuntu 12.04 and 14.04 server, with Plesk migrator set to off (i.e. not being installed).
Note that some of the ubuntu test servers were on micro-update 10 (and did not install new micro-updates automatically), while others (specifically ubuntu 14.04 test servers) were on micro-update 11 (and not installing micro-updates 12 and 13 automatically).
It seems to be the case that some micro-updates are only installed when a specific Plesk package is installed.
I cannot help you to identify the dependencies between micro-updates and Plesk packages in more detail, since any attempt to do so with (for instance) autoinstaller will result in the missing micro-updates being installed (and hence any testing or conclusion would be falsified).
However, in my humble opinion, it can be safely assumed that the autoinstaller is doing it´s work properly (since running the autoinstaller is resulting in installation of micro-updates) and hence it must be the case that has to be searched in those scripts that call autoinstaller (or similar scripts performing updates).
Hope the above helps to narrow down the (potential) issue.
Regards....