You’re in the danger zone where the current codebase has been mentally deprecated, but no replacement exists yet. It may seem like a small detail, but declarin

You’re in the danger zone where the current codebase has been mentally deprecated, but no replacement exists yet. It may seem like a small detail, but declaring your only codebase “legacy” before you have a replacement is a bad move if you have any customers or active use cases at all. You may not like the old project, but you need to be honest with everyone that it is your bread and butter until the new codebase is written. If you start calling it “legacy” and pretend that new hires will only ever be dealing with something that doesn’t exist yet, you’re setting everyone up for disappointment when business realities make the old codebase active for far longer than you expect. I’d hire now, and hire with the expectation that new hires will be working with both old and new codebases. Don’t set your company up for a situation of competing codebases, or worse, competing developers depending on which codebase they’re each working on.