When you have a release candidate, you'll want to test any migration scripts that refactor existing tables, and therefore affect existing data, very thoroughly,  To run these tests, you'll need access to the current build of the release candidate, and to a development copy of the current production release, with data matching as closely as possible to what's in the real production database, so that you can check for potential data migration issues.

The test will need to apply the migration script to the current release, check that its metadata now matches that of the release candidate, and then check that all the data is preserved, after the schema refactoring.

With SQL Clone, these sort of tests are easier to set up, faster and more effective. You need two clones of the current release. You apply the migration script to one of the clones, leaving the other as a reference to check that the migration worked properly. Then, first, you compare the metadata of the resulting database with that of release candidate to make sure they are the same. Next, to ensure that the data is preserved after the schema refactoring, you run queries on each of the clones. The queries will be different (due to the refactoring) but they should still produce an identical result.

After testing the migration script, with SQL Clone it is very simple and fast to recreate a fresh clone, as part of the tear-down of the test after every test run.