You want to relaunch your site and / or move it to a new domain name? This posting tells you which points to follow during that process. It has been originally published by the T3N Magazine in German. I have translated it to English and am publishing it here with permission by the original author.
Domains transfers are bad. Many of you may know the post “Cool URIs don’t change” by the W3C. The article comes to the following conclusion:
Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.
So if you’re planning to serve your site over the next 2000 years 
you should consider the following basics and list of 20 advices. If you follow them then your relaunch including a domain transfer should come up roses.
General advices for a technical relaunch project:
- First identify which features shall be changed during the relaunch. Implement only the absolute neccessary change requests.
- Document the internal testing phase in a system that is available to all team members (for instance backpack, wiki or bugtracker) -> avoid bugreports via E-Mail, to prevent duplicate records of bugs.
- No relaunch without a testsystem that is identical to the livesystem!
- First migrate/relaunch the testsystem and record all the steps taken, to have a plan for the migration of the livesystem later.
- Discuss bugs that reveal during the migration of the testsystem with your team, then fix them, test again and document your doings in the plan.
- During the migration of the livesystem, take the website off the web. Otherwise you may have to cope with data inconsistency.
- Plan the switch / downtime (time of migration) for nightly hours (so that less users will recognize the downtime). If you have to switch in the daytime then use the downtime as PR- or marketingevent and announce some messages or even special activities while the action lasts.
- Keep an eye on your errorlogs after the relaunch. Additionally keep in mind that you may need some extra time for fixing bugs that occur on the livesystem after the relaunch.
Domaintransfer checklist:
- Register the new domain.
- Verify your new domain in the Google Webmaster Tools. Insert your new sitemap (after the relaunch) there.
- Change the configuration of web statistics / tracking software like Piwik, Mint or Google Analytis to use the new domain.
- Generate new domain related JavaScript codes for AdSense, AdScale and other partner- or advertisingnetworks.
- Change zones and codes of your own AdServers (when applicable) to your new domain.
- Change domain-related extensions or plugins of your Content Management System (CMS).
- Don’t redirect internal links to your own resources but change the whole domain / code structure. (Hint by the translator: redirects are known to be bad for the performance and overall user experience of your website)
- Use HTTP status code 301 redirections to migrate well-known URLs of your old domain to the new one.
- Change headers and / or bodies of E-Mail generated by scripts (server statistics, order confirmations, newsletters etc.) to use the new domain.
- Change E-Mail accounts and footers of your company’s employees.
- Reconfigure your Feedburner account to use the new domain.
- Notify Google of the domain transfer at least two weeks in advance!
- Create a new News Sitemaps for Google News.
- Set up new company related documents like stamps, business cards, media kits, notepapers etc. to refer to the new domain.
- Create a list with backlinks to your website. Then contact bloggers, webmasters, partner, journalists and friends to adapt the backlinks to your new domain.
- Change backlinks from Wikipedia and other wiki systems yourself.
- Instruct all employess of your company to change to their social networking profiles to reflect the new domain. A few examples likely to be forgotten: Facebook, Twitter, LinkedIn, Xing, MyOnID, Gravatar, Delicious, Mento, Flickr, Digg and so on.
- Keep your old domain for at least six months and support the redirections (see rule 8).
- Search for broken Links and fix them with tools like Xenu or the Broken Link Checker.
- Check 404 (”Not found”) and other errors of Googles crawling process via Google Webmaster Tools daily. Fix them as soon as possible.
Did we forget something? Please comment this article and i’ll happily add your suggestions to the list.
Google will inform webmasters about their vulnerable software
As announced earlier Google will soon start to inform webmasters if they’re running out-of-date or vulnerable software. All webmasters registered with the Google Webmaster Tools will soon get notifications in case of using outdated software. Google is trying to achieve this by parsing the HTML code of the website, especially the generator meta tag. Quoting the Google Webmaster Central Blog:
If you’re using (open-source) software that is writing a generator meta tag including its name and version into the HTML code, then you’re likely to get notifications by Google if this piece of code is outdated. I think this is a good thing and it won’t cost Google that much computing power as they are already parsing the source code of the site anyway. On the other hand i am not fond of software that is giving away too much information about itself. I am still a fan of security by obfuscation – as long as this is not the only line of defense.