Migrating to SaaS

Software-as-a-Service (SaaS) represents a dramatic paradigm shift in the way organizations develop, market, deliver and service software. It also transforms Independent Software Vendor (ISVs) into service providers that add value to the software. The migration to SaaS requires organizations to consolidate their existing single-tenant applications into a multi-tenant solution, which can prevent them from fully realizing all the benefits of SaaS.

Multi-tenancy provides customers with advantages like a low total cost of ownership (TCO), which is why major SaaS platforms such as Gmail, SalesForce, Workday and Yahoo have this architectural feature. Various multi-tenant models exist, with fully-shared and single-code models being the most common. The choice of models help ISVs find the best way to implement multi-tenancy SaaS for their customers.

Overview

The conversion of single-tenant applications to a multi-tenant model requires time, money and effort just like any project. It also requires expert knowledge and real-life experience in SaaS and system design. The overall cost of an SaaS migration project depends on factors such the solution’s size, complexity, customer base and database model. The consolidation of applications into a single source code also requires careful analysis before it can be migrated to a multi-tenant model.

Figure 1: SaaS Migration Methodology Flow Diagram

The figure above shows that the migration process involves multiple phases, each of which contains multiple steps. The phases include the following:

• Study
• Approach
• Design
• Develop
• Verify
• Deploy
• Migrate

The architecture of an existing single-tenant infrastructure must be redesigned to support multi-tenancy while still providing the required customization with minimal negative impact on the users. Altering the look and feel of an application can introduce a learning curve for existing users who are already accustomed to its current interface. This change therefore needs to provide a drastic improvement in user experience if it’s to receive wide acceptance from users. The best practice for this process is usually to release changes in a phased manner so that only part of the existing application is changed in each version. This approach allows developers to gather customer feedback on each feature change. Developers can then evaluate and incorporate these changes according to their priority.

Study

The study phase can have a great impact on the effort and cost of migrating to SaaS. It consists of the following steps:

• Goal identification
• Business feasibility
• Technical feasibility
• Code reusability
• Non-functional requirements (NFRs)
• Integration requirements
• Application security

The goals of the migration project include its overall result and expected benefits to the organization. These could include cost savings, better alignment with the market, addition of value-added services, improved user experience and greater web presence.

A study of the SaaS migration project’s business feasibility needs to assess its impact on customers. Many of these projects fail because they fail to implement the desired business model or meet regulatory compliance requirements, ultimately resulting in rejection by the end users.

A technical feasibility study determines if a multi-tenant model can provide the features of the existing solution. For example, an application that requires a rapid response time isn't a good candidate for SaaS migration.

Reusing existing code to the maximum extent possible is generally big best practice for SaaS migrations. Determining the percentage of code that developers can reuse is also vital for accurately estimating the time that the migration project will require.

Developers must also identify the NFRs that the applications must support. The table below provides some of the most common in NFRs that an SaaS solution must support.

Fig 2: Key NFRs for SaaS Solutions

Integration is a major portion of the process of migrating applications to an SaaS platform, since single-tenant applications can be customized for each tenant, while multi-tenant applications have a single source code. Developers must implement enough books for integration to allow users to connect with external applications and services.

Application security is particularly important in sectors such as finance and health, which are tightly regulated by PCI and HIPPA. These measures are generally intended to prevent unauthorized users from accessing information or conducting malicious act.

Approach

The approach phase develops a migration approach based on the information obtained during the study phase. It includes many of the key decisions for SaaS migration, so it should comprise a major portion of this process. Steps in the approach phase include the following:

• Development strategy
• Delivery model
• Cloud types
• Interdependencies
• Service provider
• Gap analysis
• Migration plan

The development strategy often involves a decision to use existing code or building a new solution from the ground up. These decisions largely focus on the existing solution's design.

SaaS typically uses a multi-tenancy delivery model, but this isn't always the case. Each project should be evaluated according to a number of critical factors such as the level of customization needed, application, and the degree of isolation required for those applications. Legal compliance requirements and customer preference can also affect the best delivery model to use.

