Account Migration FAQ

In general, if InterWorx-CP supports the feature, it will be imported. But like anything else, when you are dealing with different operating systems, control panels, service software versions, etc. there is no such thing as a sure thing. The importer will ignore anything that it does not recognize (by design). It is always best to doubhe check your imported accounts before deleteing the originals.

The good news is that the importer does not destroy the backup file so you can still manually decompress it and complete the import by hand.

The importer scripts are stable and reliable on the listed supported control panel versions. A user who finds what he or she believes to be a but in the importers are always able to open a support ticket with is and a member of the InterWorx team will assist you in importing the account and at the same time making the importer better.

This is normal, if for some reason the restore script didn't recognize something in the backup. Differing MySQL versions from old host to new host has also been known to cause problems (e.g. MySQL 4 to 3).
The good news is that the importer does not destroy the backup file so you can still manually decompress it and complete the import by hand.

Yes. Info about our Migration Tool can be found Here.

In cPanel the backup file must be created from cPanel NOT WHM!

Yes, you can import all of your user accounts from another InterWorx-CP server or a number of competitor's servers, including cPanel, DirectAdmin, Ensim, and Plesk.

While it is possible to move a Hsphere account to an InterWorx-CP box, it must be done manually. This is due to the fact that Hsphere does not have a backup format per se. It merely zips the site data.

Not precisely, but you will have the best results if the versions of all of your services (especially MySQL) are the same.

Going from MySQL 4 to MySQL 3 HAS caused users problems so it is advised that you update the MySQL version on your new server if it is older than older box.

No, you will encounter problems with restoring your databases if you do this. Or, to put it in technical terms, "things will break."

For example your old host has MySQL 4.1 and the InterWorx box has 3.3 (the default for most supported distros), it will not work correctly because MySQL 4 has some differences in the table format that 3.x won't understand.

If this is the case you should locate and download an updated MySQL RPM/SRPM ind upgrade before trying to import your site.

Yes, going from MySQL 3 to MySQL 4 should be fine (though there have been some bugs here which have -- hopefully -- been squashed).

One possible problem is that the unique SiteWorx user name (e.g. /home/<siteworxuser> ) from the old box is not available on the new one. Since the SiteWorx importer/restore is dependent on using the original name, this issue must be resolved before you proceed.

Another problem could be your MySQL version. If your old server was running MySQL 4 and the new one only has MySQL 3, your databases and/or users will probably not be imported.

If the backup file is too big for your internet connection to handle through http, try loging into ftp and downloading it that way. The backup files are stored in /home/<siteworxuser>/backup by default. You can also specify an alternative location when you create/schedule the download.

If you have a local backup file on your hard drive that is very large, InterWorx won't let you upload it via the browser due to file size restrictions and PHP or Apache timeouts. If you try to upload it, you will get an error message indicating you should upload the file with another method (for example, FTP or SCP) and use the remote backup file option instead.

You can upload it anywhere in the file system but it is best to upload it to the default location of /home/<siteworxuser>/backup

This answer assumes you are moving the email account from another server which runs qMail or qMail-Toaster. InterWorx stores mail in /home/<siteworx_user>/var/mail/<mailbox_name>.

1. Create the mail user on your server
2. Transfer the mail directory from the old server to the new one

Yes, InterWorx-CP has a mass importer for a number of competitor's control panel's. The software connects to the other server, directs it to make a backup of every account, transfers the native backup files to the new box and imports them.

Archive file : /mysite.com_aug.24.2005-00.44.29.tar.gz
» Working directory : /tmp/siteworximport9DF59D
» Archive extracted successfully
» Could not extract data archive. Wrong backup type? : <backup name>

First make sure you selected the correct backup type on the import page. Double check to make sure.

If that's not it, how big is the archive file? How big does the .tar.gz expand do?

How big is the /tmp partition on your server?

Here's the problem I had:

My data center put the /tmp directory in it's own partition and only made it 500 MB. The .tar.gz backup I was working with was 390mb and expanded to 580mb. That caused the errors above.

The workaround was:

mkdir /home/tmp
chmod 777 /home/tmp

(because /home tends to be in the largest partition).
Then

vi /home/interworx/iworx.ini

locate

[dir]
cron="/var/spool/cron"
mysql_base="/var/lib/mysql"
skel="/etc/skel"
sysconf="/etc"
tmp="/tmp"

change tmp="/tmp" to tmp="/home/tmp"

save the file

service iworx restart

just in case, but it should work without it.

You are getting this message because you are backing up a SiteWorx account that has been given access to cron but the backup script is not finding cron files for that user. Most likely this is just because the user has never actually used cron before. Unless you know that the user has set a cron before you can safely ignore this message.

• Determine which partition /home is mounted on.

root@test-box# df /home

• Run a quota check on the partition determined above.

root@test-box# quotacheck -cugvmf -F vfsv0 /home

• Run the storage accounting script.

root@test-box# ~iworx/cron/storage.pex

Your quotas should be correct now