Nice, glad to know there's other brave souls that choose the Big Rewrite path, despite the latent idea in our industry that every one of those projects are meant to fail.
I'm a simple employee with some management duties, it's small company (20p), I estimate my wage to be on the low end of the local market (french, not in the capital), but the position is quiet unusual so it's difficult to compare.
At the beginning there was only vague goals, not estimates, now 4y later I can tell how much days a functionality will take within a 30% margin error. But it's only based on personal appreciation, tightly coupled to having personally designed the new arch from the start.
The migration strategy that I chose was to hijack the sales activity and pick which new projects should go on the new version. That way we can stay away from replacing years of specific functionalities for picky customers until we have a good idea of how much the business module is ready for prime-time.
I should definitely write a book, there's so much to say - maybe in 2020! :)
We're (team of 2) rewriting an old enterprise ERP system made of ~1M of C89 non-portable loc, tens of thousands of handwritten PLSQL loc, thousands of business rules carefully abstracted in sql data, tens of complex screen designed and scripted on a no-name RAD software that was the current fad back in the days, and some companion pieces in VB6 because, you known, 'C89, not anybody can do it'.
That's fun.
The new system is a quiet simple SOA arch with a dull, only-real data db layer, backend in Go with code-generation, frontend in es6 migrating to elm.
That looks the IT guys have when we say 'no really, we don't need IIS or Java', its priceless :)
The interesting part actually lies in handling both product management and sales for the new version while handling the day-to-day coding part.
Sometimes I think I should write a book on those subjects :)