[codingdave]

There might be a book that has some info, but a migration off a legacy stack is not a cookie cutter project. It requires understanding of how the entire system works in a way that you can devise a plan of how to slice it up and move one piece at a time without breaking things.

Because in general, the migration will first need to be planned without consideration for technical roadblocks. You decide which pieces to move, in what order, based on what your desired final solution is. You then identify what is stopping you from making those moves and you spent a bunch of time and effort mitigating those roadblocks. That could take you a year or two. Once you are actually ready to start migration... execute the plan. Another year. It sounds slow, but a 3 year plan to decommission a legacy product is fairly standard.

In any case, people like myself exist who have done such projects, but we don't know your product. So while you are correct that getting some outside advice may help you find your direction, nobody external to your company has the knowledge to truly make the plan. You need to put your heads together internally and use your knowledge of the legacy system to plan things out, while also figuring out how to keep the system alive while you migrate. Identify which pain points in the system impact your customer, and focus on fixing those so that your customer base doesn't revolt while you take the time to move the stack.