I'd like to say that every upgrade is as seamless as the upgrade from ColdFusion 7 to 8, where I didn't have to do anything (that I remember). But of course they don't always turn out that way. Back when Macromedia released ColdFusion MX, myself and a number of other developers had to do a fair amount of work to remove references to structure variables named "this". It turns out that they've added a "local" scope in ColdFusion 9 and wouldn't you know, about the time I stopped using "this", I started using "local" instead. ;)
Ryan McIlmoyl gave me the heads up on the issue on the DataFaucet list. About a day and a half later, I've just finished up the basic modifications for CF9. (There were 3.5-thousand references to "local" in the core code, plus another 500 or so in the Members onTap plugin, with plenty of false-positives.) I don't actually know if the onTap framework is still working on CF9 yet, because I haven't installed it to test with yet. If you give it a shot, let me know how it goes for you.
One thing I'm glad of though, is the way I designed the ontap.cfc. This is a component with some basic functionality that was created before onMissingMethod() was added to the language, otherwise it might have looked a bit different. But in essence, the lack of onMissingMethod() is why the ontap.cfc has generic getters and setters (or accessors and mutators for you lingophiles out there). These are two private methods name getProperty() and setProperty() and two public methods named getValue() and setValue() instead of having loads of individual functions named getBlahBlah() and setYaddaYadda(). What's cool about this arrangement is that in all my CFCs, nowhere to I directly reference the structure that holds property values, which was named (you guessed it), "variables.local". Well, nowhere except in about 3 private methods in ontap.cfc. And because all my other CFCs faithfully relied on getProperty() and setProperty() instead of simply referencing local.x or local.y, that means I only had to change "variables.local" in about 3 places. This saved me HUGE headache. If I'd gone the other way and used all hard-coded (or more to the point hand-coded) getters and setters, I'd have had easily another couple thousand references to replace and another day's work on this update for CF9. I love it when a plan comes together! :)
I was actually thinking about this the other day too, because I was looking at a small application someone else wrote (I won't mention any names), where they used all hand-coded getters and setters in their code and I was trying to figure out how to use it for configuration. After about an hour or two of looking through the code for documentation of one of the features I realized that said feature was never completed. There were just 23 references to it hanging out in the code, not doing anything at all (other than passing a useless variable around). All those 23 references were mostly hand-coded getters and setters, plus a couple of form fields and param tags. And I was thinking to myself, how nice it is to know that, for the most part, that sort of thing doesn't happen in my applications. Sure I make mistakes, everyone does, but the point here is, if I'm writing config for an app, there's not going to be 23-lines of code hanging around for a single config value, there's probably going to be about 3 or 5 and that means not only less maintenance, but less work up-front as well. :)
So new zip archives of the core framework and of the Members onTap plugin are up on RIAForge.