• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Migrate to new server and new Plesk version considerations

JuliusT

New Pleskian
Hi, I'm preparing to upgrade a plesk server.

The old (current and live) plesk runs 11.5.30 Update #44
Update date: 2014/05/02 11:48
Build date: 2014/04/07 17:00
Build target: CentOS 5
Revision: 324178
Architecture: 32-bit
Wrapper version: 1.1

The newly installed target server's plesk is 12.0.18 Update #18
Update date: 2014/10/06 12:45
Build date: 2014/08/21 14:00
Build target: CentOS 6
Revision: 333059
Architecture: 64-bit
Wrapper version: 1.1

So, upgrade plesk version, new OS (and 32 to 64 bit), and a separate (bigger) plesk license and new machinery.
In addition, due to personal preferences/experiences we'd like to change courier to dovecot for imap/pop in the same go.

Another thing; Our /var/www is quite large, about 200 vhosts with content, and the mail-storage used is also quite large.

What are your recommendations for this process to make the transfer go smoothly? I already did a rsync from source to target for the web and mail data, just to be sure (our old hardware is dying and not as redundant as we'd like it to be right now).

There seem to be many migratory options. Which one of the KB articles best fits our purpose?
Are there any particulars for the courier to dovecot conversion in this regard? Or is this switch handled by your migration scripting already?
 
Last edited:
From what I learnt:
  1. backups - take care on the Plesk backup, as it will most likely not work (due to difference it systems). Therefore make sure you have your own backup at least of mysql and vhost files as well as mailboxes.
  2. migration manager is the way to go: just move customers/subscriptions to the new host.
 
I have always used Migration Manager and then use the Backups as a last resort. If you would like you could import all of your site content and ignore the e-mail for now. Once your sites are there you can add the sites to your hosts file (If you are using Windows or Linux) on your local computer and verify some of the sites pull up. You then know that once the DNS is synced to the new server your sites will be live. Another option would be to add additional MX records for your mail servers (Might be difficult on so many accounts) and then turn off the e-mail service on the new server. Get all the new e-mail over there and once the DNS is propagated you can turn off the mail server on the old server, copy the mail over, and then turn it on at the new server. This will do a smooth transition as far as e-mail.
This may be stuff you already know, but, figured I would put some of it out there for you.
 
OK, great advice. Within the Migration Manager, what do I best set for these (especially wondering if I should set it to [Replace existing objects], what do they
mean with 'objects' here? :



Transfer settings
Transfer the following data
Migrate the whole server
Skip server global settings and system services configuration
Transfer license key
Only manually selected resellers, customers and domains
Replace existing objects
 
When they say objects they are talking about the configuration of the domain as one object, the files in the domain folder as another, databases are an object, and then mail is its own object. Inside of those you can select individual accounts, databases, etc. If the new server is most likely containing out of date information you migrated earlier you would be safe in choosing replace.
 
OK, so these objects do not include OS or system-config files, only user data. I really think they should mention that within the UI of that migration manager. I also found some KB articles that are instructing the user to migrate by using the CLI, which I find really confusing advice. Either Plesk regards their CP as mastering it all, or not, and where they do, they should make it a black box we should not mess with under the hood. I'd prefer doing it under the hood, but it's not clear if or where we should.
 
Back
Top