The problem with database migrations are the rows, not the columns. I think I've written similar "column" tool like this for just about every DB project I've st

The problem with database migrations are the rows, not the columns. I think I've written similar "column" tool like this for just about every DB project I've started, or write one for projects I've inherited/stepped into... The rows (i.e. the actual data) is where the problem comes in. Just a few examples: * Splitting overloaded fields ("5qt" => 5, "qt") * Datatype changes ("ID" => ID) * PK size/type change (NUMBER(10) => NUMBER(15)) * "Just" add a column (PK,Col1 => PK, Col1, Col2)... easy until the identifying column is no longer enough! * Alter a PK (PK => PK1, PK2) - now cascade that through the Referential Integrity chain(s) * Change the "Type" column for every row based on the output of some external API call * "Rollback" part of the schema, with examples of the above applied * Implement a 'vertical split' on a very wide table, and associated RI cascades/updates * The infamous "was_migrated" flag, or "row_version" solutions that seemed like a good idea at the time * etc. And the next level of complexity comes with large-scale systems; doing these types of changes while the DB is online is even more complicated, and sometimes not possible or not worth the development effort. These are not intractable problems, and a tool to help with these kinds of issues would be quite valuable; that's what I was hoping to see here. [Edited; formatting]