Updating Production data; Script checklist

Bugs are inevitable if you write code bugs will come; We can't ensure 100% bug-free software; that's why we have QA cycles and steps before deploying to production. The nastiest bugs are the ones that need data altering after fixing; For example, you have a point of sale system, and a wrong tax calculation happened and stored in your DB, then you need to update the data after fixing the bug. This tax bug might be a simple one, but imagine one with workflows, and the data object needs to go through different stages before it's done.
In this article, we will talk about a checklist that might help when such cases happen.
When you have such type of bugs, first of all, you need to assist it by answering the following question:

1. Is it blocking the customer?
2. Is it reproducible?
3. Is the fix determined?
4. Is the damage known?

Your primary focus should be unblocking the customer, even if that means you go and fix the data manually. Then you can reproduce the issue and stop it - this might happen before fixing it - the fix might be as simple as try-catch and log the error, now you should figure out the damage, work on a real fix and write a script to alter the data.

Script Checklist

• Ensure you know what you will change, get the affected data, and print some logs; Put the data and the results somewhere and preferably a file system, then email it.
• Make sure it is reversible; yes, your code effect must be reversible if something went south.
• Take a copy of the data, if possible, before altering it.
• Ensure that the code you wrote is working, get help from some reviewers, run it in a different environment if possible.
• Calculate the estimated time for your script, and this is crucial for all parties (Engineering, Support, and the customers )
• Have proper logs, for example( [ScriptName][PRE]I am changing the Product with ID 3, from value X, to value Y ), [ScriptName][POST][Success]Changing the Product with ID 3, from value X, to value Y ), [ScriptName][POST][Failure]Changing the Product with ID 3, from value X, to value Y, due to REASON and TRACE ).
• Have a progress indicator, such as [ScriptName][Progress] 10% 9/100 are done successfully, 1/100 failed Running for 3 minutes and 9 seconds ETA is 30 Minutes
• Have a kill switch. You might add a simple boolean in your DB and read it before each iteration. In software, nothing guaranteed
• Email the results once its done
• Make the code very flexible so you can run it only on a small set of data as a start
• Make sure the audit log is clean and clear. You don't want to confuse your customers with unfamiliar names on the audit log.
• Secure the script accessor. If you run it over HTTP or other, you must secure it, avoid hacking, and, most importantly, someone running it by mistake. Use an encoder for the endpoints and simple passwords such as "IKnowWhatIAmRunning,TheTaxUpdateScript", or add expiry date on the code.
• The script code is a code, make it reusable and leave it well documented.

At some point, you might need to make your script framework or just a nice Abstract Class and implement the logic of the script.

Conclusion
The software will have bugs, and hopefully, they are the friendly type. In case you needed something to alter the data, make sure it is reversible, keep it visible to everyone in terms of updates, and make sure it is secure and not easy to run.

I hope you don't ever need to do this, but if you do, I hope it helps.
What other points can we add to this list?