These are illustrative scenarios showing how the products are used, not customer case studies.
The same sequence, twice
Today
- Change proposed
- Impact unknown
- Maintenance window booked
- Rollback is a backup restore
With SynaptaGrid
- Change drafted
- Impact analyzed against live
- Migration plan reviewed
- Publish; old version stays
The situation
The change itself is small — a field retyped, another made required. The risk is everything downstream: the integrations reading that field, the rows that will not convert, and a rollback plan that exists only as a database dump. So the change waits for a maintenance window, and the window gets scheduled around whoever is least available.
How it is approached
Each schema keeps one working draft alongside every version already published. The draft is analyzed against the live version before anything ships: which changes are breaking, which need data migrated, and which operations keep working untouched. A breaking change produces a migration plan with a column map to review first, and rows that fail to convert are set aside individually rather than stopping the run. Where a mechanical conversion will not do, the transformation is supplied and validated before it runs.
What changes
The scope of a change is known before it goes out rather than discovered afterwards. Superseded versions stay live until their data has moved, and archiving one is refused while rows still depend on it — so the rollback plan is a version that is still there, not a restore from backup.