When migrating your accounts, domains, users etc. from the old FreeBSD based servers, you will inevitably run into some problems, as the layout of the account and the naming schemes had to be made different. See Changes from TextDrive Shared Hosting for a summary.

This walkthrough is specific to those hosted on TextDrive servers. For a more general overview of the process, see Moving to Joyent Shared Accelerators.

Based on suggestions by tweir:

1. Delete cruft and organize what’s left. Take this chance to go through your sites’ file structure and clean out things you are no longer using, or organize things a little better.
2. Read up on Changes from TextDrive Shared Hosting.
3. Make a list of email users.
4. Remind email users to clean out their inboxes.
5. Make a list of domains that need to move.
   1. Make a list of what type of ports you need (lighttpd, trac, instiki, mongrel, generic use)
   2. Make a list of dedicated IPs
   3. Make a list of Share certificates (from Joyent) and third party certificates which will need to be regenerated.
   4. Make a list of protected directories (if you made any)
6. Set your TTL to a low level if you manage your own DNS records. If your DNS records are managed by TextDrive, they are already set at either 1200 or 2400 seconds (depending on when your account was set up) which is a fairly low value - no need to change anything.
7. Catchall email address users: make a list of email addresses you have used that you want to remain available.
8. You can keep track of how the migration is going at Joyent's end via the OpenSolaris Migration Update forum thread. This also has info on how to request a Golden Ticket.

Do the following for each domain - you may wish to use the domain migration checklist below. By the way, start with your least important domains.

1. Limit access to your website if possible, especially if other people besides you normally contribute to the site (forums, blogs with comments, etc.). For example, put up a simple “down for repairs” index page up and redirect all access to it. Or simply disable comments, etc. If users make additions or changes to any part of your site during the migration, it is likely that it will be lost, and this step helps prevent that from happening.
2. Back up your files, either to your local hard drive or to strongspace.
3. In Webmin on your old account, turn on FTP access for all users (for email migration later).
4. Add the domain to your account
   • Adding a domain
