Your title suggests the business model is mismatched from the schema, but your current thought process is only focusing on tracking history.
The actual problem here is that the data schema is too closely aligned with the business model, that is, it only tracks and displays the current state of data. What you are really asking for is a level of abstraction that allows you to gather business insights over time to satisfy some new reporting requirements.
In an SQL database it is pretty easy to bolt-on audit and/or version tracking for any or all tables using triggers. Similar to the solution suggested by @Doc Brown however, I would use a generic schema for storing the changes and use dynamic logic to generate out the
AFTER INSERT|UPDATE|DELETE triggers.
The benefit to this is that the existing application should not be affected, making this backward compatible. You can then add improvements to the application to view the history for records or show the current row version timestamp if you want.
When dealing with existing applications, we really want to be careful of introducing breaking changes. Depending on the code or frameworks involved we can usually add new fields and tables and relationships without breaking the existing logic as long as we use reasonable default values or allow nulls. But not all code bases will support adding new fields to existing tables, so you need to have an understanding of what types of changes the existing application will tolerate before you go too far down the design path.
Adding in a transparent audit trace or version history through the use of triggers is a good start and solves your data issues before you start making changes to application logic.
Do we set a "cutoff" for the legacy model that was corrupted and wipe the table clean?
It is not clear if the legacy model is corrupted at all. It still contains the current data, the fact that there is no history cannot be helped but you can insert the first history record right now, effectively marking the data as valid from this point on.
If there are fundamental flaws in the current schema, and or the current application is not well aligned to the business process, then you may ultimately benefit from a new user interface and schema. When approaching a Version 2 of a product it is important to decide if you will attempt to import the historic data, or if you will simply cut over to the new application and start with a clean database. Implementing an audit trace now will mean that you have a good set of data when or if you need access it to migrate data to the new system. If you need to run the old and new system in parallel then you can implement Change Data Capture by adapting your version history solution to include flags to identify if the data has been synchronized with the new system.
- In the new system you would also setup Change Data Capture if you want to support pushing changes back to the legacy system.
You will need some sort of ETL process to physically migrate the data between the two systems, but doing it in this way gives you complete autonomy to rewrite the schema to match the current business process without affecting the current user process while you develop the solution and train the users to use the new one.