<p>After testing this on development/staging environments, I can confirm it is safe to run. When it originally ran, it likely failed due to exceeding the TTR.</p>
<p>Looking at the queue job, simplified it is checking if a revision exists in the entryversions table but isn't present as a draft in the new format. If the queue job does get interrupted it can be resumed and would just continue from the entryversion needing to be converted.</p>
<p>If you originally migrated from a Craft 2 site this table could be quite large and you may need to truncate it before queuing the job, given you probably don't need versions from more than a year or so and it will take a very long time when you start dealing with values like 30,000 drafts.</p>
<p>You will likely want to push the queue job with a higher TTR if you do have a lot of entry versions to convert. Likewise running this as a separate worker will avoid issues with causing issues with your site's front end if it's a longer running job.</p>

CC BY-SA 4.0
2022-07-01T08:06:53.300Z
2022-07-01T08:06:53.300Z
James White
<p>I have a fairly large Craft CMS 2 site was recently migrated to Craft CMS 3, because of the large amount of entry revisions, the migration that runs the ConvertEntryRevisions queue job did not complete so entry revisions/versions from Craft CMS 2 are missing, the database tables pre 3.2 are still there with this data.</p>
<p>Is it safe to re-run the <a href="https://github.com/craftcms/cms/blob/v3/src/queue/jobs/ConvertEntryRevisions.php" rel="nofollow noreferrer">ConvertEntryRevisions queue job</a> in a migration to kick off the job again to resave these into the newer format to restore them from Craft CMS 2? If the job gets interrupted, as it is more likely due to the time it will take for the amount of revisions present (several hours) despite setting a long ttl value, can it be retried without any issues if it did get marked as failed i.e. wouldn't cause any data corruption?</p>

<craft3><entries><entry-versions>
Is re-running the ConvertEntryRevisions queue job safe to run after migration to Craft CMS 3.7?
# Is re-running the ConvertEntryRevisions queue job safe to run after migration to Craft CMS 3.7?

(Asked by: username_0 on 2022-06-25)

I have a fairly large Craft CMS 2 site was recently migrated to Craft CMS 3, because of the large amount of entry revisions, the migration that runs the ConvertEntryRevisions queue job did not complete so entry revisions/versions from Craft CMS 2 are missing, the database tables pre 3.2 are still there with this data.

Is it safe to re-run the [ConvertEntryRevisions queue job](https://github.com/craftcms/cms/blob/v3/src/queue/jobs/ConvertEntryRevisions.php) in a migration to kick off the job again to resave these into the newer format to restore them from Craft CMS 2? If the job gets interrupted, as it is more likely due to the time it will take for the amount of revisions present (several hours) despite setting a long ttl value, can it be retried without any issues if it did get marked as failed i.e. wouldn't cause any data corruption?

**Tags:** craft3, entries, entry-versions

---

## 1 answers

### Answer by username_0 on 2022-07-01. Score: 1 | Accepted answer

After testing this on development/staging environments, I can confirm it is safe to run. When it originally ran, it likely failed due to exceeding the TTR.

Looking at the queue job, simplified it is checking if a revision exists in the entryversions table but isn't present as a draft in the new format. If the queue job does get interrupted it can be resumed and would just continue from the entryversion needing to be converted.

If you originally migrated from a Craft 2 site this table could be quite large and you may need to truncate it before queuing the job, given you probably don't need versions from more than a year or so and it will take a very long time when you start dealing with values like 30,000 drafts.

You will likely want to push the queue job with a higher TTR if you do have a lot of entry versions to convert. Likewise running this as a separate worker will avoid issues with causing issues with your site's front end if it's a longer running job.


---

