About a month back we flipped the switch on our website, moving away from a Frankenstein code base that was patched together from an old version of Community Server and a standard ASP.NET website. Being that we’re all geeks here, I wanted to post about how we handled the migration and to share some information about the products and technologies we used.
One classic problem that us geeks usually suffer from is that we change things for changes sake. We love building things and often ignore the actual need to do so – or even if there is a need. So we started by nailing down exactly why we should migrate our website:
So with these improvements in mind, we made the move.
1. What actually would be "better"?
We needed to pick what software we would use to replace the bulk of the website. As mentioned, we had a mix of a standard ASP.NET website and Community Server. We had stripped back Community Server to only powering our forums and the login system. The site content was basically just static content (oh the shame!) and the store was our own application.
We wanted to move to ASP.NET MVC, make the informational part of our website content managed and more easy to maintain and thirdly we wanted to marginalise Community Server even more. I had been looking at various CMS products for a while and knew I wanted something light weight that was built with ASP.NET MVC. Being in ASP.NET MVC we knew we could get sensible and attractive URLs and a really nice development model for when we did need to make code changes and update our store.
The search led us to N2CMS – a fantastic little content management system that I can’t recommend enough for .NET Developers.
I set about building page templates for the different types of content we had, Jeremy migrated the store and cut Community Server out of managing our user accounts. We kept the CS Forums for the time being but they’ll likely only live until we find the time to migrate to something better (any suggestions?).
N2 ended up being brilliant for us – it was easily extensible, integrated happily with non-N2 parts and had a beautiful development model. It didn’t try and bring the kitchen sink with it which is a problem that many CMS products suffer from in my opinion.
2. URLs were going to change
The CMS we selected was built using ASP.NET MVC and could accommodate much nicer looking URLs. We wanted to use the tidier URLs but also knew that we’d be breaking every URL in the website as part of the move. We of course altered most of the site content to use correct URLs but there are thousands of websites that link to our website and we don’t control their content.
To solve this, we setup our 404 handler to record any 404 responses to the database along with some statistics about when the 404 was generated and how many requests had failed to date. This allowed us to quickly see the pages generating the most failures and fix them first.
N2 CMS makes it super easy to integrate into the Admin site so Jeremy wrote a simple jQuery powered page that listed all the failures as well as the redirects that were now in effect:
This made life very easy for managing missing pages and handling the redirects. It’s still running now however we will likely turn off tracking soon as most failures being generated now are from spam bots trying out common URLs.
3. We wanted to improve performance of the website
The page load times for the website were alright before but we knew we could do better. Our existing host only provided IIS6 on Windows Server 2003 and we really wanted to get onto IIS7 with features like Dynamic Content Compression.
We had used Amazon EC2 in the past for some sites and knew we could get the performance we wanted along with the features we needed. We setup the preview site which we could work on for content migration a few months before we flipped the switch. The price of an EC2 instance was also cheaper than our existing host which was just the icing on the cake.
Google Webmaster Tools gives you statistics for your average page load times – see if you can tell when we moved to EC2:
This is before we do anything regarding content (for example, CSS combining and minifying etc.). It will be interesting to see how much those types of changes aid the site performance further.
The grand conclusion
Overall the site migration was successful – we now have a much faster website which is great for our users. We also can now manage the content more easily – not requiring a website release to change text on a page is always nice and hopefully will lead to increased "freshness" of the site content.
One of the the unexpected technical benefits we found from the migration process was the act of auditing the site for migration allowed for a lot of beneficial refactoring which both reduced the amount of code in the solution and helped tighten up the domain model and business rules in place through the website. We also found quite a few pages which had been previously used for miscellaneous campaigns over the years which could now be removed.
We’re now working on a website design refresh. We’ve applied a new design to the homepage (check it out and post your feedback in the comments) and will be working on getting this style across the entire site in the coming month.