My response would depend greatly on the system I was working on.
- Is it true that changes actually take longer in the new system, or is there an unfair comparison being made (eg "tweak a form input" vs "rework an API")?
- Is the new system inherently more complex than the old one in terms of business logic?
- Is the new system inherently better than the old system (as you hint by your UI/UX allusion), and it's just a case of "good things take time"?
- Have you, in fact, chosen an unnecessarily complex stack in which to build the new system?
This last point is worth considering as a possibility. Ordinarily you'd expect to make progress faster in a newer, smaller codebase you're building from scratch than you can when trying to change a large legacy system that someone else built. If you can't, and if the new system isn't inherently a larger effort, it may be that your tools are poorly chosen or are overkill for the task.
Eg, if the application would be just fine as a server-rendered site, but you've taken on the task of building the server side in one framework and the client side in another, you've added unnecessary work.
Or maybe you've chosen tools that are perfect for the task but which your team doesn't know well.
Web development has gained the potential to be more complicated; you can now build things on the web that you couldn't build 10 years ago. But you still can build sites like it's 1999, and in some cases, that (with a little bit of modern styling) would be good enough.
