Moving from custom ASP.NET application to Sharepoint Services

Question

Our company has an ASP.NET application for customer information database. The application started small but has grown without proper design. Now a new version of the app sho

Answer 1

Kirk beat me to punch and said it better than I would have anyway :)

Another thing to consider is the possiblity of workflows in your process. For example, if you need to start a process when a new contact is added (a follow-up call, etc.), then SharePoint provides a great deal or benefit.

Perhaps a hybrid solution would be appropriate. A custom app for your CRUD and SharePoint integration for the pieces that make sense and provide value.

Building in SP for the sake of using SP probably isn't a good idea.

Answer 2

I agree with Greg in that I wouldn't necessarily recommend putting your data in SharePoint lists (this is what Greg may be assuming). But my short answer would be "maybe".

Here's the long answer...

SharePoint runs on ASP.NET so it should accommodate your needs. You would likely be writing ASP.NET web pages that live within SharePoint that access your database or writing web parts that live within SharePoint that access your database.

You could consider the BDC for reading/retrieving data, but that requires MOSS Enterprise and won't provide the CUD part of CRUD. Other tools like CorasWorks DIT may help, but I suspect that custom web parts or pages are the way to go for you.

There are plenty of benefits you can get from SharePoint such as authorization and maybe things like integration of your data with SharePoint list data, provisioning, search, etc. It really depends on the nature of your application as to whether SharePoint will provide much of a benefit.

Answer 3

Short answer: No.

Long answer: Is there any collaboration? Supporting documentation for the data? Workflow? If no, then there really isn't any reason to host it through SharePoint - you won't be gaining much.

Additionally, keep in mind that the SharePoint lists may look like tables, but they aren't - there is no relational aspects of the lists - no joining, no cascading updates/deletes, etc. This may be a problem if data reporting is a big part of your app.

You can store the data externally and have it appear as read-only lists in SharePoint, but you're still jumping through a lot of hoops if you're not using any of the other SharePoint features.

Answer 4

We have an ASP.NET application that runs in MOSS 2007. While we barely use any of SharePoint's features, we do get the advantage of SharePoint's security model, navigation webparts (we use CorasWorks), integrated Reporting Services, and workflows. In the very least, SharePoint features are there for us to use someday.

All of our application data is in its own SQL Server database. We don't store anything in the SharePoint content database.