Does something like this work for your application? http://www.howtogeek.com/50786/using-srvstart-to-run-any-application-as-a-windows-service/

If so, may be a good middle ground. Personally, I HATE applications that require you to log into a server and click an icon to start it up. What happens when the server reboots unexpectedly at night or after windows updates. Just makes end users think that the application is broken when in reality the IT person either forgot to manually start that one application or didn't know the server rebooted. Just cause headache's all around.

Having less maintenance is a good thing. Having it start on start-up is easy. Writing a new interface is hard.

Take the easy way out and have it start automatically.

I don't really get the problem, but a startup script launching the program would be the end of all troubles right?

Or did you mean to make a SQL database with a webpage front so you can easily export it to Linux?

Needs to run headless, as it requires two manual steps, logging in and launching it, every time the machine which hosts it is re-started. Why retain two points of failure? They've had no complaints about it because people there are accustomed to it being wrong, i.e. to having to have a person in the loop for it to operate properly.

A startup script is not the answer on a server, IMO. Having a server operating system that needs to automatically login, which btw has credentials not encrypted in the registry, is bad practice. Also having this particular app start as a service causes an issue when a second instance of it is opened up. Been there done that. The "front end" part of it is literally a text box showing output from the warehousing equipment and a few buttons to change quantities in the db.

Services are harder to create, debug and maintain. Services also have another annoying thing, the startup sequence of the services cannot be predicted easily. Your service might start up before your SQL server.

In my experience with software developing, there is no single good solution.You have multiple solutions and the only way to know what was best is to try both of them. Even though it is a service or a Windows executable, you basic core code could be exactly the same. When 90% of your code van be used both on a executable and service then it can also be used in a unit test.

Also interesting to know, an executable can also be a service. When it starts as a service then don't use UI functionality but when you double click the executable then you do show the UI.

Windows Services are not too difficult to write and maintain, but they can be a bit cumbersome to debug and troubleshoot. I like services for tasks like what you describe because they can be made very robust and resilient. The architecture of the service will greatly depend on what exactly you need this code to do. If it is simply connecting to the SQL database and running queries/stored procedures, then great you can write a simple service with a simple monitoring and control application for it. If you need access to network resources, to interact with the UI or to use more than one security context then it gets messy, but it doesn't sound like you need to do this. If you're a Visual Studio user you can make a single solution that has your service project, the service deployment project and your monitoring/control project together in a nice tidy package. There's even a handy dandy command line tool to register/unregister your service for painless testing and deployment. It's pretty easy once you understand how a service works in its various operational phases. Just be sure to write in some fail safe checks to make sure the SQL server is accessible and to wait for it if it's not. I would also out in some logging feature to give you feedback on how things are going when you're not watching the control/monitoring app. Keep everything as simple as you can with appropriate error handling and don't lose sight of the fact that a service is simply a timer driven app. There's plenty of resources for writing Windows Services in C# or VB.Net and it's a lot less daunting than people think.

Just put a shortcut in the startup folder

This is still a thing? Make it a service.

Also, is it hitting the db tables straight up?

Is this a leftover from 1999?

If it works don't fix it.

Two smaller, more focused programs with better separation of concerns is really supposed to be easier to maintain than one big confused one with an identity crisis.

Otoh, you know, things don't get fixed if they aren't perceived to be broken. Just be ready to say 'Well, I told you so', and have the simple solution ready to pitch when that server next power cycles and that thing doesn't run over the long weekend and there is great wailing and gnashing of teeth.

And design the next one properly in the meantime.