Virtualmin can import accounts from a cPanel backup file, including all mailboxes, databases, and web data. This can make the migration process much faster and easier, though there may still be some aspects of the account that cannot be directly translated to Virtualmin policies and practices. For example, Virtualmin features far more advanced mechanisms for executing PHP in different ways in the same Apache, which cannot be directly mapped from the old-style cPanel suPHP or mod_php configurations. Generally, migrations will result in working websites, but some Virtualmin features may need to be enabled (with care and testing) in order to take full advantage of the advanced capabilities of Virtualmin.
Making the cPanel Backup
To migrate all services from a cPanel server to a Virtualmin server, you’ll need a full backup. To generate a full backup in cPanel, click on the Backup icon, and then click the Generate/Download a Full Backup link. Fill in the form, and click Generate Backup. Wait until you receive confirmation that the backup has completed, and then copy the file to your Virtualmin server.
Copying the cPanel Backup to Your Virtualmin Server
If your backup is small, you can use the cPanel download full backup page to download it to your PC right in your browser, and you can then use the upload form in Vitualmin.
If your backup is larger than a few megabytes, you’ll want to copy the file using a reliable transfer mechanism, like SCP. All Linux systems have scp built in, and so can easily be used to copy the file to your new Virtualmin server.
An example of scp usage:
scp backup.tar.gz email@example.com:/root
Which will then prompt for your root password on the destination server.
Using the Migration Form
Once you have the backup available on the Virtualmin server (or on your local PC if it is small enough), you can then browse to the Migrate Virtual Server form by clicking on the Add Virtual Servers menu to expand it, and then clicking the Migrate Virtual Server link.
Fill in the form, selecting either to upload your backup file, or select the path to the file on your server.
Select a Backup file type of cPanel
Fill in the Domain name to migrate. This should match the domain you’ve backed up on the cPanel server.
Fill in Username for domain. This can be any valid username, but for ease of use, you may wish to use the same name used under cPanel. Virtualmin has fewer restrictions on usernames than cPanel (it allows long usernames for example, so I could name our user virtualmin rather than virtualm).
Choose a Password for administrator.
The remaining options can be left to their defaults, but it may be useful to you to change one or more of them, depending on features you’d like to use. If you will be using SSL or anonymous FTP virtual hosting, you will need to assign a new IP address just for this domain–SSL and FTP virtual hosting does not support name-based virtual servers. Realistically, anonymous FTP is almost never needed, but SSL is often required.
If you will be creating many servers via this mechanism, and have specific requirements for quotas, enabled features, etc. you may find that creating a new Server Template just for imported domains is useful and speeds up the task of getting cPanel users up and running under Virtualmin.
Both cPanel and Virtualmin allow creation of MySQL databases, but Virtualmin simplifies the common use case, while perhaps making less common cases less obvious. In Virtualmin, if MySQL is enabled for a virtual server, a single user and database is automatically created, both with the same name as the administration user of the virtual server (“virtualmin”, for example, for a domain named “virtualmin.com”). This database will be the default for Install Scripts that require a database. If the script in question is incapable of using a prefix or suffix for database table names, this may restrict which applications can be installed into the default database.
If the virtual server owner has been granted database creation privileges, the Install Scripts form will include an option to create a new database for scripts. This is generally the recommended way to deal with running more than one script within a virtual server, particularly with applications that don’t support table prefixes or suffixes to insure uniqueness.