The ability to generate SQL scripts instead of actually executing the sql directly. The scripts are
generated in sequential order to ease of use and include labeling of the schema for multiple database
interdependencies.
Activation of production mode allows for only upgrades to take place and not allowing accidental
destruction of schema and data which might be caused by a downgrade.
Clean migration indicators to allow understanding of which delta migrations failed and whether or not to
prevent further migrations until human intervention has taken place in case of bad migration scripts.
Allows you to deliver migration source scripts in archived form of either .zip or .jar format. This
archive must contain a migrations.xml at the base of the archive and directories representative of the schemas
just like a normal directory layout. Thus making it easy to deliver migration scripts to other groups with fewer
complications.
Migrations also sports an API designed for use within testing frameworks like JUnit. It allows integration
testing to take place effectively and easily against a clean and well setup database similar to dbunit but with
the actual schema scripts thus not having problems with test/release schemas getting out of sync. In addition,
it does not require that the schema already have the basic DDL defined and thus can allow for things like Cruise
Control or Continuum to use a single database schema to handle multiple different projects each with their own
schema definitions.