Considerations for Purchasing a SaaS Product
Recently, a colleague in the team has been conducting an evaluation of migrating an on - premise product to SaaS. He has organized some evaluation content, which I think is quite good. Based on his work and my own experience, I have made some additions and deletions, and am writing this note here. The content here is also applicable as a checklist for purchasing a new SaaS service.
It is mainly divided into the following aspects: service availability, feature comparison between SaaS and on - premise deployment, performance, security, operation and maintenance, data migration, and integration with other company applications.
Service Availability
Service availability is divided into two sub - aspects: SLA and service support.
SLA
SLA refers to the proportion of time that a service can be used normally in a year. Generally, the SLA of commercial SaaS products is between 99.5% and 99.9%.
When considering this indicator, two factors need to be taken into account. First, the needs of other teams within the company that use this product. We need to communicate with them about this aspect. Second, if the company’s externally - provided commercial products also rely on this product, we need to pay extra attention. Because the downtime of this SaaS product may also lead to the unavailability of our own commercial products, thus affecting our SLA to customers. Failing to meet the SLA may result in financial compensation.
Service Support
Service support refers to how we can obtain support from the support team of the other company when we encounter problems.
Generally, there are the following ways to get their support:
- Submit a case on the dedicated support page
- Special communication software, such as WeCom, DingTalk, Slack, etc.
- Phone
- Video conference
The convenience of different methods varies. When evaluating this point, in addition to paying attention to which types of support the other party will provide, two other points should also be noted. First: response time, which is very important in case of downtime and other major incidents. Second: whether different response methods are charged separately. Some companies (especially foreign companies) charge separately for real - time response, so this should be noted.
Feature Comparison
Sometimes, there are differences in some features between the SaaS version and the self - deployed version of the same product. Whether purchasing a new one or migrating from on - premise, these differences need to be noted. It is best to talk to both the SaaS pre - sales and the self - deployment pre - sales of the other party. Sometimes, you may get different information.
Performance
The performance I want to talk about here mainly refers to network performance.
According to the distribution of the company’s office locations, there are two situations: having only one office location and having office locations in multiple cities across the country or even globally.
Only One Office Location
In this case, whether the company builds its own data center or uses public cloud for self - deployment, the service is relatively close to the users, and it is also close to other company applications (if it is a local data center, it may be in the same data center). So generally, there are not many problems with network performance.
However, if purchasing a SaaS service, the network performance needs to be specifically tested, and both ordinary users and systems with integration relationships should be tested simultaneously.
Because, considering the investment, SaaS companies are unlikely to deploy servers in every city across the country (or globally). So the location where you use the service may be far from the location of the SaaS server, which will inevitably affect network performance.
Multiple Office Locations
If the company has multiple office locations, the situation becomes more complicated.
In addition to the considerations for the case of only one office location, the following situations generally need to be considered:
CDN
If there are more than three office locations and they are far apart, it may be necessary to consider supporting CDN. Otherwise, no matter how the location of the server is selected, it is difficult to balance the performance requirements of each office location.Data transfer between different locations
It is better to support mesh - like data transfer rather than star - like. Mesh - like means that data can be directly transferred between any two points, while star - like means that all communication can only be done through the server for message forwarding.
However, this is also determined according to actual needs. Not all scenarios require this function.
Security
Security is divided into data security and network security.
Data Security
Some laws and regulations impose restrictions on certain industries, such as not being allowed to host data. Therefore, when purchasing a SaaS service, it is best to communicate well with the company’s legal team and keep evidence of the communication for future audit needs.
Even in the absence of legal restrictions, it is necessary to thoroughly understand the part about data security in the purchase contract and carefully study and verify it with the legal team.
Network Security
In the case of self - deployment, the service is likely to be accessible only within the intranet, but SaaS products are often published to the Internet, which brings potential network security risks.
It is recommended to consider the following points:
- Whether there is a WAF. This is crucial for services exposed to the public network.
- Whether 2FA, that is, two - factor authentication, is supported.
- Whether there is a detailed access audit function (who did what, where, and when, and whether it was successful).
- Evaluate jointly with the company’s security team (on the one hand, with their professional capabilities, a more comprehensive evaluation can be carried out; on the other hand, having another team to back you up).
In addition to data security and network security, another point of concern is a complete audit function, especially in listed companies or multinational companies. Special attention should be paid to this because there may be legal requirements.
Operation and Maintenance Management
Ideally, a SaaS product should require zero operation and maintenance. However, the current situation is that this cannot be achieved. Generally, two aspects of operation and maintenance work still need to be paid attention to: status change notification and monitoring.
Status Change Notification
Status change notification means notifying users in an effective way in advance when the service status changes, such as during upgrades, maintenance, or failures.
Most current SaaS products only support sending notifications to administrators and cannot send them to end - users of the product. It requires administrators (usually us) to forward them. It is best to automate this part. Because relying on a few administrators to manually forward notifications, if a notification is missed at an important node, it may lead to serious consequences.
Monitoring
Any system that provides services externally should have a supporting monitoring system. Otherwise, those responsible for maintenance will always be on tenterhooks, not knowing when a “bomb” will drop.
Some SaaS products provide customers with a complete monitoring and alerting system, and even provide APIs that can be further developed, which is relatively ideal.
However, some SaaS products do not provide a monitoring system for customers. If you still need to purchase this product in this case, it is best to do some black - box monitoring for important functions or scenarios. Otherwise, you will really be in the dark and know nothing.
Data Migration
In the case of migrating from a self - deployed service to the SaaS side, data migration must be considered. If the company’s information security policy and legal affairs permit, it is best to conduct an actual data migration before purchasing (for example, during the POC). “Salespeople’s words can be deceiving.” Don’t blindly trust what salespeople and pre - sales say. If there are real problems, we will be the ones who suffer.
Integration with Other Company Applications
When considering the integration of a SaaS product with other company applications, two aspects should be considered: functionality and network reachability.
Functionality Availability
This is the same problem mentioned above. The self - deployed version and the SaaS version of the same product may not have exactly the same functions. So it is necessary to actually conduct an integration to know whether it really works. Don’t blindly trust the documents provided by the other party. At least from my current experience, it is normal for documents to have errors and omissions, even if the other party is a top - notch company in the industry.
Network Reachability
SaaS products are often published to the public network, while many company applications are only published to the intranet. So when communicating, there may be network problems: network unavailability or sub - standard network performance. This can only be known through actual testing.
In general, when purchasing a SaaS product, testing is very important. It is necessary to communicate with as many stakeholders as possible and explore more test scenarios, so as to avoid as many pitfalls as possible.