diff --git a/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migration-support-for-github-enterprise-importer.md b/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migration-support-for-github-enterprise-importer.md
index ddae9661ba5a..090d96519da2 100644
--- a/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migration-support-for-github-enterprise-importer.md
+++ b/content/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migration-support-for-github-enterprise-importer.md
@@ -178,5 +178,4 @@ There are limits to what {% data variables.product.prodname_importer_proper_name
 - **{% data variables.large_files.product_name_short %} objects not migrated**: The {% data variables.product.prodname_importer_secondary_name %} can migrate repositories that use {% data variables.large_files.product_name_short %}, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see "[AUTOTITLE](/repositories/creating-and-managing-repositories/duplicating-a-repository#mirroring-a-repository-that-contains-git-large-file-storage-objects)."
 - **Follow-up tasks required:** When migrating between {% data variables.product.prodname_dotcom %} products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see "[AUTOTITLE](/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/migrating-between-github-products-with-github-enterprise-importer#completing-follow-up-tasks)."
 - **Delayed code search functionality:** Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
-- **Scheduled workflows for {% data variables.product.prodname_actions %} are not enabled post-migration**: After a migration, scheduled workflows will not run. They can be re-activated by pushing a change to the repository. For more information about scheduled workflows, see "[AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#schedule)."
 - **Rulesets configured for your organization can cause migrations to fail**: For example, if you configured a rule that requires email addresses for commit authors to end with `@monalisa.cat`, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see "[AUTOTITLE](/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
\ No newline at end of file
diff --git a/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md b/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md
index 5c011dc22bb1..8be8ccd5ea10 100644
--- a/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md
+++ b/data/reusables/enterprise_backup_utilities/enterprise-backup-utils-encryption-keys.md
@@ -1 +1 @@
-After restoration of a backup created using {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.7.0 or 3.8.0{% elsif ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %}, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.1{% elsif ghes = 3.8 %}3.8.1{% elsif ghes = 3.9 %}3.9.1{% endif %}. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance#known-issue-users-cannot-sign-in-after-restoration-of-a-backup)." 
+After restoration of a backup created using {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.0{% elsif ghes = 3.8 %}3.7.0 or 3.8.0{% elsif ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %}, users may not be able to sign into the instance. To fix this issue, plus a bug that was preventing secret scanning encryption keys from being backed up, upgrade your backup host to use {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.7 %}3.7.1{% elsif ghes = 3.8 %}3.8.1{% elsif ghes = 3.9 %}3.9.1{% endif %} and generate a new full backup using `ghe-backup`. For more information on using an existing backup, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance#users-cannot-sign-in-after-restoration-of-a-backup)."