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

BETTER PLANNING-> BETTER RESULTS!

TEST, TEST, TEST & TEST AGAIN!

So Don’t Forget….

(be sure to involve all stakeholders & make sure the plan is vetted by all)

…… plus don’t forget!

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

Even Twitter Learned…

Poor Planning Can Result In: Loss of traffic & poor user experience!

Service disruption!

Visitors who will never return!

Loss of investment!

Worst of all – VERY Upset Clients/Bosses!

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."

Chris Kivlehan, VP of Account Management

INetU Managed Hosting, www.INetU.comStep 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."

Kelly Beardmore, CTO & COO, Tenzing Managed IT Services www.Tenzing.com

1. Analyze and Size -> Use performance baselining scripts to accurately size new environment.

2. Stage and Test in Parallel -> Replicate data and feeds to thoroughly test site functionality

3. Preserve Organic Links -> Spider current site links and implement SEO friendly redirects on new servers for any changes.

(next page)

4. 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.

5. 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.

(continued)

1. Install WordPress into a unique subdirectory

2. Store all URL’s of legacy site into a new field in the db

3. Migrate all URLs to the Permalink field(next page)

“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!”

Ben Fisher, CEO, TechPadAgency www.TechPadAgency.com

4. Create a SQL query to match the fields for all news items, taxonomies, article IDs, titles & content then dump into the custom page URLs

5. Use Custom PermaLink plug-in for WordPress: www.michael.tyson.id.au/wordpress/plugins/custom-permalinks/ to allow for the custom page URLs

6. Import the CSV using a modified version of “CSV Importer” (WordPress plug-in)

7. Install all required plug-ins into subdirectory, then test sampled subsets of all URLs

8. After completing testing & making a full backup of existing, move WordPress core files to the root directory for a seamless transition.

(continued)

1. Configure current production database as a master, if it is not already.2. Dump your production DB and transfer the dump to the new server.

3. On the new server, configure db to be a slave to the current production database. You can use SSH Tunneling to ensure data security. 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)

“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.” David, Joslin System Admin, SEOmoz

www.SEOmoz.org

4. Restore the production dump to the new db server5. 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 updated6. At cutover time, you need to stop data being written to the old db server. This

can be done in several ways. Turn off the old apps. If your apps supports it, enable read-only on the old

site.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.

7. Once you are sure replication is caught up, stop slave on the new production DB server.

8. 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

9. Now you are fully migrated & the cutover can be done in just a few seconds.

(continued)

1. Set your DNS time to live to 0 1 week before you update the DNS for the new website.

2. Once you have done this, go ahead and make the move of the all web pages & content.

(next page)

“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. !” Jeff Hinkle, President, NetDepot

www.NetDepot.com

3. 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.

4. 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

(continued)

1. Identify the domains to be migrated..

2. Identify any special settings in configuration for existing server/website; you will likely want to replicate them.

3. 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)

“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.”

Ryan Elledge, COO, Coderowww.Codero.com

4. Change the TTL (Time To Live) to 300 seconds on domains to be migrated.

5. Replicate & test content on new server/account by creating new entries in the host’s file of your machine.

6. 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).

Rsync or robocopy are easy ways to perform this task

7. Reset TTL back to standard (typically 3600 seconds).

(continued)

1. Do your initial deployment to your new website location using a tar (or some other compressed archive of your content)

2. 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)

“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.” Robert Collazo, Professional Services Manager,

Rackspace Cloud, www.Rackspace.com

You can do that by running the following on your new website: -> rsync -avz --progress -e ssh username@oldserver:/var/www/html/ /var/www/html/

3. 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/

4. Switch your DNS and run the rsync command one last time after you have made sure DNS has propagated.

(continued)

(next page)

Shop around to see what else is out there Put a competitor’s bid in the hands of your current host Prices are usually (99.9%) negotiable By renegotiating, you may be able to enter into a

new/better contract sooner than expected It’s more expensive for them to get a new customer than it

is to keep an existing customer

If you are concerned about your hosting company & considering a new host…..here are some suggestions :

Also...Having THE RIGHT web host will make migrating a lot easier!!!!

BUT….beware of “empty” promises!

Plan carefully – there are plenty of hosting & other related professional who can help you with your web site migrations depending on your needs!

http://rackspace.com/index.php

(Curtis) R. Curtis, Chief Rainmaker

Sharksfly Marketing Solutions &

RankSense SEO SoftwareDirect: 1.604.313.7377Office: [email protected]@CurtisRCurtis

Real Life Tips from the Pros!

mailto:[email protected]

Real Life Site Migration Tips from Pros

Technology

Transcript of Real Life Site Migration Tips from Pros