There are no workarounds

There are no workarounds; there is only the system. Some parts of the system might be clunky, or redundant, or might appear suddenly in response to changing needs; but there are no workarounds. There’s only the system, and the current behaviour of the system, and some improvements you can make, and the direction you want it to take.

Labelling something a workaround is dangerous. Something labelled as a workaround, or otherwise tagged as an object of expediency might tend to be left alone. No-one wants to touch it, as it’s “going away soon”. It might even accrete new functionality.

Your system might be mostly workarounds.

Thinking of code as a workaround is wrong. It may have been a workaround once, at the time of creation – but now it’s part of the system. Its behaviour needs to be characterized in tests. Changes to it need to be controlled. You need to be looking at it; refactoring it when you touch it and spot a useful change; considering it’s place in the overall design.

All system code is in a state of change, moving from one expression of requirements to the next. Holding parts of it constant because you consider them a workaround makes no sense.

Telling yourself it’s a workaround is just stopping you from seeing the reality of your system. Give it up; it might stink, but it’s doing the job; if it stinks so much that it’s holding up the evolution of your system then fix it, bit by bit.