Well, I think the most projects you do you discover new ways to do things. For these reason i think know new languages or frameworks can help you with your old legacy code.
For this reason i think you always have to go straight and advance in knowledge, and the most technologies and libraries you see you can take ideas to refactor your old projects.
Another idea is to read documentations, examples and screencast about the clean code and decouplement of code, and when you have more knowledge, return to your old project and apply!
for other side, you projects always can be better and for this reason i think always change and adapt to the new ideas.
For personal "toy" projects this is totally fine. You may want to use this to try out the features of some framework so that you can use them in upcoming projects. It's a good way to see the pitfalls of the framework or language.
However, for projects that you get paid for it wouldn't be advisable to just gut them to put in new stuff. This may probably delay development time greatly especially if you get stuck with a bug that these new features introduce in your app (and there's no one on StackOverflow to help you).
One cool method I've seen my teammates at work use to branch the current version of the app (using Git or SVN). They then do all the experimental stuff there and run all the need tests on their own time(maybe at home). They finally pitch it to the team juxtaposing the pros and cons of the old and new apps with each other.
Yes and No! If the project is more than bunch of files, I won't change it, unless the client request me to do so, which don't happen very often.
But if the project is simple and doesn't cost too much due to downtime, I will play with it. Mostly I will start working on the code and use sub domain to test it. Once things started working fine, I will migrate it overnight!
Coming to your question, for the urge you mention, I will write a tiny service which can be used in existing projects. I used CI for a medium sized application but once I have seen Laravel, I couldn't stop wondering about it. So took some time, learn it and implement a tiny module of the same app using Laravel and I'm pretty happy about it. Now I'm planning to use Laravel for creating APIs for mobile applications. So instead of changing the project as a whole, we can create microservices, or some helper utility kind of things which can be pretty fun, easy and get us going!
After looking @mgiambanco reply, I would like to add that this applicable to side projects.
When it comes to employer, I'd be happy to do it, if only it justifies the cost and time of migration. To give you an idea, we've migrated a big transaction based project from struts to spring and it took us close to 5 months. Was it worth it? Hell yeah. Development times went considerably low, and associated costs went down. But if the project was already in Spring, then it makes no financial sense to move it to PHP or Nodejs(just for an example!)! So it all depends on factors!!
I do think my old projects are kind of terrible, and have many ideas to of what I could do better.
But if the project isn't actively used, it's more fun to make something new, so usually I don't do rewrites (90% of my hobby projects aren't used for long, or even finished).
(At work the result IS used, but it's not my call to rewrite it. And it's not very economically viable to do big rewrites, at least short term, so instead technical debs keeps piling up).
This question could be divided into 2 sides - personal side projects and paid work. For both, you can ask yourself the same question:
Is there a reason the old way no longer works or is no longer viable?
A very important concept for programmers to learn is that time is money. We are almost like lawyers in this respect. Every hour you spend should be billable. If the client / customer / company isn't paying for it, it shouldn't get done.
So if you have a personal side project that did something unique from your other projects, and you want to try to redo that project in a new framework / language - sure! Go ahead. Personal side projects (not billed) can be done in whatever you'd like, how ever many times you want to do them.
But if your working for a company; if someone paid you to do a job, those hours should be billable. And unless the new framework / language introduces a feature the project could use, the customer, under most circumstances, would never pay for that.
There are many caveats to this obviously -
Maybe this new way does something really cool that the old way didn't and you want to show it to the boss and get them to approve it. In this case, any website > 2 pages will need to vet the new language / framework and be discussed.
Maybe you scoped the project wrong and this new way is really a better way then the old way. In this case, you can discuss this with the client, propose the new way and see if they want to pay for it.
Maybe the customer is unhappy and you want to provide a value add. Here, you might be better off giving a refund of sorts.
Going back to the side projects; an employer would be much more impressed to see multiple projects in different languages / frameworks on a portfolio then to see all of them in the same language / framework. It shows diversity, it shows options and it shows the ability to learn. If every project you have is in 1 language, then you've become very niche. If you show projects spanning 3 or 4 languages, that makes you diverse and leaves room for the company / client to have options in the future with the same programmer.