Howdy 'Volters, Even though I'm already up to my eyeballs, I had a new alligator introduced to my pond the other day ... The Set-up: I have a large number of web-based reports that run off some data tables that get updated several times a day. The structure of the underlying data feeds will be changing so significantly that the current table structures can no longer be used on a 'go forward' basis. (Yep - "merger impact".) New reports will have to be developed based upon the new data feeds. What I need are some interesting ideas on how to keep those "old" reports 'live' and available to users who want to see the old historical information for some extended period of time. So far the ideas I've come up with seem to fall into three categories. Are there any other categories? Anybody run into this and have a better idea? Is there a 'conventional wisdom' that any of these approaches is 'the best'? Static: I could run each report (potentially multiple times) and dump the results to a static .csv or .xls file, place those on the server, and 'retire' the dynamic reports and database tables/schedules/etc. + Once completed this should be a very low maintenance proposition. - Users lose the 'dynamic' functional interaction presently offered by the report apps. - Users would be 'locked in' to whatever options I happen to chose when I generate those static snapshots. Dynamic: I could shut off the load schedules, move the tables to a new 'archive' db instance and point the current reports at it. + Low initial investment in time and effort. + Users retain full report functionality. - Could easily lead to 'down the road' maintenance issues through hardware upgrades, server upgrades, db upgrades, and even browser upgrades. - Licensing agreements may not allow 'perpetual use' of an old software version. Blended: I could create some new 'data-models', possibly in a 'cube' environment, populate them with the historical data, and turn the users loose in data 'mining' with whatever 'tool du jour' happens to come along. + Gives 'power users' full access to the information. + Probably low 'long run' maintenance effort. (Should be "future proof".) - May create a 'barrier to entry' for less skilled users. - Large initial investment in time and effort. Hmmm ... maybe there is a 'fourth' option where I try to engineer some method for loading the old data into the new structures ... it would not be easy. I know this isn't a 'what's wrong with my code' question -- but I think it's still 'on-topic'. Thanks, RonL.