Clean into production is the wrong tool, every time
There is exactly one scenario where Clean against production is correct: you have decided to throw production data away. If that is not the plan, this article is for you.
Clean does one job, and it does it well: it brings a target into a known state by replacing its contents wholesale. Against a sandbox, that is a feature. Against production, the same operation becomes "delete all live data and replace it with whatever the source happens to hold right now".
Why this happens
Clean is irreversible inside DMM Infinity. The Runs page records that the operation succeeded — meaning the rows were deleted and the source rows were loaded as instructed. It does not record what was in the target before. There is no rollback button, no row-level undo, no warning step that asks "are you sure".
Worse, Clean has no way to tell you whether the source was correct. A staging environment that is six hours behind production looks identical to a current one until you load it. A network blip mid-source-read drops rows quietly. Either of those, combined with Clean against production, ends with a smaller dataset than you had this morning.
What to do instead
Use Merge. It updates matched rows, inserts new ones, and leaves target-only rows alone. In every realistic production-sync scenario, Merge gets you the same outcome as Clean would have if Clean had worked perfectly — without the failure mode where it does not.
If you genuinely need "production = source, byte for byte", do it in two stages: take a database-level backup of production first, then run Clean. The backup is your insurance against the source being wrong. This costs operational time, which is the point.
- ·Reach for Merge first when target=Production. It almost always answers the same question.
- ·Take a database-level backup outside DMM Infinity before any Clean against production.
- ·Use Clean against QA, staging, sandbox, or freshly-spun environments you fully control.
- ·Document any production Clean as a planned operation with a named owner and a rollback plan.
- ·Clean into production "just for this one entity" — there is no granular undo and the entity might reference others.
- ·Assume the source is complete. Clean replaces target-only rows with source-only rows; missing rows on the source means missing rows on the target.
- ·Use Clean to "tidy up" production. Tidy means deletes, deletes mean rollback, rollback means a backup you may not have.
A concrete example
A team scheduled a weekly "data refresh" Clean run from a staging snapshot into production, on the assumption that staging would always be at least as current as production. The snapshot was taken at 02:00. The run scheduled at 08:00.
In the six hours between snapshot and run, an automated batch in production created 2,200 invoice records. Clean deleted them at 08:00 along with everything else and reloaded the staging snapshot. The audit log showed a clean, successful run. Successful for the run, not for the data — those 2,200 invoices were reconstructed by hand from email confirmations over the following week.