Yes. All software products that you purchase from us come with a one-year maintenance service, which includes complimentary support. The complimentary support allows you to raise up to three (3) support tickets.
Yes, we do offer paid support if the complimentary support is not suitable for you. The paid support is offered at the price of USD $180 per one support request/ticket, or $750 for an annual support contract which allows you to submit up to 5 support requests.
Yes, certainly. Our paid support is not limited to licensed users.
No, if the issue is deemed to be a defect of our software, it will not be considered as a support request.
KingswaySoft provides bug fixes to the latest official release version only, we do not generally create or provide fixes for any past release versions of our software. If you are using an older version of our software and come across a bug our team will ask you to first try the latest version of our software as it is likely something already addressed in a newer release. In some rare cases, we may provide bug fixes for the release version that is one version behind our current official release. This is generally assessed on a case-by-case basis, and it may require some special support agreement from the clients. All our software releases are generally accumulative, any bug fixes that were provided to our clients or partners in those interim temporary builds (if any) should be automatically inclucded in the next official release that is made available publicly.
The best way to reach support is to send an email to [email protected] with a detailed description of the issues or challenges that you have experienced. Any additional information that might help identify the problem would be appreciated, such as a screenshot of the error, the version of software that you are using, etc.
No, technical support is free for KingswaySoft partners.
In utilizing Microsoft's SSIS platform, our components interact with the source or target systems through the APIs or Web Services which they provide. Whenever applicable, our Connection Managers communicate with the underlying platform via HTTPS as long as it is supported by the service endpoint of the target system. In doing so, all of the network traffic should be encrypted using the highest TLS cryptographic protocol, which is TLS 1.3 (which falls back on TLS 1.2 if not available) as of today, whenever possible. It is important to note that our software is not the one that dictates the actual protocol level to be used. Security measures should be implemented and enforced on the server-side or service-side for the best protection.
In addition, our software is generally managed by our clients in their infrastructure. The software can be installed in a fully-isolated environment without network connections to any third-party servers (except the service endpoint that is required to read or write data using our components). Our software does not transfer any processed records or data to a third-party server, neither does it store the data somewhere else unless it is designed in the data flow or control flow tasks to do so.
When using our software to transmit data through the public network, we generally recommend setting up the service to use the highest security protocol on the server side. Since our software is independently installed, you have all the options to secure the network connection, such as using a VPN or a secure gateway, which is something that you can discuss with your infrastructure team.
We also encourage our clients to use those security mechanisms provided by the SSIS platform to save those sensitive connection properties such as a password or security token in order to provide maximum protection. Such mechanisms may include, but not limited to, the SSIS project or package's ProtectionLevel setting, secure environment parameters, Azure Key Vault (when SSIS-IR is used), etc.
You should make a full backup of your SSIS packages before you upgrade since our software could make silent metadata updates when you open the packages in our newer version of the software. The updated packages may not work with the older version of our software if you ever need to go back to the original version.
Our software is generally backward compatible, which means that if your packages were developed using older versions, they should work on the new version once it is opened and saved.
We generally recommend you perform some validations before promoting the software updates to a production environment.
We recommend you re-deploy the package to the server once your server installation is updated. You should only do so if the server has been updated to the new version.
We recommend you use the same version of our software between your development workstation and your deployed servers. If you have a newer version installed on your development workstation than on your servers, you could run into issues during runtime, or the new features that you rely on may not be available on the server.