Hosted Vs. Cloud Vs. On-Premise Software Applications  

Many advanced technologies have widened the range of options you have, in terms of how you provide the software you need to run an effective business. Deciding and implementing a new software application, especially when the company is going through a digital transition, can always create confusion among the decision-makers because of the available options and technical terminologies. It is important to know which software solution your company actually needs to run its business. Here, we are going to discuss hosted, cloud, and on-premise software applications and what makes them different from each other.   

Hosted software solution 

Hosted software solutions are somewhat similar to on-premise software solutions. Here you purchase the software license from a vendor and rent all the network infrastructure and the hardware from a third-party provider, instead of purchasing it. You have full control and access to the software you purchase but the server is hosted by an outsider and customers can access the hosted services using a direct network connection like a VPN (Virtual Private Network). A hosted software solution always addresses a single holder, that is your business, and is ideal if you are dealing with strict security requirements, sensitive data, and particularly intricate software implementation: but you have to pay a premium for the privilege. However, if your infrastructure is bigger and difficult to manage, the best option is to go for hosted solutions because you can have control of your software and license while using the server running on a vendor.   


With a cloud software solution, you can have everything including the software, network, storage, etc. after paying a monthly amount to the cloud consulting service provider. It is comparatively simpler and more cost-effective than on-premise infrastructure. When it comes to the functionality of cloud software applications, it is easy to generate a mix of integrated functions, or maximize the number of users, thus enabling you to grow and widen your business overseas. Automated updates indicate that your software is up-to-date and highly functional. The main advantage of cloud services over hosted services is the affordability as well as the scalability of the solutions. While using cloud services, the costs associated with maintaining data centers and tools can extend to millions. As cloud vendors depend heavily on clients to maximize revenue, they need to pay more attention to ensuring the security and safety of their client information. This is one of the significant ways to make sure that the technology is free from outside threats/attacks.  


An on-premise solution is the conventional way of purchasing and using the software. You will receive a product that you pay for in advance and your software service provider will install and run it on your own server. Here you have complete ownership to handle your computer server or servers internally and finish all software backups and upgrades, without the involvement of a third-party provider. It is easy for users to remotely access on-premise software online. In an on-premise implementation, the entire responsibility of running software lies within the organization. The software will be installed on your server once it is purchased from the vendor. They seem to be more protected, first and foremost; they are in the house. Secondly, they are managed by the IT department of the organization. Some of the important benefits of an on-premise cloud solution are that you have full control over the safety, expandability, and configuration of your servers. However, the scalability option is restricted based on the size of your data center.   

On-premise v/s cloud v/s hosted  


In terms of cost, most on-premise software has a pre-existing license fee. In addition, the company will stay responsible and incur the expense of training, support, and updates. Anyhow, on-premise applications are assumed to be safer and valid, as it provides total ownership and control.  


  • Comparatively less long-term cost without any monthly expenses.   
  • Easy to control policies and stages related to security and data.  
  • Can be accessed even if there is no internet.  
  • Total control over any software change or update.  


  • The heavy advance expense for hardware and license.  
  • IT support is needed to perform any update.  
  • A team is necessary for system maintenance.  
  • Difficulty in scaling if more users are added.  


When it comes to smaller companies, the cloud is particularly helpful as it offers complete functionality at a small cost as there is no need for upfront investment. Additionally, cloud software is priced under a subscription package on a monthly or yearly basis and it covers training, assistance, and updates. The exact cloud service provider would give you improved robustness and swiftness. Therefore, with cloud computing, you get greater flexibility and time. 


  • Advance expense is lower.  
  • Less maintenance cost.  
  • Third-party providers offer a protected environment.  
  • Scaling is easy because users are added/removed.  
  • Easily accessible on all devices from anywhere anytime, but requires an internet connection.   


  • Least or no control over upgrades and changes.
  • Limited customization for company requirements.  
  • Reduced control over policies and procedures.   
  • Do not work without an internet connection.   


On the other hand, a hosted service is the best option for operating multiple properties using the services of your choice on a unified corporate server or a private cloud environment like Amazon web services or Azure. Here, the additional costs will be based on the level of support you need from the virtual private cloud hosting provider.  


  • No need to perform application maintenance tasks.  
  • Easily accessible from any device.  
  • All upgrades and updates are performed by the service provider.  


  • Requires an internet connection to access any apps.  
  • Applications run slow during peak times.  

Wrap up  

The disparities among the three – on-premise systems, cloud, and hosted are very clear. Anyhow, there are still chances for confusion to come up while comparing cloud and on-premise. The major difference lies between what you have to control yourself against what is managed for you.   

The Future Of InfoPath & SharePoint Forms

What’s The Future Of InfoPath?

Yes, Microsoft has decided to discontinue InfoPath which worked mostly on top of SharePoint and replaced it with a more cross-platform-ish alternative called PowerApps. However, Microsoft will keep supporting InfoPath till 2026, but there won’t be any updates to the core product such as feature additions. In this article, we are discussing the future and transitioning of Infopath into PowerApps and what is on hold for its users. 

What Is InfoPath Used For?

