In this specific case I could imagine supporting both carbon and cocoa screens / logic at the same time, and begin conversion screen-by-screen or feature-by-feature.
In the end this might mean maintaining extra complexity to support both technologies, but protects you from the danger of having to implement a complet syst m to feature parity at once.
I think it would make more sense to slowly port the Windows version to Qt. And then when that process is complete, you get a Mac and a Linux version.
"We are still planning to support the Carbon Event Manager and Text Input Sources, to name two mostly non-UI APIs. You might wonder, what about the Memory Manager, or the Alias Manager, or the Process Manager, or other lower-level managers? At this time, it looks like most, if not all, of the APIs provided by the ApplicationServices and CoreServices umbrella frameworks will still be available in 64-bit." - Eric Schlegel (apple developer)
It’s so obvious - why has nobody done it before?
Moreover a complete rewrite doesn’t exclude any truly unique parts of the old codebase from being ported into the modern one.
(I voted him up, but the analogy did make me squirm.)
Hopefully you can just swap out a UI layer. You shouldn't need to rewrite any business logic.
The best path forward if you want a program that works like the old one but runs on the current version of macOS is to use the old version to create a requirements document and then develop that using modern techniques.
Same as with restoring a 19th century farm house with a bad foundation. The cost of restoring it and bringing it up to modern standards will typically be 5-20 times more than knocking it down and building a lookalike from scratch using modern building techniques.