The choice of cloud types for an SaaS migration project include a public, private, hybrid, and community cloud. The best choice will be based on the type of domain or vertical market that the applications primarily deal with. For example, a public cloud is usually the best choice for CRM and ERP applications while the private cloud is better for financial applications.

Choosing the service provider for the project is also a key decision since it influences the ongoing cost of the SaaS platform. Additional factors to consider include the ease of deployment and choice of development tools.

An analysis of the gaps in features and functionality between the current system and the proposed SaaS solution is essential in the approach phase. This step should include a review of the current architecture, including the separation of architectural layers and high-level designs. Some cases may also require an examination of the potential bottlenecks in the new solution.

The completion of the approach phase allows you to prepare a detailed migration plan, including strategy, schedule, limitations, communication procedures, data validation and management of unexpected problems.

Design

The design phase largely consists of consolidating multiple-instance applications to a single code-based SaaS solution. This phase consists of the following steps:

• Architecture
• Database isolation
• Technology stack
• Tools
• Framework
• Integration
• Security

Designing the SaaS architecture requires careful consideration of the interaction of the architectural layers with each other. For example, the interaction between the web layer and business layer is typically of critical importance, as is the communication between the business and data layers. In addition, the web layer shouldn't handle security for a service-oriented architecture (SOA).

A true multi-tenant architecture completely isolates the data between tenants, but greater data isolation generally increases an SaaS solution’s cost and architecture complexity. The specific method that it uses to isolate data is a primary consideration for the design phase. The migrated applications should be able to handle as many of the following data isolation models as possible:

• Separate databases per tenant
• Separate schemas per tenant
• Separate tables per tenant
• Shared databases, schemas and tables

An SaaS's technology stack primarily consists of the programming language that it uses. This stack should align with the existing application, allowing the organization to conserve existing expertise and resources for the migration. However, it may be better to use a different technology stack if the existing one is obsolete.

Using the right tools is essential for minimizing the time and cost of designing an SaaS migration. It's critical that the development team to avoid reinventing the wheel since these projects typically have tight constraints. Furthermore, teams that are inexperienced in designing this functionality will need to rework their solution multiple times before getting it right.

The goal of consolidating single-instance applications into a multi-tab one provides a single source that's easy to manage, maintain and scale. This application must be well-written and documented to accomplish this goal, requiring designers to use a number of best practices. The use of a proven framework is the best approach to designing such an application, especially for a team that's inexperienced in SaaS migrations. Frameworks allow designers to focus more on developing the business aspects of an SaaS solution and less on its technical aspects.

SaaS must be more flexible and scalable than a traditional single-tenant application. This capability requires developers to provide hooks for customization that allow an SaaS solution to better meet its users' needs. The solution must therefore be highly integrable, allowing users to connect to their applications via heterogeneous services.

A multi-tenant solution must include security in all of its architectural layers, including the application, database, file and network layers. This requirement is especially true for the application layer, which should subdivide security into its functional and data aspects. Functional security ensures that features and modules are accessible only by authorized users, while data security deals with the accessibility of database records. An SaaS application that's accessible with a web browser must also be secure from attack such as Cross Site Scripting (XSS) and SQL injections.

Development

The development phase of SaaS migration includes the following activities:

• Code scrubbing
• Code merging
• Code migration
• Architecture alignment
• Feature implementation
• Integration support
• Administration

SaaS migration usually consists of reusing existing code as much is possible. However, it may also require some code scrubbing, which is the process of removing code that isn't needed for the SaaS solution. Developers may also use this opportunity to improve the code in other ways while retaining its existing function.

The remaining code will need to be merged into a single source code for each application, assuming the SaaS applications will have multiple tenants. This step also includes business validation and hard coding configurations.

After merging the scrubbed code, developers will write the new code that will build multi-tenancy into the application. Multi-tenant applications must be completely parametrized rather than hard coded because they need to be as customizable as possible. The application must therefore rely on configuration and metadata to avoid modifying the existing code base more than necessary.