In SharePoint hosted environments, InfoPath is used as a form creation and data capturing tool which was capable of gathering data from multiple sources like XML, web services and databases.

For companies or institutions, it was an easy way to gather structured data from many sources. The basic premise of Microsoft launching this in 2000 was to enable users to create a variety of forms without actually coding it.

The form creators were provided with options to create business logic, rules and also validate the content in the forms. Without getting into too much detail, the whole process of creating the forms in InfoPath could be summarized into a few steps which are planning, adding templates and layout, adding data connections, business logic, adding access controls and then publishing it. 

What Will Replace InfoPath forms?

InfoPath is slowly transitioning into PowerApps, which is envisaged as a tool that helps create custom business apps on top of the existing Microsoft services like SharePoint, Azure, Office 365 and a lot more. It says in the PowerApps website, “We make it easy to get your data into your apps with more than 200 connectors for many popular cloud services and even your on-premises data”. With many templates and interfaces with a drag and drop approach, designers and/or developers could easily create screens or forms that can perform CRUD operations. 

When InfoPath had specific use cases among its users, what makes the PowerApps an obvious improvement is that it lets you create an entire business application in a very limited amount of time. One area in which Microsoft had a specific focus on is where it took the customization capabilities of Dynamics and brought it within PowerApps. What you need to understand is that whether it is InfoPath or PowerApps, both are meant to be used for internal use. There were built for a replacement for things, for instance, an internal onboarding application, task management, etc. Businesses internally can install a native PowerApp in their phone or PC and launch an internal application from it. Even though it has some business logic, it is not actually meant for much larger applications with lots of logic which typically .Net would support. 

Can PowerApps Replace InfoPath?

Along with all the benefits, there are also some disadvantages too. As far as the app performance is concerned, native apps are much faster as compared to this one. Some developers have even reported a difference in 3-5 seconds in app load time. If you need to run multiple apps at the same time, then PowerApps might not be the right fit for you, especially in mobile environments. However, on the web, you can run multiple apps in the same account. Another important drawback is that being an internally implementable app, the apps cannot be published to the app store or play store. None of these are huge issues and we are sure Microsoft will improve these with the latest updates. 

Migrating InfoPath forms to Power apps

Even though InfoPath is considered as a SharePoint first product, originally, it was not built to work with it. Later on, InfoPath was refitted to suit Sharepoint so that the forms could be easily used whereas PowerApps is an Azure first product. PowerApps require a constant internet connection and this is going to be extremely difficult especially for people who may not have an active internet connection like on-field workforce in industries like construction, delivery, etc. It doesn’t even cache the data offline and then sync it later when connectivity is available. Maybe they would introduce this later on, but it is highly unlikely since they have extended support for InfoPath only till 2026. So for now, it seems the only alternative is to continue using InfoPath and this presents a much bigger problem. 

Now that these older versions are being replaced to support Microsoft’s cloud-first approach, the organizations using InfoPath will need to start looking at alternatives that would suit their requirement. But it is extremely difficult. Why? Because the underlying technology of both these software does not function the same way and hence you need to rebuild most of these forms which are going to be a big bottleneck for most of the old users who have the InfoPath forms especially in local servers. When people move from on-premise SharePoint to SharePoint hosted in the cloud, existing InfoPath forms will just stop working. This worries many existing users and they are looking for solutions. 

Is there a better way to create SharePoint forms without InfoPath?

Knowing that InfoPath is going down the drain in a few years and PowerApps may never have InfoPath like features, it is up to the users to find alternatives. An option that the users can have a look at is ClaySys AppForms.

ClaySys AppForms is a metadata-driven low code development platform that can be used to build forms, workflows, and apps. You can create basic forms for migration from paper forms to electronic forms, to a complex line of business applications using AppForms.

It has all the features of InfoPath and can also be used in a local network. On top of that, the Forms created in AppForms can be connected to varied data sources like SharePoint lists/libraries, SQL Server, Oracle, Web Services, RESTFul Services, SQL Azure, Azure Storage amongst others.

Any functionality created in AppForms is future-proof, as all existing functionality continues to work in future versions of the product.

ClaySys AppForms Form Versioning

ClaySys AppForms Form Versioning, Archival and Restoring

Form History

  • Select the form the history of which to be viewed.
  • Click View History


  • The Form History List window will be opened displaying the form history; latest descending.

Form history archival and restoring

Select the “View History” option from the context menu of the form which History is to be viewed. The Form History List window will be opened displaying the form history; latest descending.


Archive is a process of keeping away the different versions of a form, so that more hard disk storage can be made available, or for some other purpose.
On clicking Archive, the “Archive Form Versions” window opens up.

The Number of versions to be archived can be entered. It should be always less than the  “Version count”.


The Archived versions of the form can be restored with the help of restore.
On clicking the Restore button, the “Restore Form Versions” window opens up. The version of the form to be restored can be done so by clicking the Restore button.


On clicking the Cancel button, the window closes.


Right click on a row and click View.

The View Forms window will be displayed.

This is the default view.

Clicking Rules will display the rules that have been created for the form.

Zoom in and out by scrolling through – and +.

Clicking Details will display the Form History Document window that displays form details like new items, updated items and deleted items.

