What are the steps for migrating drupal website to a new server ?

·         Verify Clean-Urls in Apache. Confirm AllowOverride All is in effect, and mod_rewrite is available.

·         Ensure that when you uploaded, the Drupal .htaccess file went up as well. On some systems this file is hidden.

·         Check DB support via phpinfo

·         Check GD image toolkit support in phpinfo, or in the Drupal admin status page.

·         Decent php memory_limit (32 M) (phpinfo, php.ini)

·         Decent php upload_max_filesize, post_max_size (phpinfo, php.ini) For Drupal to behave as expected, post_max_size must be 2x upload_max_filesize

·         Check allow_url_fopen for updates and aggregation if required.

·         Check that the include_path contains \'.\'

·         Check that safe_mode is off

·         Check the error_reporting level. You may want it on when installing, but remember to turn it off on production.

·         This and more is covered in the Drupal \'requirements\' doc and of course INSTALL.txt is the first reference to look at.

·         Set up cron! Remember!
_{If your host is Debian/Ubuntu less than} php5/5.2.6-2 _{PHP sessions may not get cleared correctly, and you may need a} workaround for Debian session garbage collection

·         TEST an upload.

·         TEST an image derivative rebuild.

·         Review access control settings for admin/editor/authenticated/anonymous users. Log inas each role and check a few things like the ability to upload big files, use input filters.
_{I\'ve been stung a few times by setting up as user #1 and handing over to an \'editor\' role client who then found they still had incorrect upload size limits etc.}

·         Adjust write-access to sites/${SITENAME} (if installing) and sites/${SITENAME}/files

·         Check at admin/settings/file-system, it\'ll warn you if there\'s a problem.

·         What you need to do and what you CAN do to adjust permissions on the server will vary between systems.

·         check write-access to /tmp . Change it to sites/${SITENAME}/files/tmp (no leading slash) if needed.

·         Once you are set up, consider locking all the code to read-only for security.
See more at File Permissions and Ownership For Security.

·         Check the owner and group of any newly created files and folders
ls -la files/
_If the owner of web-process created files _{is the same as your login username (not www-data), that means it\'s theoretically possible for web scripts to modify themselves. This is a hack vector, and could be a concern.}

·         Check access to your settings.php. It contains your database password in plaintext, and it would be good to NOT have that readable by anyone other than your web process. Unfortunately that means it\'s readable by anyone running the web process on that machine.
For this reason, it would be good to have your :
- Admin-control panel-ssh login password different from your
- database password different from your
- Drupal user #1 password.
...even though that\'s a pain.

·         If you have enough rights, consider shifting htaccess directives into apache configuration files for performance.

·         Remove phpinfo.php if you had one.

·         TEST directory browsing is disabled for files/ (by attempting to access it in a browser)

·         TEST that www.example.com and example.com perform the same, preferably by redirecting one to the other. See .htaccess [handbook doc needed?]

·         TEST email sending. Email setup is different for different hosts, but should be configured already by the sysadmin.

·         Check the email:from headers and see what you can do to avoid system emails going into a spam bucket

More testing ideas.

·         Run a links checker. Xenu is simple for windows. linklint is adequate for commandline.

·         Visit your admin/reports after running a link checker and see what shows up. Other errors, not just 404s may appear there and need attention.

·         Consider benchmarking Drupal Performance. apachebench (ab) is OK, but needs root and just whacks one page. siege is better (can script a session), but needs installing.

·         If you have a high level of control on the server, Consider other tuning issues like PHP accelerators.

·         Consider your backup plan.

·         TEST your backup recovery.

·         Remember to configure and test any non-Drupal logging tool you may want to use. eg,Webalizer, Google Analytics or something provided by your host.
_{Now is a good time to locate your server logs, and make sure you have access to them from your host. When you need them to troubleshoot problems it\'s too late to find that they don\'t exist.}

·         Document every password, path and IP you can find. Domain registration, Control Panel login, User account info, FTP server, MySQL connection string, location of the config files for your backups, contact details for key parties etc. Put it all in a document with a DATE in it. Print that off and save it in three SAFE places.

·         Review your hosts policies on overages. It\'s much better if your host provides a warning & throttle service when/if you overrun your bandwidth or storage allocation than if they let it run then charge and penalize you (or just shut you down). Some hosts also punish \'excessive\' use of the database or processor - which Drupal can be guilty of.Read the fine print.