Altering or moving a large website can feel scary.
Are you about to embark upon a major change to your website? Are you updating the page layouts or the site architecture? Or moving the site to a new Content Management System perhaps? Or maybe both at once?
It just feels like a lot of work doesn't it? All those pages... All that different content. There's a lot that can go wrong across the board:
- Pages, images, documents and so forth can move from where they're supposed to be, or disappear entirely.
- Links within pages and navigation can break.
- Page addresses can change, which means links both inside AND outside the site (such as those from Google) will break too. So any effort you've put into Search Engine Optimisation is at risk of being negated.
- The metadata that your pages is tagged with can get out of sync and no longer match the content it is supposed to describe.
- Or you may be changing the site's metadata taxonomy, which means you'll need to alter the way pages are labelled and categorised.
- Pieces of custom functionality (such as special database searches or the site search engine) might break.
- Pages that used to validate properly against web and accessibility standards might stop doing so.
It could all just become a big mess if you don't check it all. But how are you going to do that? By hand? It'll take months, if not years!
What's more: do you know for sure that everything's working properly to start with? Any large site is bound to have a few issues and bugs in, but if you don't find out where they are (and preferably fix them) before the change, how will you know if the change is breaking things, or if they were broken in the first place?
Your site has to change: maybe the CMS is out of date, or the provider's gone bust and its no longer under support. Maybe the design just looks old and tired, and customers are defecting to your competitor's shiny new site as a result. Your bosses are demanding that the change happens.
So what are you going to do?
Check your content (whether you're expecting a problem or not...)
Assessing the impact of a major change to a website's infrastructure is simply hard work. This is despite what CMS providers and / or design agencies may say: it's in the interests of people profiting from such change projects to play down the complexity of the job to help close their deal with you.
Changing the first 80% or so of the content may seem easy enough: the bulk of web pages on any site by definition use 'standard' CMS templates, for example, so once you've organised how 'standard' content displayed in a 'standard' way is going to change, that's most of the job done.
What about the 'non-standard' stuff, though? What about all those pages that your developers and site managers spent ages crafting to solve specific problems? They only exist because important end-users had enough of a business need (and enough organisational clout) to get someone to put in the extra effort to create them.
Are those users going to be happy when your major website change breaks their important custom pages and applications?
The extra 20% of 'non-standard' content is where most of the pain of a major website change lies, and it is this 20% that presents the greatest risk to your project. Many of the pages or pieces of functionality in that 20% are "feature content" that makes an important contribution to the message your organisation is trying to put across, so damaging that content is not acceptable. But 'working-around' non-standard content during a change can be time-consuming and difficult.
There might also be 'standard' items in the main 80% of the content that present problems, too. For instance, if you are redesigning the layout of a website's pages, a small proportion of the 'standard' set might contain images sized in a way that worked in the old layout but which cause problems in the new one. How are you going to find them and get them working again?
All the above points towards the fact that testing a high volume of content (both 'standard' and 'non-standard') is crucial in order to prevent a major change to your site causing errors, making it harder and less pleasant for visitors to use your site, and hence damaging your organisation's reputation.
And until recently, the only way to carry out such tests was by hand; by physically eye-balling the pages and their code to check that the content most likely to break still worked and to look for unexpected problems in the midst of hundreds or thousands of 'standard' pages.
There must be a better way?
So it's a fact that making a major change to a sizeable website (e.g. more than 750 pages) presents a tough challenge. But, like all big, challenging problems, it can be made less of an issue by approaching the problem methodically and working smarter:
Don't underestimate the effort needed to make a major change to your site. As mentioned above, CMS companies and designers will often downplay this as it queers their pitch. Don't be lulled into a false sense of security about how 'easy' it all is.
Similarly, don't skimp on the testing budget either, or issues will inevitably slip through, the project can overrun and developers end up fixing issues months later. Which of course costs a lot more than it would do to test properly in the first place.
Papers by Industry Leader Vamosa (1) estimate that a major website migration project (from one CMS to another) can cost between $25 and $220 per page if done by hand. They calculate that automating this process can reduce the cost by up to 80% as well as improving the quality dramatically.
Vamosa also estimate that the cost of testing the outcome of the migration can add 150% to this figure. All these costs are over and above the cost of the new CMS, too.
Put effort into scoping, planning and organising the change. Development teams often dive into the mechanics of a big change first (such as redesigning page templates). It's far more important to take stock of what you have before you start on the development itself.
Assess the size of the job, the nature of the tasks involved and where all the difficulties are likely to occur before you start writing code or changing designs. In a nutshell: 'plan the change properly'.
Have a clearout and tidy up. Every piece of content contained in a website that's changing is a potential bug once the change has occurred. So reduce the size of the problem first by removing content that's out of date or which nobody ever uses.
Also, pre-existing bugs and issues are going to confuse things once the change occurs. Were they there beforehand? Or did the change bring them into being? This can cause some real red-herrings for programmers, so at least have a good hunt for bugs and fix them (or at least note their existence) before the change happens.
Start planning how you are going to test at the start of the project. People often put testing to the back of their minds, but testing isn't something you should "wait until the end" to do. It makes no sense to do that... How are you going to deal with the issues the testing WILL raise if there's no time left?
Don't just throw effort at the problem, try and be smart about it. Computers are ideal tools for carrying out tedious, repetitive work (which testing usually is). So why not use them to make the testing job easier?
Benefits of automated testing
Automated testing is faster and hence cheaper, and in most cases is more accurate too. Plus it reduces the size of one of the most tedious jobs in a big website change project, sometimes by as much as 90%. So if you were to introduce automated testing to your change project your development team will love you for it.
The automated testing of changes saves so much time you can often run several "test runs" before the big switch-over comes, too. This gives you the opportunity to improve your plan, thus increasing the quality of the new site and reducing the stress involved in the project.
So, while we're not saying automated testing makes a big change easy, it definitely makes it a whole lot easier.
Trovo's Automated Testing Suite for when Websites Change crawls your pre-existing site, capturing information about content, links, page addresses and metadata. It can even take screengrabs of pages (or parts of pages).
It can then crawl the new, changed site, comparing it with the old automatically, and flagging-up potential issues and discrepancies for your developers to check. So they don't have to spend time eye-balling hundreds of pages. They just need to focus on the ones our system thinks are broken.
But you must act soon... Don't test too late
As mentioned above, testing the effects of a major website change is something that you need to plan, prepare and leave time and budget for from the very beginning of a project.
While our tools are a great way of taking the testing pain out of a project, they are much more effective when first let loose on a project near the start, as it's usually much easier to act upon the information they provide earlier on.
Also, our testing tools are ideal for finding pre-existing bugs and issues with a site so you can clean them up before the change occurs.
But a successful website change is not all about fancy gizmos. Trovo has some of the highest level project management expertise in the UK at its disposal, so we don't just bring our tools, we can help you and your team get a proper handle on the entire problem.
Yes, a major change to a big website is a big challenge . But with our help it need not be a scary one. So if you're about to embark on a major change to your website, call us and tell us about it on:
0116 232 5147
or email:
We can help you make your website change for the better; faster, cheaper and with much less stress.