We opted for something similar when facing a technology pivot point in our front-end application. Instead of opting to re-write our entire application that had been built over the course of 3 years, we chose to integrate the replacement technology side-by-side with the original. This enabled us to add new features using the new technology as needed, along with allowing us to move old features over as we were able to. So far, I'm pretty happy with it. But, at some point, we will have to actively prioritize re-writing old content using the new technology, or else we'll be stuck with this frankenstein forever.
Yeah. I'm really torn on this approach. I guess there aren't really any "good" options to redoing 3 years worth of stuff, so it's mostly an exercise in trying to pick the most acceptable bad trade-off.
The downside of this as I've experienced it is the tech-stack bifurcates and it becomes harder to ramp up new people. Or only some people get to work on the new shiny stuff and others just don't.
It's probably the best approach if you can guarantee the frankenstein won't persist forever. I've seen it get several frankensteins deep. At that point you're never getting rid of it, and the problem compounds. But there are no right/wrong answers, it's all completely context dependent and perhaps that's the only configuration in which the company can survive.
I also think there are likely certain inflection points in terms of project size/complexity. If the whole thing would only take 3 months to re-write then that's probably a good option. If it would take 3 years, it's probably not feasible. You know what I mean? The software itself is an input into the function of 'can we move this to a new techstack/architecture?' and I feel like there are certain parameters which have a safe operating envelope within which it's workable to do a re-write and not have the old solution hang around, but outside that the parameters may just simply not allow for it as a possibility.
