We’ve been an Ensim shop from the outset six years ago. As we have gone through this switch there is much I have learned. Nothing here is meant to be a value judgment. The world isn’t perfect, nor is any hosting environment. They are not in any particular order. These are just my observations and learnings so far. If I’ve botched anything I would sincerely appreciate it if you would let me know so I can improve my knowledge base. I’ve compiled it from posts at cpanel.net, at The Planet, and elsewhere on the web. All of the information is out there somewhere but not all of it is accurate and it is certainly not in any one place, so perhaps this will be helpful to someone else. Everything below worked consistently for us, so I feel confident repeating it. I am greatly appreciative of the help out management company has provided during the process. Give Cheetaweb a look if you have need for server management. General Ensim works in a chroot environment. You can chroot to a virtual site and be on your own virtual machine. A site admin can not see anything on the server that is not in the virtual site. cPanel shares most of the executables amongst all sites. Accounts reside under the site user in the /home directory. This user can navigate the entire server via sftp or ssh (if enabled). They are some things I would rather they not be able to see but apparently they can’t do anything to files outside their space. Anything a virtual user for a site does is actually done under the permission and authority of the site user. Users An Ensim user can be set up for mail, ftp, telnet, and ssh in a single operation. This user will have a /home/user directory that looks much like a non-virtual directory structure. Ensim chroots into the virtual site and executes commands as you would in a normal box. I’m sure there is much overhead involved in that. As near as I can tell cPanel virtual users don’t really exist other than in virtual user files. Again, this is not a bad thing as it clearly works, it’s just different. There are different procedures to follow to set up email users, ftp users, and users with subdirectories. I'm still getting used to having to go several places to perform these seemingly related functions. cPanel site users who ftp into the box are by default chroot-ed to the site owner’s home directory. However, if they sftp they navigate to the home directory and above. This is difficult to explain clearly in documentation. I.e., if you use ftp you do this, but if you use sftp you do this. Both environments share the confusion of virtual versus actual paths, but most web developers understand this. Copy Accounts The migration tool built into WHM that moves sites from an Ensim server to a cPanel server is like a sledgehammer. It is extremely helpful and does much heavy work but it requires some preparation before the move and some cleanup afterwards for every site. Ensim allowed us to use the same admin user for every site. It automatically maps that to an adminxx linux user. As a result, all of the site admin’s on our previous servers were just called admin. The migration tool assumes that every admin user is unique as in the cPanel world. Before you can use it you must make all of your admin users in Ensim unique. Once this is done it can differentiate the Ensim accounts by admin user name and start to bring them over. We could not get the double-login to work (i.e., log in to one account and su to root) and had to enable direct login to root on our Ensim servers during the migration. HTML So far everything from /home/virtual/sitename.com/var/www/html from the Ensim sites has been moved perfectly to the correct cPanel /home/siteuser/www directory. I’ve made scripts that search for all the /home/virtual… paths and the /var/www/html paths and change them to the correct path for cPanel. Mail User mail stored on the server is converted from mbox to maildir and placed in the /home/siteuser/mail/sitename.com directory in a subdirectory under each user’s name. That works perfectly. Oddly, though, the tool also copies the mail folders to /home/siteuser/mail. These are of no value there and just take up disk space. Squirrelmail attachments are moved into /home/siteuser/squirrelmail-data, where they do no good. This folder must be renamed to .sqmaildata. I don’t know yet where attachments are placed, but when I find out I’ll update this. Again, I’ve got a script that cleans up the mail migration pieces very effectively. Anything in the Ensim site admin’s home directory is placed in /home/siteuser. Much of it can be deleted, like old .procmailrc files, .mailboxlist files, spamassassin and other vestigial Ensim things. Home Directories During the copy process everything in the Ensim users’ home directories is copied into a subdirectory named for the user in the www directory. If /home/bob existed in an Ensim site the contents of that directory will now be in /home/siteuser/www/bob. I do not like this at all. First, by default it exposes all of bob’s information under the web root. I have a script that finds these directories and drops an .htaccess there to prevent indexing, but if a snooper guesses a filename from the folder he can get in. Second, since Ensim keeps all non-inbox mail folders in /home/user/mail all of these are copied to bob’s subdirectory under the web root. This means that post-migration not only are these files momentarily exposed in a public directory, there are actually three copies of bob’s mail folders on the cPanel site. If a site was under quota on Ensim but not by very much, the triplicate imap folders that the migration creates can easily drive the new site over quota. If this happens during the move the tool will fail to create the mail directory structure properly. If you have sites that are tight on space increase their quota temporarily in Ensim before starting the migration. You can switch it back after you’ve cleaned up the site on the cPanel server. In addition to the htaccess file it adds our user subdirectory script removes the mail files and also cleans out all the standard Ensim files from these subdirectories (.mailbox, .procmailrc, .spamassassin, standard image files, etc.) and the mail directory, since this is already properly placed elsewhere. MySql The migration tool does not copy databases, although it says it does. These must be exported, moved, and imported manually. It would be very nice if the database users from Ensim were created on cPanel, the databases migrated properly and ownership set to the db user. Of course, you have to find and change all files in the web directory that reference mysql. You can do it with scripts fairly easily. Server Cleanup The migration leaves a .gz file in the home directory of the Ensim server for every site moved. These files are a copy of everything in each site, so they are large. If the server is tight on disk space you will need to remove them periodically. It also occasionally leaves a copy of this file in the home directory of the cPanel server. Frontpage This last one seems small but can have a big impact. cPanel will let you remove Frontpage extensions from sites that don’t have them. When you do that it replaces the existing .htaccess with an empty one. Since most .htaccess files are there for a reason this will likely break the site. It is kind enough to back up the .htaccess it removes, however. I know many are philosophically against changing user files for them and will not appreciate all the scripting I’ve mentioned above. However, our customers expect us not to break their sites as much as possible. Anything we change is backed up to a special location and anything we touch is documented in changedfiles.html in the web root for the site. This all happens automatically. We also keep the old site in quarantine for 7 days before deleting it, so we can always fall back if need be. This dual layer of protection makes me comfortable we are covered.