This is related to <mention class="mention" data-id="40749" data-type="work_package" data-text="#40749">#40749</mention>&nbsp;

### Steps to reproduce

1. Have a 13.4 Begin of the insertioninstanceEnd of the insertion Begin of the deletion instance End of the deletion
2. Be in work-based mode (Admin -&gt; Work packages -&gt; Settings -&gt; Calculate the work package % complete with == Use the work package field
3. Create a work package with work and remaining work being unset (which should be the default)
4. Migrate to (soon-to-be-released) 14.0
5. Go and see the work package activity thread

### What is the buggy behavior?

* There is an activity item by the System user because the total % complete has been changed from 0 to null, due to the way progress calculations now work: total work and total remaining work are unset, so total % complete is unset too.
* This is an invisible and uninteresting change which is not worth showing: no journal should be created for that

### What is the expected behavior?

1. No journal should be created for this one

One way to avoid creating journals for total % complete changed from 0% to unset is to unset it in previous journals before actually migrating the data. If it&#39;s unset, there will be no actual modifications after the progress migration calculations have run, and no journal will be created. It will be faster and leaner.

### Acceptance criteria

Field `derived_done_ratio` (the db field for total % complete) was introduced in `db/migrate/20240116165933_add_derived_done_ratio_to_work_packages.rb`.

Begin of the insertionIt shouldEnd of the insertion Begin of the deletion ShouldEnd of the deletion be Begin of the insertionresetEnd of the insertion Begin of the deletion setEnd of the deletion to Begin of the insertionNULL in work packages and their journals. This way, it&#39;s like the field had justEnd of the insertion Begin of the deletion NULL:

* all `work_package_journals.derived_done_ratio` where updated\_at &lt; 2024-01-16T16:59:33 (this is not very accurate as this migration could haveEnd of the deletion been Begin of the insertionintroducedEnd of the insertion Begin of the deletion run at a later date, but this is not knowable).
* could a better implementation be found?
* all `work_package_journals.derived_done_ratio` where `derived_estimated_hours`End of the deletion and Begin of the insertionthe value has been set by the migration. All previously computed values were incorrect anyway (old computation method)End of the insertion Begin of the deletion `derived_remaining_hours` is NULLEnd of the deletion