We engineers love to isolate the “nice” from the “ugly,” the “new” from the “old.” We draw dotted lines, add adapters, and wrap legacy code in “temporary” abstractions — usually to make a future migration easier.
Unsurprisingly, years into your “migration”, other priorities still take the lead, and the simplification never quite actually comes. Those artificial, “temporary” boundaries are now part of your architecture, and make the code harder to follow. Newcomers struggle, bugs hide, features slow down. You end up maintaining both a legacy monolith and a patchwork of abstractions with no real benefit to show.
Either commit fully to the new architecture, or stay with the old one until you have a concrete plan to see the migration through. Halfway measures just create fragile glue code that add confusion and make your code harder to maintain and evolve.
Code is play-doh, constantly changing shapes. Stop pretending it’s Lego.