I’d fix data quality at the source when the issue is recurring, affects multiple downstream systems, or reflects incorrect data being captured in the first place. Adding another transformation may solve the immediate problem, but it can also create more maintenance and hide the underlying cause.

For example, if different systems record customer dates in inconsistent formats, standardizing them in a transformation pipeline can be a practical short-term fix. But if the source system repeatedly captures invalid dates, correcting the validation there prevents the same issue from spreading.

The decision also depends on ownership and control. Source-level fixes may take longer when multiple teams or vendors are involved, so transformations still have a role in handling legacy data, integrating different systems, and meeting specific reporting requirements.

I’d look at how frequently the issue occurs, how many downstream processes it affects, and the cost of maintaining the workaround. If the same rule keeps appearing across pipelines, that’s a strong signal to address it closer to the source.

How do you handle situations where fixing the source is clearly the better option, but the team responsible for it cannot prioritize the change?

My rule is to fix data at the source when the issue reflects incorrect business logic or broken data contracts, and use transformations when the change is intentional and specific to a downstream use case.

For example, if an upstream system repeatedly sends invalid customer IDs or inconsistent status codes, fixing it in every ETL pipeline just creates multiple points of failure. The same defect can surface in a new dashboard, model, or downstream consumer that doesn’t have that workaround.

However, transformations are still necessary for legitimate differences in representation, schema mapping, and analytical requirements. Not every inconsistency is a source-level defect.

If the source team cannot make changes, I’d isolate the correction in a shared, version-controlled transformation layer rather than duplicating patches across pipelines. I’d also add data quality tests, monitor exception rates, and document the workaround with a clear owner.

One important distinction: a transformation can make bad data usable, but it doesn’t necessarily make the underlying system reliable. The goal should be to prevent recurring defects wherever possible, while keeping unavoidable corrections explicit, testable, and observable.