If you want to roll back your form to the version being viewed, click Rollback button.
Click OK in the confirmation window.


Use Compare to compare 2 versions of your form.

  • Select the 2 forms to be compared.
  • Right click on any form and click Compare.
  • The View Forms window will be opened displaying the comparisons of the 2 forms selected.



This is the default view.


Clicking Rules will display the rules that have been created for the form.


Zoom in and out by scrolling through – and +.

Clicking Details will display the Form History Document window that displays form details like new items, updated items and deleted items.

If you want to roll back your form to the version being viewed, click Rollback button. Click OK in the confirmation window.

Select Vertical to view the forms vertically.


Introducing WSDL Integration Module in ClaySys AppForms

ClaySys AppForms Version 1.0

Introduction to WSDL ( Web Service Definition Language )

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specification for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

Types– a container for data type definitions using some type system (such as XSD).

Message– an abstract, typed definition of the data being communicated.

Operation– an abstract description of an action supported by the service.

Port Type–an abstract set of operations supported by one or more endpoints.

Binding– a concrete protocol and data format specification for a particular port type.

Port– a single endpoint defined as a combination of a binding and a network address.

Service– a collection of related endpoints.

Configuring the WSDL and Reading the available web methods

    1. The basic requirement will be that the ClaySys AppForms application should be able to access any external web service and allow the application to make calls to it.
    1. When a new WSDL is introduced to the application, the end user will be adding the URI of the WSDL to the application along with the Credentials if any.
    1. Once the URI and credentials are provided, the application will display all the web methods available from the WSDL.
    1. When the user selects one web method, the application will display the parameters that need to be passed to this web service and the return type of the web service.
    2. The WSDL Configuration steps are explained below

      Create a new DataSource

      Configure a DataSource Step1


      Select DataSource


      Display available Web Methods


      Display Parameters for the selected Web Method


      In case of a XML parameter the administrator will be able to define the XML parameter structure. If there is a XML file that contains the syntax of the parameter to the web method, it can be imported to the ClaySys AppForms application or the administrator can define the xml using the following screen. The screen will be opened when the administrator will click on the button named XML next to the parameter textbox.

      Define XML Syntax for the parameter

      Once the administrator user clicks on the button named “Load XML” it will allow the administrator to open an xml file, the second option is to define the XML manually.


      Define XML Syntax for the parameter


      After defining the XML syntax for the parameter, the administrator will be able to map the controls in the form, global variables or session variables to each node value or attribute of a node. This option will be available when the tab XML Tree is clicked.

      Map control value to Node or attribute

      Configuring the return type to a form

      The return type of a web service can be a single value or a XML.

      1. In case of a single value, the admin user can assign the return value to a Control in the form.
      2. In case of an xml, he will be able to pass the node values to more than one Control in the form.
      3. If the return type is XML, then the admin user will have to execute the web method once with a valid parameter, so that the application can get a sample XML which can be used for the configuration.
      4. Once the application gets a sample xml, the admin can map each node of the xml to any of the controls in the form. This can also be mapped to the datasource of a combo box or lookup etc.


      Test Invocation of the Web method to get a sample output which can be used for the configuration


      Output of the invocation (XML result)
      Column Mapping of the XML Nodes

      Dynamic Invocation of Web Methods
      The ClaySys AppForms rendering engine will be able to invoke the web method dynamically. There will be a proxy WFC which will be used by the ClaySys AppForms application. The ClaySys AppForms application will only make call to this WCF service which in turn will make the dynamic call to the third party WSDL files from the server.

      Each web service call details will be saved to a transaction table irrespective of the output. The details saved will be timestamp of the call, parameters, return value, etc.

      Failures and Timeouts
      Each WSDL call will be having a timeout period, which will be set to 5000 milliseconds (5 Seconds) by default. When the WSDL timeouts, the datasource will either send the error code to the client or read the values from the database (which can be configured when the datasource is details are saved). The status of the WSDL execution will be passed to the client.

      Exception Handling
      The WSDL configuration will allow user-friendly exception messages to be passed from server to the client. The exception, with the details like Timestamp, User Name, etc. will also be logged to an Exception table so that it can be checked in later stage.

      This module will be using the generic exception handling method that is supported in ClaySys AppForms application for logging the errors to the exception table and sending the user a user friendly error message.

      WSDL Execution Approaches

        1. Real-time execution
      1. Queuing

      Real-time execution
      In this approach the WSDL will be invoked at real time. There will be a proxy ClaySys AppForms service which will be used to invoke any WSDL from the server at real-time. The client will not make the WSDL call directly and will always be using the Proxy service.

      In this model, the ClaySys AppForms application will be using the default datasource to save the data to a SQL table. There will be a server side windows workflow service, which will be doing a data pooling to this table. Each time it finds a new record, the service will read the record and post it to the WSDL. The timeout, exception handling will be logged to the table which will be similar to the real-time execution.

      Attaching Procedure Call
      For each WSDL configured, there can be a procedure call at each successful execution. The procedure call can be another WSDL or a stored procedure which will consume the output of the existing WSDL to do some other activities like merging the records.