Well, that's already a warning sign. If you don't have the talent to do the rewrite, consultants and remote developers in India are only going to make things worse.
I don't think this is necessarily a given, but I see where you're coming from with the overall perspective.
To get closer to the point of the post: unless there are truly solid and unavoidable blockers, e.g. substantial architectural defects that just can't be resolved without a major rework, a rewrite of any capacity should probably be off the table.
Although I'm sure there are others that I have no insight into, the only "successful" commercial rewrite I can think of would be Windows Vista, and that only made that version of Windows somewhat releasable. Even then, that wasn't a total reboot even of the project; it was a partial rewrite off of a different codebase with as much code salvaged from the original project as possible (the initial Longhorn builds on top of the XP codebase were a total trainwreck, driving the partial reboot on top of Server 2003's codebase instead). They still needed two service packs to make Vista stable, and it took an entire subsequent major release (7) to right the ship, so to speak.
Actually Vista is interesting. For all its problems, it's actually an impressive upgrade - whilst there was development chaos due to a lack of focus, a new management team was able to significantly focus in on what needed to be done and hundred of improvements were made under the hood. Microsoft rewrote their TCP/IP stack from scratch and included important system administration tools like an improved logging system, performance and reliability tools, a vastly improved desktop window manager, a new graphics driver model called WDDM and a raft of new kernel security measures.
These rewrites weren't rewrites of the entirety of Windows, but instead Windows was increasingly modularised and entire subsystems were rewritten. Whilst Vista was a disaster and had some real problems I don't think it was because of rewriting subsystems, I think it was due to UX changes.
Interestingly, Windows 7 was an amazing success and in fact built on Windows Vista, but again focused on modularisation and leveraging the work done in Vista.
My hypothesis that major UX changes caused Microsoft to stumble in Windows is born out by Windows 8 - which was even more stable and performed better than Windows 7, but was rejected in the market because of insane UX decisions.
So a major rework can be done, but if you are going to do this then I suggest that major changes to UX should be done after the rework.
I don't think you can avoid major rework though. Without some of the things I highlight above, there is no way Microsoft would be able to improve their code or implement features that actual make sense!
Worst of all is when those UX changes are spotty and inconsistent. Windows 10 is a fantastic upgrade, so far as the core operating system goes. But the UI is a complete trainwreck lava-layer, particularly in the control panel and settings dialogs. Bits of it are essentially unchanged from Window 2000, other parts are Vista-era, others from the Windows 7 generation, yet other in the Metro Windows 8 or whatever they are calling the Windows 10 style. Some things can only be managed through the older UI, some only through the new UI, some in both, and some in both, but with subtle and non-obvious differences.
a) Lockdown of "Program Files" directory and UAC which meant existing applications had tricky to fix issues (sortable by IT folks not by end users). Microsoft had been saying for years that many of these practices weren't allowed as part of the windows certification program (I'm sure I did most of this work for Win2K certification)
b) Requiring new drivers for things like printers / scanners. Hardware vendors didn't want to do rewrites for old hardware (there's no money in it for them) so peripherals that used to work got "broken" by Vista.
Windows 7 was better because UAC was toned down and both software and hardware vendors had done the security work a few years earlier for Vista. Folks who did the XP->Win7 upgrade had a much easier time.
From a security PoV Vista was needed.
The only major regression that comes to mind here is UAC. I don't think Vista is considered a failure because of its UX decisions.
In my experience, Vista was incredibly slow (compared to XP) and unstable, and got even worse the longer you used it. Anecdotally, even PCs that shipped with Vista were often unable to run it smoothly.
I don't think Vista would have been a hit with an unchanged Windows XP user interface.
We initially had a terrible experience with remote workers and it didn't work out at all. But we learned from our mistakes and made it work later on. When I left the company, 100% of its development (i.e. maintenance) is done offshore.
The customer simply didn't want to adopt the shiny new software.
The customer confidence in us had eroded because we weren't responding to their new feature requests in the legacy system. Plus their management didn't want to take any risks since the new system offered to new features to them and only benefited us.
You would have had to work very carefully and have an extremely solid test framework and methodology but I'm wondering if it might not have allowed for adding the features the client wanted and prevented a situation where you had to do a major cutover on code that wasn't tested in the field.
Then they'd have the motivation to make the switch.
To implement a new system the client always needs to do UAT. That's actually a drain on their resources, and if they have a working system it is far better to have incremental changes made and a regular set if bug fixes than to launch a new system, then find a raft of new bugs or unexpected changes that need to be fixed anyway.
Existing systems allow enterprises to operate effectively. New systems almost always cause unexpected disruption to a business regardless of efficiencies gained from the new system. And most IT systems are to support the objectives if the business, they aren't the actual objective if the business. A software development company can lose sight of this because it IS the objective of their business :-)
Also, it was a hosted service and client saw no value to them- just the pain. There was risk of service outage during the upgrade that would have had resulted in the loss of revenue. Also, the client had to provision extra resources to run Cassandra/SOA servers. In short, it was a lot of work for them with no benefit to them.
That's the reason behind the success of continuous integration and deployment. At least bad code stay hidden for a very short time and needs to be fixed before other things can be built on top of it.