<G> that's the nature of the beast, unfortunately. That's why I've been stalling the past few weeks.
The upgrades _should_ be transparent (or almost) from the point of view of the templates, and any changes to your database will probably not affect anything.
You may have to add some additional fields for Links's new features though.
Given that, the way to upgrade is to put the upgrade into a separate directory, and have it generate output in a separate directory, but use the same database. That way, you can test out the new features, make sure it works, then just copy things over to your "public" area, and make the path changes to Links.pm and you are in business.
That's how I do it. Every site I run has a test site attached to it. They share the same database (I used to use different databases, but that soon got tiresome... I just write my Hits_track and Build_updates to the test database by changing the database at the top of the .def files), and use the Links and Categories tables from the main database. Works great. Once I get the changes done to the test area, I can integrate them to the public area quickly.
Links.pm and HTML_Templates.pm are site-specific, so changes have to made to each of the files individually. Also, my jump.cgi is site specific (I have it heavily modified). But every other file is _not_ and could be moved from one links set up to another without a problem.
I spent a lot of time developing template sets that use include files and put all the site specific information in the Links.pm, HTML_Templates, and a few "header".inc files. Even those are mostly configured from the HTML_Templates files (remember, an include file is parsed before it's included).
So, off hand, I'd say you'll have a lot more features, and some work to make them work the way you want, but probably not as much as an upgrade to Links 2.0 would be!