Twelve tips for successful website migration
We come across or read about it regularly: sites, straight after going live with a new version, needing to shut down part of the site, reinstall the old site, or apply other make-shift solutions. Furthermore, it still happens frequently that when a new site goes live, all old links to that site stop working. Something that is preventable! This check list, put together by Joost de Valk of Onetomarket and Eelco van Beek of Jitscale, aims to help companies (and individuals) with launching a new version of their already existing site.
1. Redirect old URLs
In most cases a new website comes with new URLs. No problem if it weren’t that people are still linked to the old URLs and search engines still hold those old URLs in their index. So you can’t escape redirecting all those old URLs to their new equivalents, using 301 redirects. If you don’t, you loose all value of all links you had built up… There are many known examples of websites left with only 20 to 30 percent of their website traffic after a migration, so make sure that does not happen to you!
2. Rankings on important keywords
A new website often entails a new house style and new texts. Sometimes even new product names. By changing text and renaming pages, it could be you loose rankings with search engines on search terms that brought very relevant traffic. So always take a good look at your analytics before you rename products and make absolute sure you don’t loose important rankings.
3. Hosting in the right country
For search engines it is of continuous importance a domain is hosted in the country for which the site is intended. This usually brings the best user experiences by far. At the transition process of the new site, do not start checking whether hosting in the US is a lot cheaper; because in the end best is cheapest.
4. Do not change WHOIS data
When a website is completely changed and has new hosting, it is not a good idea to then quickly change the ‘WHOIS’ data, the ownership data of the domain, as well. Search engines have the nasty tendency to treat sites that where changed in one go as a sold website. They then reserve the right to have that website completely rebuild its rankings and strip it of all its “old” value. That is another situation you definitely need to avoid.
5. Measuring is knowing
Before going live it is essential to first assess the actual site or application capacity. There are numerous programmes (for example jmeter) by which in a simple way a site user can be simulated. By simultaneously running more of these simulations, and meanwhile monitoring the environment on different parts, you can establish the maximum amount of users the platform is able to process. Based on this a scaling plan can be drawn up.
Please note that especially on larger sites, it is often forgotten to estimate search engine bot traffic. In case of a new version of a large site this can really add up to spidering of thousands of pages per hour. It’s then a good idea to first, take this along in performance tests, and second, to not allow search engines as Live and Yahoo! full access until later and set a crawl delay for them.
6. Are users visible in site performance? Upscaling!
It’s always wise to continuously measure user experience (in terms of actual speed) of a site or application. This enables prompt detection of critical delays (DNS resolving, bandwidth, number of connections, html). In case of a noticeable difference in site response time on weekdays and the weekend (with the site being visited more on weekdays than in the weekend), this is usually a reason for upscaling. The number of users (without hitting maximum capacity) should have no visible impact on performance measuring results. An example of such a measuring survey can be found here.
7. There is always something to cache
To cache is the temporary storage of (parts of) websites or web pages using an intermediary infrastructure. When data, already stored within the cache, is requested, the application does not need to generate the content again. Websites and applications always have cacheable parts. This includes dynamic content with users getting served user specific generated content. Take, for example, a forum. A forum is static up to the moment a response or new forum message is posted. In case of such an action a cache can be instructed to reload that specific part. There are also type content caches (e.g. images, videos or completely static texts) that can cache information for a certain period of time.
8. Put users and servers as close together as possible
In the Netherlands AMSIX is a popular internet exchange point. This exchange point links providers of the user side to users at the content side to bring content and users as close together as possible. In general, the rule applies the shorter the network distance (measured by the actual distance and the number of intermediate links) between two points, the faster the transfer of information between those points. For sites in the Netherlands, with users located in the Netherlands, goes: make good use of AMSIX. For sites in other countries, it should be carefully examined how to put an application as close to the users as possible. One possibility with this is the use of content delivery networks (CDN). They place (parts of) content as close to the end users as is possible. A well-known example of an environment using this is Apple’s iTunes Music Store.
9. There is always something to cache, also at the back end
Many web applications and websites use centralized data storage, based on, for example, a database. These days virtually all databases have a concept of query-caching; if the query appears multiple times, and the data set is unchanged, the query will not be executed; the result of the query then comes from the cache. Besides caching of queries within the database, application layer connections can be cached to the database (this is not really caching but reusing existing connections: connection pooling). Good to know, as creating a connection is a time consuming process.
10. HMTL or HTML
The order in HTML is important. Is JavaScript used on the site? Then make sure JavaScript blocks the loading of components in the html until all components are loaded in JavaScript. Tools such as Pagetest but also
Yslow on Firebug offer (also on some of the issues above) useful insights.
11. Video? Not too fast
A video gets played at a certain number of bits per second (bit rate, depends on video’s codec and quality). Make sure when a certain video is requested it gets conveyed to the server with slightly more bits per second than the video bit rate, otherwise the download speed is determined by the bandwidth of the viewers. As most people nowadays use a DSL connection, the number of viewers becomes restricted. Take the following example. There is an available internet bandwidth of 100/s mbit. Ten users with DSL connection can then download at 10 mbit/s. At that moment the whole available bandwidth for these ten users is used. But the video only has a playback speed of 256 kbit/s. By transmitting that video at, for example, 350 kbit/s, the user capacity exceeds 290 users. Please note these users make use of the capacity for a longer time. A compromize would be transmitting the first ten seconds of the video on full speed to then decelerate to a slower speed.
12. Does the application perform well in a cloud?
The new hype in internet infrastructures is called cloud computing. Basically, a cloud is a large number of linked computers with virtual computers purchasable ‘on the fly’. Only actual use needs to be paid for. Advantage of this approach is that there is no need for advance investment in a complete platform. By setting up the application in such a way it automatically scales itself; for example by duplicating itself on a new virtual computer at a certain capacity need (autoscaling). This a really interesting development for platforms whose popularity is hard to estimate; the investment is low and the platform, if well designed, has enormous capacity. Animoto is an example of such a platform, and is based on the Amazon EC2 cloud.
Leave a Reply
Learn more about our services.