Real Life Site Migration Tips from Pros

Real Life Tips from the Pros! How to do a site migration without traffic loss & hosting issues? Speaker: (Curtis) R. Curtis, Chief Rainmaker Sharksfly Marketing Solutions & RankSense SEO Curtis@Sharksfly.com @CurtisRCurtis

Even the best laid plans often go astray! So how do you do a site migration without traffic loss & hosting issues?

So Don’t Forget…. ,[object Object], -> BETTER RESULTS! (be sure to involve all stakeholders & make sure the plan is vetted by all) …… plus don’t forget! TEST, TEST, TEST & TEST AGAIN!

Because after the web site crashes …… it is too late 

Poor Planning Can Result In: ,[object Object]

Visitors who will never return!,[object Object]

The following are “REAL LIFE” Tips from the Pros!

“Proper DNS management is one of the keys to a successful migration. Smart utilization of DNS features like the ability to change individual DNS records and ability to set “Time To Live” low enables you to execute migrations with minimal downtime and no data loss." ,[object Object],INetUManaged Hosting, www.INetU.com Step 1: Set "Time to Live" to low in DNS. Step 2: Upload your data and test your website/application on your new servers Step 3: Point appropriate DNS records at the new servers, the cutover should be quick if “Time To Live” was set low as per Step 1. Step 4: Check old servers for data written during migration.

“I would like to would like to recommend the use of parallel website migration as a strategy to reduce risk and minimize negative impact on the end-user or visitors." ,[object Object],Analyze and Size -> Use performance baselining scripts to accurately size new environment. Stage and Test in Parallel -> Replicate data and feeds to thoroughly test site functionality Preserve Organic Links -> Spider current site links and implement SEO friendly redirects on new servers for any changes. (next page)

(continued) Application Redirects -> Don’t rely 100% on DNS, the application should have the ability to redirect users to new clusters in the event DNS caches are persistent. Implement Global End User Monitoring ->Provide “real world” tracking of end-user traffic from around the world, especially which originates outside of the country where the server resides.

“We had a very complex site migration from PHPNuke to WordPress for TheHostingNews.com, which had been around since 2003 and had over 7000 pages of content. Our goal was to retain 100% of the URL’s without using a 301 dynamic re-direct, keeping all the links and pagenames and without losing any of our visitor traffic!” ,[object Object],Install WordPress into a unique subdirectory Store all URL’s of legacy site into a new field in the db Migrate all URLs to the Permalink field (next page)

(continued) Create a SQL query to match the fields for all news items, taxonomies, article IDs, titles & content then dump into the custom page URLs Use Custom PermaLink plug-in for WordPress: www.michael.tyson.id.au/wordpress/plugins/custom-permalinks/ to allow for the custom page URLs Import the CSV using a modified version of “CSV Importer” (WordPress plug-in) Install all required plug-ins into subdirectory, then test sampled subsets of all URLs After completing testing & making a full backup of existing, move WordPress core files to the root directory for a seamless transition.

“As part of our migration from a hosted to collocated solution, the database migration was perhaps the most challenging aspect of the move. By using master/slave replication, we were able to accomplish the migration and ensure that we had thoroughly tested the site in its new location and that we had absolute minimal downtime in the process.” ,[object Object],Configure current production database as a master, if it is not already. Dump your production DB and transfer the dump to the new server. On the new server, configure db to be a slave to the current production database. ,[object Object]

If you already have a master/slave setup, the new master can be both a slave to the current production db and the master of the local slaves at the new location.(next page) (continued)

(continued) Restore the production dump to the new db server Set the log position from the dump and then start slave. --you will soon have a production DB on the new server that is continually being updated At cutover time, you need to stop data being written to the old db server. This can be done in several ways. ,[object Object],Note: Read-only can be accomplished by having different db users for your apps on the old vs the new servers. On the old servers, revoke write privileges for that user. The db users for the new site maintain write privileges. Do not use same db user name as privileges will replicate. Once you are sure replication is caught up, stop slave on the new production DB server. Enable the application/writes on the new site and then change DNS. You might also configure forwarding from the old IP via iptables or xinetd at this time Now you are fully migrated & the cutover can be done in just a few seconds.

“Loss of traffic when moving sites to a different IP address or a different file location can be disastrous to online revenues. Too many companies try to save money on such things as turning a server off on the day the new server comes online and it ends up costing them thousands of dollars in lost sales through search engine problems and or dead links that cause customers to go elsewhere. !” ,[object Object],Set your DNS time to live to 0 1 week before you update the DNS for the new website. Once you have done this, go ahead and make the move of the all web pages & content. (next page)

(continued) When you are ready to cut over, make sure to post a forwarder – in fact 301 redirects work best to put in place whether you are picking up pages that are static but moved to a new IP OR if you move the content to different file locations. This will preserve your rankings in the search engines. Leave the content up at both servers/accounts for a week and run some tests from different public traceroute servers to make sure that the caches have been updated. When you are confident that they are - then you can turn the old server/account off. Note: This is especially critical for web and mail applications

“Execution at the lowest TTL and data transfers before and after the DNS change are two main components to a successful migration. Transparency with your hosting partner also helps alleviate unforeseen limitations.” ,[object Object],Identify the domains to be migrated.. Identify any special settings in configuration for existing server/website; you will likely want to replicate them. Verify with your host that you will be able to keep your IP(s). Often hosts have separate networks for their various products. i.e. an IP meant for SSL on a shared server may not be able to be migrated to an IP on a dedicated server. (next page)

(continued) Change the TTL (Time To Live) to 300 seconds on domains to be migrated. Replicate & test content on new server/account by creating new entries in the host’s file of your machine. Once satisfied, schedule a time with your provider to perform the DNS change & update any content to the new server that may have changed during testing (database, uploaded files). ,[object Object],Reset TTL back to standard (typically 3600 seconds).

“Syncing files when migrating websites can save you significant amounts of time. Rather than compressing your entire directories & migrating them, wouldn't it be more convenient if you could just migrate the changes? The rsync tool can help you accomplish this, especially when changing web hosts.” ,[object Object], Do your initial deployment to your new website location using a tar (or some other compressed archive of your content) After uncompressing your tar on the new server/account, you'll want to perform an rysnc from your old website in case your application has changed anything. (continued next page)

(continued) You can do that by running the following on your new website: -> rsync -avz --progress -e sshusername@oldserver:/var/www/html/ /var/www/html/ To ensure that deleted items on the old website are removed from the new site as well, you can run the following: -> rsync -avz --progress -e ssh –delete username@oldhost:/var/www/html/ /var/www/html/ Switch your DNS and run the rsync command one last time after you have made sure DNS has propagated. (next page)

If you are concerned about your hosting company & considering a new host …..here are some suggestions : ,[object Object]

Real Life Site Migration Tips from Pros

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Real Life Site Migration Tips from Pros