# Tracking and resolving a schema drift cause

**URL:** <https://meta.discourse.org/t/tracking-and-resolving-a-schema-drift-cause/290901>\
**Category:** Self-hosting\
**Created:** [January 8, 2024, 7:02pm UTC](https://meta.discourse.org/t/tracking-and-resolving-a-schema-drift-cause/290901 "2024-01-08T19:02:56Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![jrack](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jrack/32/326934_2.png) [@jrack](https://meta.discourse.org/u/jrack)\
**Post date:** [January 8, 2024, 7:02pm UTC](https://meta.discourse.org/t/tracking-and-resolving-a-schema-drift-cause/290901/1 "2024-01-08T19:02:56Z")

</div>

So trying to migrate a site by restoring a backup from an existing deploy. I am getting the restore fail because of the schema mismatch (source is newer than target).

Now reviewing the admin/plugins endpoint for both deploys they match for the ones listed, their status, and their version so scratching my head a bit. I also tried putting all Themes and Components back just in case and no change either. Both sites are at app 3.1.3 so that doesn’t seem to be the root cause in this case.

Guessing there was a plugin installed on the site then the instance was redeployed and the db preserved without this plugin installed, but that is just a guess. Is there a deterministic way given a an instance or database that I can figure out what contributed to the schema drift? And is there a way to “down rev” or is the only method to make the target site match or superset?

---

_[View the full topic](https://meta.discourse.org/t/tracking-and-resolving-a-schema-drift-cause/290901)._