Personally, I find it really fun. It's a nice mix of development, design, and organizational understanding.
What I want to do is divide up the project. Usually, these legacy systems don't have clear division points; it's all a big bundle of interdependence. But in my experience, there's usually some less impactful secondary functionality that can be spun off.
That will allow you a few things:
Figure out what you quantify as success for such a project. Its limited scope makes it easier to identify the endpoint. Allow learnings about the legacy system, and perhaps identify what elements you can extract from it—not necessarily code, but in previous work, I've been able to wrap or scrape data in certain areas to provide a sort of external output. Figure out how to work with devs, manage your own time, and educate your organization about what you're trying to do. The third and last point is critical. The failure modes for development are obvious, but the political and design impacts are less so:
1. Lack of experience
2. Poor scope
3. Overly complicated solution
etc.
But the real failure mode is political. You need a developer with some political acumen as well. There's going to be a lot—and I mean a lot—of interviewing people about how exactly subsystem X fits into their workflow. You need the political skill to navigate that, in terms of getting buy-in and quality information.
Downstream of the political dimension, in my experience, is the possible design solution. The actual interviews with people and the regular, constant contact with staff about their job are critical to building something that replaces the existing system but doesn't replicate its design failures.
One mistake you want to avoid is building something too similar to the old solution and missing out on critical information about how the job is actually done.
Also, I'm not currently looking for work—enjoying my current role—but if you want to hit me up, feel free. I can at least impart some experience on what to do.