5. Create your databases in Virtualmin (if your .sql file doesn't start with a CREATE database_name declaration)
   • Creating MySQL databases
   • Creating PostgreSQL databases
   1. Either in phpMyAdmin (mysql.servername.textdrive.com) or from the command line, export your database using as “latin1” character encoding. Download the .sql file to your hard disk.
   2. Open the .sql file in a text editor and find/replace all instances of latin1 with utf8. Note that if your collation is something strange like latin1-swedish-ci you'll need to change this to utf8-general-ci.
   3. Check if the file starts with a CREATE database_name declaration—you will have to comment this out with ”--” if you've already made the database, and/or alter the USE database_name command if the new database name is different.
   4. Save the new file and import it into your database on the new server (again, can be done either on the command line or through phpMyAdmin).
   • Restoring a MySQL database
   • Restoring a PgSQL database
6. Add users or mailboxes:
   • Adding users or mailboxes
   • Adding multiple users in batches
7. Create aliases
   • Creating a mail alias
   • Creating multiple aliases in batches
8. Upload your site's files. Rather than using SFTP (downloading everything from the old server and uploading it back to the new), why not copy the files directly? Log in to the new server and cd into your website's web/public directory, then type the following command¹⁾:

   rsync -ave ssh oldusername@oldserver.textdrive.com:domains/site.com/public_html/ .

9. Check paths, usernames and passwords in configuration files for your CMSs and other web apps. The absolute paths given in these files (such as textpattern’s config.php) are almost certainly incorrect now that you've moved all your files to the new server.
10. Recreate protected directories if you had them, and if you want to manage them via Virtualmin. Allowed users should appear automatically once you've added the protected directory since the directory's .htpasswd should have been copied over (use the default “users to allow: all users in file”).
11. Preview your domain.
12. Copy cron jobs from your old account if you have any you want to keep. The shared accelerators don't have @reboot cron jobs — read up on Boot-up actions instead.

You may wish to use the email migration checklist below to keep yourself organized through this process.

1. Check then recreate your current email setup (forwards, aliases etc) on the new server for each email user account so that the emails will be processed as they currently are once we flip the DNS switch
2. Send a test email to each new user account to ensure it’s working (you can check via https://usermin.joyent.us/servername/, eg https://usermin.joyent.us/caledonia/). The email address format to send to is username@servername.joyent.us for your primary domain, and username-domainname@servername.joyent.us (you can check 'username(-domainname)' in Edit Mail and FTP Users → POP3/FTP login, and 'domainname' is generally the first part of your domain name, eg “bbc” for bbc.co.uk)
3. On the OLD server, switch FTP access on for each user whose email you are migrating
4. At the same time add their new server email address to the email forwarding section. This merely ensures that no email is lost during the time it takes the DNS to switch over later on. (Note: Enabling forwarding can be problematic, especially if you have lots of aliases. Make a copy of all your aliases first so you can check none are dropped in the process. Also the forward is usually successful even if the server times out - try accessing from the user list again to check.)
5. Copy each email user’s mail. You could simply open both old and new accounts in an IMAP client like Thunderbird and drag and drop the emails over, or use this suggestion from anoop:

   Two rsyncs appear to be the quickest way to move mail over…On your 
   new shared accelerator, run this command:
       
     rsync -ave ssh old-login@oldserver.textdrive.com:Maildir some_local_temp_folder
   
   This will bring over a user’s Maildir to the Solaris server. Then run this command 
   to put it in their new home folder
   
     scp -pr some_local_temp_folder/Maildir new-login@localhost:
   
   Then rm -fr some_local_temp_folder/Maildir to get rid of the temporary copy.

NOTE: The second step used to use rsync, but rsync does not work due to changes in the scponly shell. Use scp instead.

On some of the textdrive servers the first step still works with rsync. On others, you need to replace rsync -ave ssh with scp -pr.

Don't forget some of these other items. These aren't covered in detail on this page since they don't apply to most users:

• SVN repositories – see Dumping and loading a Subversion repository; these instructions are for the new Shared Accelerators. If migrating from the old FreeBSD servers, the “dump” instructions won't work since these servers use an older version of Webmin which lacks the “dump” facility. You can achieve the same thing by manually performing an svnadmin dump of your repositories. (If you run svn, it's likely you know how to do this. If not, ask on the forums.) The “load” step then uses your manual dump.
• Mailing lists – they have to be moved by 'root' and need to be unique by server, so requires a ticket – see this forum thread for details. If you are using custom aliases to drop the 'lists.*' prefix off your lists, you will need to manually migrate these custom aliases over.
• Sendmail - if you have scripts which call it directly, it's now in /usr/local/bin/sendmail

This assumes that you are using Joyent to serve DNS for you (including the textdrive.com name servers). There are two ways to switch DNS from an old TextDrive shared server to a Shared Accelerator.

If you never requested any custom A type record (pointing a single hostname to an IP external to Joyent/TextDrive), and have either a vanilla DNS zone, or have a custom MX or SPF setup on a domain (anything but an A type record):

• Just enable PowerDNS for the domain in Virtualmin on the Shared Accelerator. You do not have to care about the PowerDNS option on the old server or anything else. Virtualmin on the Shared Accelerator will embrace the existing DNS zone and update all IPs in the zone to match the new server. Any non-IP customizations (e.g. MX pointing to Google or Joyent Connector, a custom SPF, custom CNAME records etc.) will be preserved. Any A type records (pointing to IPs) will be reset to point to the Shared Accelerator.

If you do have custom A type records (e.g. a hostname pointing to your own server elsewhere), you can still follow the above approach and then request to have the custom A record(s) reset, or:

• Open a support request and let Joyent switch your DNS over. Do not forget to specify which domain(s) to process and what is your original and the new server. Any customizations will be preserved and Joyent will only update IPs that match the original server.

Use these tables to create a spreadsheet or plain-old-paper list of your domains or email users and check off each task in the migration process.

Neither table is all-inclusive of the total migration process; in fact there is no overlap between the two. The domain checklist includes only website-related tasks, and the email checklist includes only email-related tasks. Neither includes the step of switching over your DNS at the very end.

This is essentially a summary process of the migrating each domain section above.

This is essentially a summary process of the migrating your email users section above.

Just where to start seems daunting sometimes. So take things step by step. First create a hello.html page so you can start figuring out just where things are going wrong.

<html>
 <body>
  <h1>hello world testing example.com</h1>
 </body>
</html>

first start out with the hello.html page in your ~/web/public or ~/domains/example.com/web/public if this is not your primary domain you are debugging. Then move it to other directories which you are having problems. Change the example.com text to be something unique just so you really know that it is your page rendering.

http://example.com/hello.html doesn't display. Don't fear lets walk through the configuration.

1. DNS issue

   host example.com

   Does this return the IP of your new slice of Solaris goodness? Read this to solve the problem

2. Virtual Host configuration look here for your app specific instructions
3. It Works! I'm seeing this page and not what I expected. Go back and edit your virtual server and make sure that in the bottom section you have Web virtual server enabled

So I'm all moved over and all I have to show for it is 500 errors. To quote Filip “A 500 error typically means that Apache encounters a broken/invalid configuration”. Don't fear here are a couple of quick tips.

1. .htaccess take a long look at this file. Anything relating to mod_security should be removed. Solaris Accelerators are using a newer version and the items from FreeBSD will not work.

My static pages(hello.html) are rendering but anything to do with the database renders a blank page.

1. usernames double check that your usernames are the same from the FreeBSD. This is where using the checklists above will really save you time. From the checklist above jervis went to jervis-foo.

Make sure you've enabled error logging. See PHP configuration

Check if your ~/etc/php5/php.ini or ~/etc/php4/php.ini matches the configuration on TextDrive. For example, you may have to enable allow_url_fopen (which is disabled by default).

Don't fear more resources are available here:

1. Troubleshooting the Internal Server Error
2. Check new install instructions for your specific frame work. Go through the steps making sure that everything is set correctly.
3. Missing or wrong version of native package. We tried very hard to make sure that all of the native items are available. Check against this list
4. search the Shared Accelerator forum. Use the search page enter the keywords for the error (start specific then fewer until you get a hit). First limit the search to the Shared Accelerator forum and if no hits search all forums.
5. post a new question here