Since there are already quite a lot of responses to your original question I'll instead address a specific aspect of your post: when you have an old legacy syst

Since there are already quite a lot of responses to your original question I'll instead address a specific aspect of your post: when you have an old legacy system that you don't want to build on any more it is almost never the right decision to try a one-shot migration or rewrite. I have seen so many people try and solve technical debt with a full rewrite and it just never works. The better way of solving this problem is to gradually peel off individual use cases and API calls. It doesn't matter if your legacy system is riddled with bugs and is impossible to build on; it's at least a known quantity. Your new system will likely have less bugs in it, but until it's been used in the wild for a while you won't know where those bugs are. If your new system has a systematic problem, you are in some serious trouble, but if you migrated over slowly at least it will be manageable.