Probably not for a few reasons:
You'd have to deploy the SSIS runtime for the package to run - this is not something that is usually done. You'd probably have to pay a licence cost
SSIS stores metadata (i.e. the type and number of columns in the source and target). If this metadata changes then the package will usually fail
SSIS is a server tool. It 's not really built for user feedback
Excel as a source is difficult for two reasons:
It has no validation. Users can put anything they want in it, including invalid or missing values
Excel drivers work out metadata by inspecting rows on the fly and this is sometimes incorrect (I'm sure you've already encountered this in your program)
A custom built solution requires more maintenance but has a lot more flexibility, and you probably need this flexibility given that you have excel sources.
If your excel files are guaranteed to be clean every time, and all of your users use a single SQL Server (with a single licensed install of SSIS) then it might be practical.
Added to reflect discussion below:
In this case you have consistent data files coming from elsewhere that need to be automatically uploaded into the database. SSIS can help in this case with the following proven pattern:
- User (or process) saves the file is saved to a specific shared folder
- A package, scheduled to run every (say) one minute in SQL Agent, imports all files in that folder
- If the import is successful, the file is moved to a 'successful' folder
- If the import is unsuccessful, the file is moved to a 'failed' folder
This way, a thick client app doesn't need to be deployed to everyone. Instead any user can drop the file (if they have share access), and it will be automatically pulled in
Users can also confirm that the file was successful by checking the folder
Here's an example of a package that imports all files in a folder and moves them when complete:
SSIS - How to loop through files in folder and get path+file names and finally execute stored Procedure with parameter as Path + Filename