Dealing with legacy systems: when to rewrite vs incrementally improve

we've got this colossal 10-year-old php monolith. it's got no tests, uses outdated dependencies, and frankly, it's terrifying to touch. management is eager for a full rewrite in go, promising a shiny new system. but i've seen too many failed rewrite projects turn into multi-year death marches that never ship. on the other hand, incrementally improving it feels like trying to fix a leaky boat with duct tape while sailing through a storm. the technical debt is so immense that even small changes are high risk. we're trying to figure out a framework for deciding when a full rewrite is truly justified versus when incremental refactoring, strangler fig patterns, and chipping away at it are the better approach. what factors do you consider when making this build vs. buy (or rewrite vs. refactor) decision for legacy systems? what are the red flags that signal a rewrite is doomed? any successful strategies for incrementally modernizing a truly ancient codebase without starting from scratch?