Architecture alignment is the process of selecting the architecture that best meets the user requirements for the SaaS solution. Each developer must use the same architecture, including elements such as business objectives and messaging patterns.

The SaaS applications have many features in addition to their core business functionality, including functional and non-functional components. These include business rules, configuration management, tenant management, workflow management and reporting.

Integration support is the process of modifying the applications that will be migrated so they may be easily integrated with existing applications, whether they're located on premises or a cloud platform. Assume for this example that an SaaS e-commerce application needs to maintain inventory with the user's application located in the organization’s own data center. The e-commerce application must be flexible enough to integrate with multiple inventory management applications.

Users need to perform administration features like licensing, management, security management and tenant management from a single dashboard. In particular, the dashboard must use the web interface rather than the backend or XML configurations.

Testing

The types of testing that an SaaS migration requires include the following:

• Functional
• Performance
• Administrative
• Integration
• Security
• Non-functional

Functional Tests

Functional tests include all the tests needed to confirm that the features of the SaaS applications meet user requirements. It also includes multiple test cases and data validation of the application's business functionalities with positive inputs that the tester can then replicate with negative data. In addition, functional tests includes user experience tests that ensure users can navigate through the application without unnecessary complexity. Error conditions must also be tested to ensure they display the correct message. Error messages should be clear and precise without providing information that's overly helpful to malicious actors, especially messages related to the server or business operations.

Performance testing goes beyond merely ensuring that an SaaS application meets the customers’ requirements. It also includes measurements of other factors such as the application's scalability, speed and stability. Performance testing focuses on the application's most heavily used functions since it's rarely practical to test the performance of every task that an application can perform. These tests should be performed under realistic conditions such as simulating thousands of customers from different locations using the same application at the same time.

Administrative testing verifies that the administrative functions of the SaaS platform work as intended. This testing is as important as the testing for business functionalities sends any defects in the administrative functions can prevent users from customizing and configuring their applications.

Integration testing evaluates the integration of two or more modules with each other, especially the integration of functional modules with nonfunctional modules. These modules must be tested individually before integration testing can be performed.

Security testing is particularly important for multi-tenant applications, which also includes accessibility and privacy features. This type of testing often includes user simulation that validates the roles and privileges that the user needs to access a particular functionality.

NFR testing validates non-functional features like availability, performance, reliability and scalability. This type of testing is usually more challenging than functional tests.

Deployment

The steps in the deployment phase of SaaS migration include identifying the deployment model, capacity planning and load balancing.

The deployment model can either be distributed or non-distributed, with distributed deployment being preferable for cloud-based SaaS solutions. The reason for this preference is that an SaaS platform must be able to scale up and out as needed, which generally requires distributed deployment. Isolating the most commonly used features from each other is an effective method of scaling SaaS applications.

Capacity planning is the process of calculating the load that an SaaS platform can handle at any given time. It can be performed with a variety of specific techniques such as predictive analysis and transaction cost analysis. Predictive analysis forecasts the utilization of resources in the future based on past utilization, while transaction cost analysis calculates costs based on user actions.

A distributed deployment model requires a network load balancer (NLB) to handle requests and responses across the network. All cloud providers provide some type of NLB, but the routing algorithm it uses needs to be appropriate for the application. The figure below describes the NLB for Windows Azure.

Fig. 3: Network Load Balancing

Migration

A multi-tenant application is driven by metadata, so its behavior depends on its configuration. The first step in the migration phase is therefore to capture the parameters for each application and consolidate them against each tenant for that application. The next step is migrate the data to the new platform while accommodating the required data level changes. The effort required for this step primarily depends on the size of the applications and the number of users they have.

It’s also necessary to develop a roadmap during the migration phase, which is a schedule for adding new features to the SaaS solution. Deploying the new solution to the production environment is the final step in the migration phase. The old solution can then be decommissioned at some point.