The new version of both sites is slow, sluggish and provides me with no benefit.It's about par for the course when a new dev group and/or manager comes in and wants to make their mark. I generally find this sort of thing facepalm-inspiring-not-so-smart. For one thing, there are so many examples out there of how this can go wrong. (see sorenjan's cousin comment) For a mature long-running production system, the right thing to do is to bias for continuity and incremental change. This isn't to say that redesign and progress are forbidden. There are usually benefits to be had. I've been a part of teams that have implemented radical changes to underlying frameworks. (Re-hosting from an object database to Oracle, for example.) My experience is that there is almost always a way to do this incrementally, but that ego and limited imaginations get in the way of doing the right thing.
When you're out to re-architect or re-host a long standing production system, there are two things you should absolutely do, absolutely:
1) Avoid disrupting the current users
2) Preserve the hard won domain, operational, and optimization knowledge of the previous development team
The goodwill of the users and the good reputation of your company/app were won with great effort and expense. They are extremely valuable. Degrade those at your peril! Likewise, the hard won domain, operational, and optimization knowledge of the previous development team were won with great effort and expense and are extremely valuable. Degrade/disregard those at your peril!
I think I would like to ask new managers who are going to "make their mark" by re-implementing something if they can absolutely guarantee 1) and if they can quantify 2) and back themselves up empirically. Then, when the project is done, ask how good they were at answering those questions.
Just the 2 cents of a hoary old veteran.
(A couple of hints, for those wondering how: Automated test suites and syntactic code rewriting are your friend!)