How do I stop ending up on death march software projects?

I end up on projects that stall and slowly fail. The goal is clear, but no one knows how to get there. Stakeholders are more concerned with keeping a slowly deteriorating status quo. My role is described to me as "ripping things out," but no one wants to risk ripping anything out. How do I learn to identify these projects early? They are bad for my career and they're also very stressful.

I am "in charge of" a large installation of our products at a customer site. I have a team of five that gets whittled down to two. A big restack has been in planning for a long time when I join the team. I realize that we aren't ready to migrate. It's not clear how we can get any more ready. The installation is set up with many opaque plugins of unknown provenance. We don't know what they do or how many users rely on them. We are afraid to ask the customer about what features they use, because we can't give the impression that we don't know what we're doing. We don't know what we're doing. We go through the motions of planning the migration and repeatedly postpone it. Nothing is done by the time I leave the project.

I'm tasked with rewriting a big feature on top of a beta plugin framework. The feature is threaded chaotically throughout the application and comes in a dozen variations and code paths. No one seems to know what some code paths do. Several features no longer seem to be in active use. No one can say what's important to keep. The PM says the rewrite should keep all existing functionality and be invisible to end users. After months of dead ends, I obtain an internal transfer.

An employer wants me to fix some data pipelines. They have been missing SLAs by days and weeks. The pipelines are flaky because different parts are owned by different teams, and each has reserved the right to pull the ripcord, because the current setup shields them from the risk of shipping a broken result. The aggregate effect is that nothing ever gets released. I soon leave the company.