Transitioning/rewriting an old ASP VBScript site to SharePoint, suggestions? I know C# but no SP API dev yet

Question

Around 2008 I was doing contract work for a large manufacturing company. I had extremely limited resources to work with (no dedicated DB server, old IIS server that couldn't run asp.net, etc). One of the projects was an internal website written in ASP VBScript. Over the years they wanted more and more functionality tacked on. Now it is an internal website that helps them manage shop floor workers/machines. Each machine has a related status log (kind of like a blog but much more specific to each task at hand). There are also pages on the site that translate all of the information into things managers like to see (eg. a visual javascript based map made that shows machine status). A lot of the site is made in straight asynchronous Javascript. The backend is ASP/VBScript, simple XML files for the website's structure, and (sad to say) MS Access database files to store status log information (one file per machine with multiple tables in each file, as well as specific db files for things like holding a recent status record from all logs, or the visual map location). When adding a new machine to the site they copy/paste a mdb file and a xml file (modifying filenames/xml tags as needed). Certainly not ideal, but the code is solid and functions for hundreds of users daily.

The javascript side of the site communicates with the server through a single ASP based "web service" I designed (just an asp script that takes "commands" and passes back and forth data from database files on the server, formats it, and sends it to the client). So the good thing is that the old ASP site itself doesn't have a huge amount of function/logic to it, at least considering how complex the entire system has become over the years.

All that said, my client is looking to transition the site to be based in SharePoint (basically run on their big SharePoint company intranet website). I have a lot of experience with C# winforms programming over the years, but no specific Sharepoint programming and no ASP.NET programming of note.

I am looking for suggestions based on your experience with SharePoint/ASP.NET. What sub-tools/technologies in SP might be a good fit to write the site on? I have just started to skim what options I have. There looks to be many different sub-tools/technologies I can leverage in SP to transition/rewrite the website. I will assume they are running on the most recent version of SharePoint, but they could be one version behind. They have been using SP for many years now as their intranet site (multinational company), so I assume they have every add-on to SP available. I do know they have a big server farm setup for SP.

Goals: - I'd like to leverage the javascript front-end code because I could see it being mostly fine as-is considering it communicates with the server through my custom language. I'm assuming at this point I'd just need to translate my asp script to asp.net and design a new backend database structure. I'll have to figure out what to ask resource wise from their global IT department. - I'd like to translate the way data is handled of course. Probably leveraging an MS SQL server. At this point I don't know how and what SP offers related to database access. With a true database backend I could get rid of the xml website structure and simplify some of the frontend/backend. - They want the new site to be easily duplicatable/clonable for different departments. They also would want a web interface for adding/deleting/modifying "machines" in a given log system. As I don't yet know what SP is capable of, I am looking for those experience based suggestions here. I am not sure if I would want to push multiple departments into a single database structure or not. That adds data complexity, performance considerations, and whatever else to the equation. Maybe there is a way for SP to clone/edit/delete table structures programmatically? Can I simply run an asp.net website on the sharepoint server and have it somehow work through their company SP intranet site, or does it have to be a SP "webpart"? - Do you have any favorite Sharepoint development books? Going to pick up one or two. Kindle or physical, doesn't matter.

I'm probably going to take a week or two of design time to write up a quote. The site is currently around 80 ASP files, 15 javascript files, and a number of support files here and there. So pretty decent sized for a single developer.

I am not looking for really hard specifics here, just suggestions on Sharepoint/ASP.NET development that might be best practices or whatever given my description of the existing website. There seem to be 10 ways to do any one task these days with Microsoft tools. Probably my biggest difficulty moving forward will be working with their IT to secure resources on their servers to make it happen, haha.

Thanks!

Answer 1

I have a lot of experience with C# winforms

As long as you are working in the "Classic API", and not the SharePoint Online/SharePoint 2016 "Modern UI", then your forms experience applies. That said, SP best practices for development are to focus on customization through web parts, SharePoint 2013 (and later) apps, and client side development using web services. For very large farms, there will be a lot of push back on moving any custom compiled code to the servers.

so I assume they have every add-on to SP available.

Unlikely! While possible, the bigger the SharePoint farm, hopefully the cleaner it is.

So,

• Which version of SharePoint is being used: 2010, 2013, 2016?
• Do they have any plans to move to SharePoint Online / Office 365 in the future? (there are a lot more restrictions on custom development)
• Which edition is being used: Foundation, Standard, Enterprise?
• What are their policies and governance on SharePoint customization.

Goals: - I'd like to leverage the javascript front-end code because I could see it being mostly fine as-is considering it communicates with the server through my custom language.

Will you be able to keep the existing server that is hosting your "custom language"? If so, and if your existing pages are 100% JavaScript calling your back-end services, i.e., no server side VBScript need for the pages, then you could:

• Create a SharePoint content page that uses their SharePoint master page and add your HTML and JavaScript.
• Create a SharePoint and customize it using SharePoint Designer to add your HTML and JavaScript.
• Create a web part that uses compiled code. (Probably not allowed by your SharePoint admins, and will not migrate to SharePoint Online in the future.)
• Create a custom web part that uses just your HTML and JavaScript, and deploy it as a SharePoint Solution.
• Create a Content Editor Web Part that links to an HTML file stored in a library that contains your HTML and JavaScript.

Can I simply run an asp.net website on the sharepoint server and have it somehow work through their company SP intranet site, or does it have to be a SP "webpart"?

It's been done. SharePoint is just a web site running in IIS. You can add a Page Viewer Web Part and just set the URL to your ASP.NET project. You can host your ASPX pages in SharePoint libraries.

You can install the ASPX pages into the server's SharePoint directories. How important is it to maintain the SharePoint look and feel and any custom branding? And, what restrictions are there on adding files to the SharePoint servers. (Good governance usually says no, no and no.)

The big questions are:

• Do you need to maintain the SharePoint look to the project?
• How complex is your database? Just a few tables that could be moved to SharePoint lists, or complex multi-table joins?
• Do you need to support mobile users?
• Must you have a smooth transition to newer versions of SharePoint or SharePoint Online without rewrites?

Your best plan would be to find a local experienced SharePoint dev and buy a few consulting hours to show them your application and get some ideas.

Answer 2

There are a number of options available to you as you begin thinking about an app migration to SharePoint. Each has its advantages and tradeoffs. At the very least you'll need to completely re-envision (re-write) that ASP application to host it in SharePoint.

The direction you decide to pursue would ideally depend on a number of factors including the skill set of the development team, the existing code base, the requirements, the user base, and the appetite for upgrade or migration to the cloud.

I'd suggest finding an experienced SharePoint solutions architect, bring them in for a week or so, and work with them to come up with a technical approach that makes sense given your current state and desired end state. You'll want a solid, well-conceived architecture up front before you start this.