Changing a Strapi schema without losing data

Strapi's database config has a settings.forceMigration flag. It defaults to true, which lets the schema sync drop tables, columns, indexes and foreign keys that are no longer in your schemas. Set it to false and every drop is skipped.

In config/database.ts, add the block to the returned object:

return {
  connection: {
    client,
    ...connections[client],
    acquireConnectionTimeout: env.int('DATABASE_CONNECTION_TIMEOUT', 60000),
  },
  settings: {
    forceMigration: false,
  },
};

Restart, remove a field that has data behind it, and restart again. This time the column and its data are still there. Strapi has stopped reading and writing that column, but it hasn't touched it.

The default has gone from destroy to leave alone. Removing a field from the schema now takes it out of the API and the admin panel, and nothing else. The column stays until you drop it yourself, in a migration you write and review, on a schedule you choose. A rename behaves the same way: the old column keeps its data under the old name, and a migration moves it across.

Reach for this sparingly, because it's a blunt instrument. It blocks every drop, not just the risky one, so the database quietly keeps columns Strapi has forgotten about. And the skip is one-way: once a drop is skipped, the schema sync still records the new schema as its reference, so that column stays untracked even if you set the flag back to true later. Strapi won't clean it up for you. Treat forceMigration: false as a deliberate guard around a change you're nervous about, not a switch you leave on everywhere, and make the real change through a migration, which is targeted. The flag is documented under settings in the database configuration reference.

Turning off destructive sync tells the framework what not to do. It doesn't tell you how to make a schema change safely. For that the pattern is expand and contract, and Strapi's migration runner is what makes the backfill work.

Say you're moving price, stored as a decimal, to a priceCents integer, so floating-point rounding stops turning £15.00 into £14.999998 somewhere downstream. You don't rename the column in place and hope. You expand first: add the new field alongside the old one, backfill it, and let both live at once.

Add priceCents to the schema and keep price:

"priceCents": {
  "type": "integer",
  "pluginOptions": { "i18n": { "localized": true } }
},

With the new field declared, add the backfill. Strapi runs plain JavaScript migration files from database/migrations in filename order on startup, before it syncs the schema. That ordering is the whole trick: inside up, the database is still in its old shape, so the migration can read the old price column to populate the new price_cents one. It creates the column, backfills it, and Strapi records the run so it never happens twice. The database migrations reference documents the file naming, the ordering, and the fact that each migration runs inside its own transaction:

'use strict';

module.exports = {
  async up(knex) {
    const hasOld = await knex.schema.hasColumn('products', 'price');
    const hasNew = await knex.schema.hasColumn('products', 'price_cents');

    // Migrations run BEFORE the schema sync, so the new column does not
    // exist yet on first boot. Create it here, then backfill from the old one.
    if (hasOld && !hasNew) {
      await knex.schema.alterTable('products', (t) => {
        t.integer('price_cents');
      });
      await knex('products')
        .whereNotNull('price')
        .update({ price_cents: knex.raw('price * 100') });
    }
  },
};

Restart Strapi. The boot log shows the migration running before anything else touches the schema, and a query confirms the backfill. 1500 becomes 150000, with both columns live:

[internal migration]: migrating 2026.09.16T00.00.00.backfill-price-cents.js

strapi=# SELECT id, name, price, price_cents FROM products LIMIT 3;
 id |  name   | price | price_cents
----+---------+-------+-------------
  1 | Starter |  1500 |      150000
  2 | Pro     |  4900 |      490000
  3 | Team    |  9900 |      990000

One naming detail trips people up: Strapi stores the priceCents attribute as a price_cents column, converting camelCase to snake_case. Migrations work at the database level, so you use the column name, not the attribute name.

Expand is only the first half. With both columns live, old code keeps reading price while new code switches to priceCents. You deploy that, let it settle, and confirm nothing reads the old field any more. Only then, in a later release, do you contract: remove price from the schema and drop the column in a second migration.

The discipline exists because Strapi migrations only run forward. There's no automatic down step that puts the data back, so reverting is a manual job. That's not a gap to apologise for. It's the reason the safe path is expand-and-contract rather than rename-and-pray: every step rolls forward, each one is small enough to reason about, and at no point does a running instance read a column that no longer exists.

Strapi does not support down migrations. If you need to revert a migration, you have to do it manually. Down migrations are planned, but no timeline is currently available.