Generating migration SQL

Every change SchemaSync can make is expressed as SQL first. Generating the script is always available and always read-only — you can produce it, read it, and never run it.

-- Generated by SchemaSync Professional 1.4.2-- Source: orders_dev    Target: orders_prod-- 25 statements · reviewed by you before anything runs START TRANSACTION; ALTER TABLE `customers`  ADD COLUMN `loyalty_points` int unsigned NOT NULL DEFAULT 0  AFTER `email`; ALTER TABLE `orders`  MODIFY COLUMN `status` enum('draft','paid','shipped') NOT NULL; CREATE INDEX `idx_orders_placed_at` ON `orders` (`placed_at`); -- Dropped columns are commented out by default.-- ALTER TABLE `sessions` DROP COLUMN `legacy_token`; COMMIT;

How the script is ordered

Statement order is derived from object dependencies rather than from the order differences were found, so the script runs cleanly on the first attempt:

1. 1Drop foreign keys that would block the changes that follow.
2. 2Create new tables, then add and modify columns.
3. 3Create and rebuild indexes once their columns exist.
4. 4Recreate foreign keys and constraints.
5. 5Replace views, routines, triggers and events, which depend on tables being final.
6. 6Apply commented-out drops last, if you have enabled them.

Destructive statements

Anything that destroys data — dropping a column, dropping a table, narrowing a type — is written into the script commented out. Deleting data should be a decision you make explicitly, so uncommenting is a deliberate act.

Using the script elsewhere

Save the script and it becomes an ordinary artefact: commit it next to the change that needs it, attach it to a change request, or run it through your existing release pipeline. Nothing about it depends on SchemaSync being installed on the machine that runs it.