Thanks for sharing your experience in a well written and organized fashion. After over 45 years of software development this is one of the first examples I have seen of someone (successfully) rewriting a legacy application that is fundamental and core to an organization's mission.
I have often thought about the many legacy systems I have worked on as a maintenance developer and whether or not they could actually be rewritten - most can't. Here's why and why you had success (I think).
1. Access to the original developers. Product managers, sales and execs come and go but if the core development team still exists then the business rules may still be available in their heads even if it is not available in documentation. Sometimes, very, very good engineers who know the language the application is written in can deduce the business requirements (or at least the intent of the code which many not actually satisfy the real world requirement - caveat emptor). With APL ( that I am proud to say I programmed once as my primary language) you're screwed without the developers.
2. You seemed to have had, if not an understanding, at least a detente with management. Without that, you may have been driven by the forces of "when will it be done" and "show me a demo" management that has no patience for projects that take more than 3 months.
3. You didn't mention the other gotcha in many attempts at rewriting an application in a big company. There is often layers of IT management that impose their own ideas of languages, architecture and resources that make it challenging if downright impossible to fit the solution, if not perfectly, at least appropriately with the problem domain. Forcing XYZ technology on a project when the team either believes ABC would be necessary or has no skill sets in XYZ is further friction that exacerbates the one thing that drives management nuts - an inability to accurately predict any milestone on the roadmap.
4. Legacy applications are successful - that's why they are legacy applications. Why would you rewrite something that works and powers the cash cow? Forget technical debt - let's focus on new features. So there's that - inertia. Put aside all of the reasons one might want to rewrite an application - this one factor trumps everything - apparently someone in your company had the vision to realize that APL programmers die and there are (probably) not enough new ones or people willing to learn a new language to support the product forever. The risk of the cash cow dying along with those programmers was a risk too big for even the exec with the narrowest of tunnel vision to ignore.
5. Lack of documentation - which can be compensated for by #1 - but only to some degree. Even seasoned developers forget the reasons they wrote code the way they did or to what end. Makes me wonder how today's systems (i.e. tomorrow's legacy systems) will enable developers to piece together the requirements of the system by reading JIRA tickets (or God forbid Confluence pages)? ;-) I am a big advocate of making sure that systems are well documented and the documentation lives with the implementation. Even better still is a system that has as part of its architecture a documentation framework that lives within the application itself and is somehow mandated by fiat or design to remain in sync with the application. And links to external systems like GitLab, GitHub, or BitBucket are not what I am referring to. If you've every relied on those links you know what I am talking about.
Finally - if I might do some "rewriting" myself:
1. Executives must be aware of and invested in the mitigation of the risk of a legacy application
2. Product Management wants to see progress - communicate effectively
3. Development teams must have have time to do things right (so carefully vet and document in architectural decision documents what right actually looks like remembering that this will a legacy application someday)
4. The business has to keep running
5. The legacy team needs to still be alive to transfer knowledge to the new legacy team
