First off, let me summarize what is and isn't happening.
What IS happening:
The domain, IP assignment (no matter if shared or dedicated) and DNS records are all migrated successfully. The DNS is correctly reformatted to the target server's DNS Template, it even revises the SPF record correctly.
What ISN'T happening:
Everything else. No site content, no aliases, no mail accounts and no databases. The whole process pretty much stops after the domain is retrieved and the IP and DNS are assigned. NOTHING happens after that.
There are no <ip_address> xml tags at all in the entire debug log.
However, I did notice something I thought was strange. Look at this xml:
There is a </mail> closing tag but no <mail> opening tag. Shouldn't there be a <mail> opening tag?Code:=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||<?xml version='1.0' encoding='utf-8'?> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||<packet version="1.6.6.0"> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <webspace> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <get> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <result> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <status>ok</status> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <filter-id>xxxdomain.com</filter-id> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <id>4</id> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <data> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <gen_info> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||... =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <outgoing-messages-mbox-limit>default</outgoing-messages-mbox-limit> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <outgoing-messages-domain-limit>default</outgoing-messages-domain-limit> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <outgoing-messages-subscription-limit>default</outgoing-messages-subscription-limit> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| <outgoing-messages-enable-sendmail>default</outgoing-messages-enable-sendmail> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| </mail> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| </data> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| </result> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| </get> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client||| </webspace> =|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||</packet>
This only shows the domain I entered manually to set up my own nameservers.
Mail (and everything else) works fine for domains that are set up from scratch. This is an issue with the Migrator. I even tried to do a simple backup from the source server and restore on the target server to move some domains and, although it does move the databases and some mailboxes (it doesn't move all of them for some reason) it breaks your ability to delete some mailboxes and has a few other problems with aliases.
To be honest, I have had so many issues with a very straightforward clean install of Plesk 12.5 on a brand new server that I am starting to feel that version 12.5 isn't ready for production. I have spent 2 weeks fixing issues that are all over the Odin forums that many people are having too. It has so many bugs that I have had to solve, I don't trust it to function correctly when I take it to production. Perhaps it should still be in beta. I may re-image the server and use 12.0.18 until 12.5 is truly finished.
@KirkM,
With respect to some of the issues you have mentioned, the following (general) work-arounds can be provided:
a) when migrating across versions, everything should be migrated, even though some (or more) error notifications can occur.
I did some tests with the migration manager and, in most cases:
- multiple issues were reported, but most of the issues can be safely ignored,
- an issue with the assigned IP occurred (note: the assigned IP was blank in the migration process, very similar to the issue you reported, but not exactly equivalent).
Some simple work-arounds seem to exist:
- rerun the migration process for one domain (and retry if the issue IP address occurs again), OR
- start with one domain, OR
- re-assign the IP address on the new server (the target server in the migration process).
For some strange reason, all the above work-arounds did result in a proper migration of data (with reported issues, that can be safely ignored)
b) when migrating across versions AND using a new server:
- install Plesk 12.0.18 on the new server,
- migrate using the migration manager (i.e. from 12.0.18 to another 12.0.18 installation)
- on the target server in the migration process, upgrade Plesk to 12.5.30 afterwards
and this should not be resulting in any issue.
c) when mostly migrating WordPress sites:
- create a fresh install of Plesk 12.5.30 on the new server,
- install a "clean" WordPress instance on the new Plesk 12.5.30 server,
- use "Migrate DB" and "Migrate Media" plugins for WordPress, in order to migrate the whole WordPress site (from a Plesk 12.0.18 to a Plesk 12.5.30 install)
and repeat the process for each WordPress site (note that this process only takes a couple of minutes per site).
Why would you want to migrate WordPress sites manually? In most cases, the WordPress databases are not migrated properly or not migrated at all.
d) the most obvious work-around:
- migrate all databases manually (simply exporting and importing of databases, even though "simply" is an understatement)
- rsync all data to the new server (inlcuding mailbox data)
and having said that, one should be aware that this "obvious work-around" is very error-prone. Just use the other methods, if they work for you.
Regards.....