Until now, our migration process consisted of:
1. Using an existing LSMB 1.2 to 1.5 or Sql-Ledger 2.8 or 3.0 database
2. Applying a specific migration script, with various fix
possibilities using specific forms
3. Obtaining a dataset that can be pushed into the latest LedgerSMB
schema or failing completely.
During the last week, Erik and I have been working on adding different
edit, update, insert, cancel and override possibilities for the
migration forms, in order to ease migration and try to prevent returning
the user to his old application to fix data.
Now, some of those fixing forms are specific to each migration but some
are more general and should probably fit better in a new sanitization
step, to be inserted between steps 2 and 3 above.
* benefit all previous versions
* prevent entering bad data in the database for which we do or not
have means to fix
* provide a diagnostic of the database to the owner. Such report could
also be generated on demand through the admin application.
* allow for more complex checks than was is strictly required by
This is a change from the actual process for which your input would be