# Migrating settings should take GlobalSettings into account

**URL:** <https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789>\
**Category:** Bug\
**Created:** [August 22, 2025, 4:27am UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789 "2025-08-22T04:27:21Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\
**Post date:** [August 22, 2025, 4:27am UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789/1 "2025-08-22T04:27:21Z")

</div>

I’ve seen a few settings migrations recently (the most recent being the removal of [automatic\_backups\_enabled](https://github.com/discourse/discourse/commit/f8bf51441e71166a3995c5b03d0075e4c9556191) ) where the migration uses database values only to calculate a new value. This ignores any settings made in `discourse.conf` via `app.yml`.

Code:

```plaintext
INSERT INTO site_settings (name, data_type, value, created_at, updated_at)
      SELECT 'backup_frequency', 3, NULL, 'NOW()', 'NOW()'
      WHERE EXISTS (
        SELECT 1
        FROM site_settings
        WHERE name = 'automatic_backups_enabled'
        AND VALUE = 'f'
        LIMIT 1
      )
      ON CONFLICT (name) DO UPDATE SET value = NULL, updated_at = 'NOW()';

```

which ignores `automatic_backups_enabled = false` in `discourse.conf` and as a result, does not keep backups disabled when that setting is present.

This specific ship has sailed, but it might be good to keep in mind that this pattern causes issues with settings that are overridden globally.

---

_[View the full topic](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789)._