I have read it, I read it long ago, I've got a copy of Joel on Software in handy reach. But during the last year I migrated a ASP.NET--WinForms and VB.NET--project to Oracle APEX/ORDS. I'd have vastly preferred to leave it to be maintained as it was: but Microsoft had bought the company the produced an important set of controls, and had dropped support for that package; but for a number of reasons the system was hard to secure; etc.

Large? The component I migrated amounted to fewer than a dozen pages, with a lot of Javascript and T-SQL in addition to the VB.NET. Old? Say 2010.

I overwhelmingly agree with this. I think it's probably the worst decision you can make in 99% of cases.

The problem is if you don't consider a rewrite at some point, you're just as likely to have some other product come along developed elsewhere that isn't held back by the constraints of your own and steal your market share.

I don't doubt a lot of rewrites end up being disasters, because insufficient attention is paid to the actual problems being solved by the warts and bits of chewing gum and baling wire in an existing codebase. And potentially because they're simply not done in a way that confers sufficient advantages over sticking with the existing codebase. But I can think of many cases where I ended up spending longer dealing with the consequences of the poor design of existing code than it would have taken me to rewrite it properly from scratch. Hindsight being 20/20 of course.

Then of course there's this...

http://thecodelesscode.com/case/33

Or you can keep business as usual while build a separate high skilled team to do the rewrite. Things are hard to build but easy to copy. Unless you're talking about massive progress like OS/Browser, a few highly competent engineers can copy anything in a better structure within a short amount of time.