What would be the best approach to migrate from an existing cPanel setup to Plesk?
cPanel DNS Only cluster (which is just basically BIND) for those cPanel servers.
Obvious part:
Install Plesk Servers, set up the Slave Extension, install BIND servers, connect to them.
The problem is downtime. While you could just transfer the zones files to the new BIND servers to avoid this I have read on the forums that the slave extension only applies to new domains.
Since Plesk seems to create everything into the database as well, this would be an obvious problem because the records already exist on the DNS servers. If you try to create them on Plesk, I assume the slave will fail because they exist on the BIND servers, but if you delete the records, and the create on the Plesk so the extension then transfer them to the slaves that means a nice very big downtime for every domain, not to mention the main network domain that hosts the zones.
Long story short. Is there a way to import the DNS records/zones to Plesk manually? Also, not all zones need web hosting. So creating a new account just for DNS would be a bit overkill. While having some downtime for customers can be acceptable, in that case just let Plesk create the new account with DNS, etc I'm trying to see if there is a way to do this without DNS interruption. Importing them first, would also probably mean problems when you then try to setup the actual web hosting accounts (unless there is check to skip DNS check on creation).
The cPanel DNS only are basically just Bind records with a top header added by cPanel that is just a comment and can be removed, technically there is no reason why Plesk would not be able to use the same records but it probably has to have similar information in the database as well or they will not be able to manage by Plesk or even appear.
Suggestions would be appreciated on what the best approach would be. While this would be quite easy for a new setup, transferring an existing one is a bit more complicated as with anything DNS related, one simple mistake and it will be propagated online.
cPanel DNS Only cluster (which is just basically BIND) for those cPanel servers.
Obvious part:
Install Plesk Servers, set up the Slave Extension, install BIND servers, connect to them.
The problem is downtime. While you could just transfer the zones files to the new BIND servers to avoid this I have read on the forums that the slave extension only applies to new domains.
Since Plesk seems to create everything into the database as well, this would be an obvious problem because the records already exist on the DNS servers. If you try to create them on Plesk, I assume the slave will fail because they exist on the BIND servers, but if you delete the records, and the create on the Plesk so the extension then transfer them to the slaves that means a nice very big downtime for every domain, not to mention the main network domain that hosts the zones.
Long story short. Is there a way to import the DNS records/zones to Plesk manually? Also, not all zones need web hosting. So creating a new account just for DNS would be a bit overkill. While having some downtime for customers can be acceptable, in that case just let Plesk create the new account with DNS, etc I'm trying to see if there is a way to do this without DNS interruption. Importing them first, would also probably mean problems when you then try to setup the actual web hosting accounts (unless there is check to skip DNS check on creation).
The cPanel DNS only are basically just Bind records with a top header added by cPanel that is just a comment and can be removed, technically there is no reason why Plesk would not be able to use the same records but it probably has to have similar information in the database as well or they will not be able to manage by Plesk or even appear.
Suggestions would be appreciated on what the best approach would be. While this would be quite easy for a new setup, transferring an existing one is a bit more complicated as with anything DNS related, one simple mistake and it will be propagated online.