Well, first, somewhere, there was a miscommunication about the level of test they were interested in discussing. You were focusing on the lower level "what would I do to test ..." and they were interested in knowing what risks there were. If that sort of miscommunication happened a lot, then there's a larger issue there than how you answered, possibly having to do with the role you were interviewing for.
Second, I'm not sure you understood the size of the question they were asking. What they're proposing to do is often described as "changing the wing of a 747 while the plane is in flight." They want to completely replace part of a system without changing other parts of it. What you suggested is regression/API testing, which is part of, but nowhere near, all of what is needed in this case. Many such projects fail because they're so hard to do for any system of a realistic size.
As risks and mitigation plans (which I wouldn't consider part of a QA/test role's responsibilities to come up with; risks, possibly, but not the mitigation plans; that is more of a architect/project planner responsibility), some things that come to mind:
1) Performance. Can the new application handle the same load as the prior application? How well does it scale, compared to the other application? Does it have different stress points? (i.e., old version started slowing down because it saturated the database I/O, new version slows down because it starts having to page to disk, or something similar). Depending on the results of the test, you might need to move to different hardware, shard the backend database, or redesign the new application.
2) Known errors/undocumented functionality. It's actually common for systems to have either bugs or undefined behavior, and for client applications to rely on that behavior. So your replacement system has to not just behave the same way as the spec says, it has to behave the same way the other system actually behaves. In order to test this, I'd probably want to implement some sort of record/replay functionality at the information flow level, and verify that for a given client input, the new backend gives the same response to live data.
3) Complexity. As I said; these efforts are very hard to do, and tend to fail. A better way to approach might be to rearchitect the current backend so as to make it less monolithic, and have more defined silos of responsibility. Then you can, instead of replacing the entire thing at once, replace it in pieces.