The business partners I work with have also been frustrated at lack of estimates, things constantly breaking, lack of flexibility / features that were available prior, etc. So far after many years the project has only been used on a small set of our products.
The problem I see is that writing new features on the new platform takes a LOT of work, because of mistakes in the abstraction. However all the new hires don't want to listen to the people who were here before, are often ignored, they work in silos and prevent other people from pushing code while they approve whatever they want within their inner circle, and the whole thing feels like a project where once it launches on a few more products they get to send their resume out and hop to the next level on the enterprise ladder at a different company.
I'm frustrated by the whole planters / gardeners shebacle going, the idea that people can just come in without taking the time to truly understand the problem in depth and look at past abstractions, and then when the work they do is incomplete or half-baked, they dump it to one of the other teams while they plow ahead with their next feature and get to say they met their goals.
They've also slowed down the rollout of the project, and some features have been scrapped altogether just to get the new platform out so that the company can stop supporting two platforms at the same time and invest in the new one only.
So what are some signs to tell if the project is going well or not? In public I always see a lot of congratulations and praise on small wins, but I'm not impressed. I've also heard the project has been under a lot of scrutiny because of the introduction of bugs, etc. Are there any tips / tracks to get a feel for the temperature of the project and wheth
If you have good test coverage prior to the rewrite the cost of rewrite will be substantially less because there exist many fewer unknown success and failure criteria. If a thorough plan and requirements strategy exist in writing before the rewrite starts the cost of rewrite will be substantially less because there is less exploration necessary. If you have a good type system in place, such as interfaces defined or a means to define them rapidly without a regression, the cost of rewrite will be less because the technical definitions are already defined.
A rewrite is going poorly when it costs more than plan. A rewrite is going well when it costs less than plan. A rewrite is phenomenal when it costs less than plan and eliminates future maintenance expenses.
I'm no expert, but I suspect this all sounds like a system that's fallen victim to the Second System Effect:
https://wiki.c2.com/?SecondSystemEffect
And is blundering through many of the same mistakes as the Netscape rewrite mentioned in that Joel on Software post.