The ascx is not that large at all thanks to the generic one-off methods. The business objects are simplistic and don't take up many lines (I am going to separate them though). I am definitely not starting over. It is not going to be difficult at all to move to a compiled and layered framework (if someone can convince me I must) since I have this wonderful content management system. All I'd have to do is modify 10 or so template aspx files, and have the CMS re-write all the 300+ site pages for me in a matter of minutes. So I may be up sh*t creek in your eyes but I have a huge a** paddle and a nuclear powered steam engine as a backup. This system is live (beta), and works well. Maintenance is extremely easy, as is deployment. Enterprise re-use is a non-issue since every object lives and dies only on the website, which is hosted. If we do ever want to port objects or data over to another corporate app, a simple web service would do the trick. >>a user control is for creating a UI interface, not Data Access I proved it can be used either way. The compiled and running application on the server is going to be the same in terms of the Intermediate Language that is created whether I include the code with an import statement from an assembly or through the non-pre-compiled code of a user control. In my situation the user control approach is doing fine, and no one has told me yet what performance gains I can expect by going to the pre-compiled structure... just that I should do it because everyone else does it.