This would be an ongoing slow-motion fireball of a disaster, in terms of usability, product coherence, and user trust in your company's capabilities and professionalism.
Not to put too fine a point on it.
Usability
Throughout the transition period, your users would have to cope with two competing layouts and two conflicting navigation structures. This would double their cognitive load in trying to keep track of where everything is, and would cause confusion about how the two halves correspond to one another.
(Looking at your before and after screenshots, it's totally unclear to me which links are intended to correspond to each other in each layout; this would be confusing even if you weren't planning to change the structure of the application along with the redesign.)
The problem will be exacerbated by the fact that things will keep moving around on them as you gradually transition from one framework to the next; it's unlikely you'd be able to document the current state of the system during the transition period, or that users would be able (or willing) to keep up with it even if you were.
change tolerance among our users is low
...so it's maybe not a great idea to subject them to months of ongoing, gradual but radical change.
Product Coherence
But it's even worse than that, because you're also planning to
redesign layout and navigation and not have to worry about backward compatibility.
...which means that the navigation structures will be in conflict; sections which are to be removed from the old design will be inaccessible from pages which have the new design, and vice-versa. The user will have to remember things like "ok, to get back to this old feature from this new page I have to click one of the nav links that I remember happens to point back to the old design, so I can get to the old navbar which links to the thing I actually want to get to. Oh, wait, I guess they updated that page now. How do I get back to the old design? Where am I?"
Or alternatively, you'll have to preserve and maintain the entire "old" application throughout the transition, just so you have a reliable fallback for the missing parts of the incomplete "new" application. This would be effectively the same as just redesigning the whole new product behind the scenes and cutting over on launch day, except much more difficult because you'll have to support both in public throughout the transition.
But you can't do that, either,
because of the extensive database redesign that's involved in this project... it would be impossible (or at least undesirable) to maintain both at the same time
Not worrying about backward compatibility is one thing -- you're proposing not worrying about current compatibility. Right now your users have a product they can use. While they wait for you to finish your redesign, they'll be stuck having to work with two halves of two different products.
Professionalism
We don't have time/resources to simply stop and redesign the app all at once
That may be true, but it's probably not a good idea to expose that fact to your users quite so blatantly.
Redesigning only part of your application clearly sends the message "we lack the capability to do this job properly, so please just bear with us while we muddle through."
No need to belabor this point further, I think.
So.... Instead of that...
It is probably not a great idea to redesign the product's appearance, and its functionality, and its navigation structure, while simultaneously transitioning from one front-end framework to another, as well as redesigning the database structure -- everything, in other words -- in public, with live data coming from both sides, while trying to keep everything in synch.
That's, like, a totally full Risk Factor Bingo card, even if you set aside the UX factors this answer is putatively about.
You need to separate these processes, for your own safety and sanity, as well as that of your users. Don't try to do everything at once; you'll fail.
If you need to change frameworks, I'd suggest completing that transition first, without considering any changes to functionality, layout, or structure. This will tend to make the code transition much quicker and smoother than if you're trying to make other changes at the same time.
(It'll also have the incidental benefit of letting your devs get a handle on how React works before they have to dig in on the "real" new design; they'll be doing their learning on the version you plan to throw away, instead of on the code you'll be living with long term.)
Some database structure changes probably go along with that by necessity, but keep these as minimal as possible.
Once you have a solid footing from a technological standpoint, then it's time to start thinking about redesign and structural changes.
Especially with a change-resistant audience, I like to do this in two separate stages:
- Cosmetic changes. If these are major, do them all at once. Rock that new look-and-feel, move the layout around like mad, but keep all the functionality and the navigation hierarchy exactly the same, so the user doesn't feel lost; it's the same product, it just looks prettier. This is what will be perceived by users as the real redesign, even though it's functionally identical to what was there before.
- Functional changes, incrementally. Restructure your site map as needed, change the functionality that needs changes, but do these gradually and incrementally. This is where the real change happens, but it generally won't be perceived by users as a "redesign" because it all looks the same -- bits and pieces of it just work better every time you do an update. Doing this incrementally means you have the opportunity to get user feedback as you go, and back out mistakes before you've committed too heavily to them. It also mitigates the change resistance on the part of the user, because you're not changing everything around on them, you're just improving bits and pieces.
