This is one objection that our sales people get quite a lot.  Often because people in this position are starting to look at how they'll test the new site before launching and enquire about our services.

Website managers often hold the view that until the new site is heavily populated with content that it isn't worth spending time testing as there's nothing to test.  So, yes, they are interested in Sitemorse but "not just yet". 

However, lets look at the rationale behind the presumption that taking Sitemorse when you've just embarked on a major redesign of your site is a waste of time.

Will ABSOLUTELY NONE of the content from the old site move to the new site ?

Unlikely.  So you can be testing the current content right now to make sure it's OK.  That way you don't taint the new site with old errors.

PDFs are a great case in point.  I would suspect that most of your PDFs will move to the new site.  Make sure that they are all accessible and that any links and mailto: links work.

How about Templates and Style sheets ?

They may change but who wrote the old ones and who is writing the new ones ?

If it's the same people or the old ones are being updated rather than scrapped you could bring poor quality practices into the new site from the old.  Test them now and clean them up.  That way your developers will familiarise themselves with best practice BEFORE coding the new site.  It's often easier to learn by your (or others') mistakes than to learn from a text book.

What about external links and feeds ?

It's pretty likely that you'll retain a high proportion of your existing links and feeds.  Do you know how well they all work right now ?  How many links fail on your site currently ?  How many have permanent redirects set up ?  How may mailto: links go to non-existent email addresses ?  Now is a good time to find out before you port them to the new site.  Sitemorse will also test the first page of a linked site, running all of its test on that page.  If it fails miserably you might choose not to link to it anymore as it would taint your new site's image.

How accessible is your current site ?

If you find out what you didn't do too well on the old site you can make sure you don't repeat the same mistakes on the new site. 

Hindsight is OK but foresight is much better.

And is your code standards compliant.

As this is the section that most organisations get their lowest score it's reasonable to assume that the most likely case is that it isn't.  Internet Explorer has been very tolerant of non-compliant code (see my blog posts http://blog.sitemorse.com/2008/06/firefox-3-hits-8-million-downl.html and http://blog.sitemorse.com/2008/06/ie8-standards-compliance-issue.html) which has allowed coders to write code that they assume is fine because it seems to work OK.  My blog posts explore this topic in more detail but essentially that fact is becoming less true as Opera, Firefox, Safari and now IE8 become much less tolerant.  Check out what you do wrong in your old site now so you don't make the same errors in the new site. 

It's MUCH cheaper to engineer out errors while you're coding than to correct them later when you're testing or they fail on the Live site.

I believe the answer to the question of when should you start testing your new site is BEFORE you even start to develop it. 

We have seen many new site launches spoiled by poor content transferred from the old site.