Those are some good points @Andy, and to expand on what he said:
i'm doing that very same thing right now. Because i have a rather comprehensive business layer, i have been able to do a lot of work (a couple of weeks worth), and in that time i have only had to add one function to that business layer. This is important because it reduces the amount of testing required. It also makes any remaining testing easier as it is easier to compare the output of the old version of the application with the new version.
One pattern that really helped to achieve this was the facade pattern. I built a WCF layer that sits over top of the business layer, and by using the facade pattern i can return results that are more suitable for the new silverlight interface, without interfering with the business layer.
It is most likely though that your new UI will have a drastically different architecture than the ASP.NET version. You will be able to achieve a far cleaner separation between UI, code and data. Some of the ASP.NET code that i was quite proud of looks positively mangy next to the equivalent silverlight code. Be prepared to chop your old code up, and eliminate those business rules from the immediate code behind :)