How to switch from an on-premise to SaaS architecture

Companies large and small are moving to a software-as-a-service (SaaS) business and delivery model. The benefits of SaaS are clear to both companies that purchase software as well as companies that make software. Much of the enterprise software built over the last three decades uses an on-premise architecture, but companies like Salesforce, Microsoft, and Adobe have proven that it’s profitable to move to a SaaS business model.

The other key advantage of SaaS applications is that their architecture allows products to be iterated on quicker.

As you’ve grown your business globally, the software solutions deployed in each region have become increasingly fragmented. Each regional division has made customizations to meet customer requirements, which has slowed your rate of innovation and ability to deploy new features globally. To resolve core issues like functioning with no common infrastructure, having to rewrite the code and implement custom features for each region, and deployment taking a long time with the current system, we recommend moving all divisions to a common architecture that’s deployed on common infrastructure.

What are the challenges involved in consolidating multiple versions of platforms from different countries?

There’s the knowledge transfer that will take a good 2-6 weeks and a 1-2 week in-person discovery session is highly recommended to transfer as much knowledge as possible to the technical and UI/UX team.
If some of your technical documentation is written in a language other than English, you might have to translate the documentation.
We’ve worked with customers who have lost documentation or domain knowledge about how their existing software works, so there is some risk that some features may not be built simply because they are not properly documented, but you’ll run into this same problem if you decide to build the new platform in-house. To reduce this risk, we recommend that you go through the process of documenting every feature for each version of your existing platform in English so that the on-boarding team can hit the ground running.

Close to a decade of helping on-premise and licensed software companies through the transition to “Something as a Service” whether that be Software (SaaS), Infrastructure (IaaS), Platform (PaaS) or Analytics (AaaS) has given us quite a unique perspective on the different phases through which these firms transition. From our experience on the front line of many transitions, we’ve narrowed down the migration process to 9 broad steps.

1. Start by evaluating your environment-Make a comprehensive list of your on-premise applications and infrastructure. Any firm on the verge of launching into a SaaS migration must first take a hard, long look at their present product, and determine what out of the legacy product is not worth carrying forward. Is every bit of the current functionality still relevant and actually being used? Audit your existing infrastructure and take stock of current cost and resource levels. Evaluate each applications’ status. Will it require refactoring for a cloud environment or is it cloud-friendly? At times the effort needed to migrate is higher than the output value. Not every system is worth upgrading.

Map the relationships between applications. This analysis mapping allows you to identify systems that shouldn’t be moved without another and those that can be combined. Acting in accordance after identifying dependencies means minimal disruption to processes. The next step is to analyze the infrastructure used by these apps once you have identified the apps to move. This includes the amount of storage needed, analytics, data generated, networking and expected SLA (service level agreement). Consider the money spent on server management, hidden costs involved and physical servers. An in-depth analysis of the costs and infrastructure can assist you in identifying how to optimize the apps for better efficiency after migrating the apps.  

2. Select the cloud environment-The first decision you need to make is which type of cloud is suited for your applications. The public cloud is nearly equal to a common offsite server. It’s convenient to use, cost-effective as it is a pay-per-use model, run by a third party at a remote location, flexible and highly scalable and there’s also the geo-redundancy. The private cloud gives a single occupant solution to a company. It’s company-specific, comes with better control and reliability and can be customized. However, the company incurs maintenance cost, and it needs internal IT proficiency. The hybrid cloud is a mix of the two. It needs hypervisor and cloud software layers. It’s Ideal for dynamic workloads, and cloud bursting is possible.

3. Choose the right cloud provider -The next step is to define the architecture required for the migration after selecting the type of cloud. Define the constituents that you’ll need and make a list of the apps that you’ll migrate. Consider computing power, storage requirements, etc. Since the cloud and traditional apps do not port well into each other all the time, there are chances that even if they are ported, they may not give the best out of them. You must check if your hosting requires load balancers, outsourced cluster equivalents, or database replication to avoid difficulties in the future. Then select the cloud provider that will fulfill all your requirements. Consider all factors while choosing the provider. Don’t forget to consider quick customer service, the assured SLA, better feedback, etc.

4. Get your applications cloud ready-Modularising monolithic app architecture to make it easier to use with native cloud services is necessary for successful legacy migrations. When you move an application to the cloud from an on-premise data center, there are two ways you can migrate your application: a deep cloud integration or a shallow cloud integration.

During the migration process, you modify your application to take advantage of crucial cloud capabilities for a deep cloud integration. This could be nothing more advanced than dynamic load balancing and using autoscaling, or it could be as sophisticated as making use of serverless computing capabilities for parts of the app such as AWS Lambda. It might also necessitate making use of a cloud-specific data store such as DynamoDB or Amazon S3.

For a “lift-and-shift” or a shallow cloud integration, you move the on-premise application to the cloud and make limited, or no changes to the servers you instantiate in the cloud for running the application. You do not use cloud-unique services. To make it to run in the new environment, any application changes are just enough. It also goes by lift-and-shift as the app is lifted "intact" and shifted, or moved to the cloud.

5. Deployment-You have prepared almost everything by the time you reach this step, and you are ready for the migration process. When it comes to cloud migration, a common misconception is that it's a one time trip. However, the reality is that the process of migrating data infrastructure to the cloud should happen gradually. So that work isn't disrupted, a successful migration should feel as seamless as possible to the organization. The aim here is to make sure that everything is done step by step when planning a major data migration while minimizing downtime and disruption to users. So prepare yourself for a migration process which can take anywhere from several months to a year.

You must back up the existing servers and data before migration. Store your data safely and make sure that it can be easily retrieved. Then set up the cloud environment. Do the provisioning, connections, and testing of all the individual constituents separately.

6. Perform the necessary refactoring-Before you migrate them, you may want to do other work on your applications and services so they work as efficiently and effectively in the cloud as possible. For instance, you may want to refactor your application so that it works well with a variable no. of running instances to permit dynamic scaling. This can potentially save you money on cloud service costs. Also, you may want to refactor your app in order for your resource utilization to make better use of dynamic-cloud capabilities, rather than you statically allocating resources ahead of time. You can choose to dynamically de-allocate and allocate resources as needed instead. You can also more easily move individual services to the cloud to move to a more service-oriented architecture before the migration.

7. Migration of data-Migrate the present data to the cloud post-deployment. This process may require some changes to fit and will take time. Ensure that they are working appropriately after testing all the connections.

Starting with the services that have the fewest dependencies makes the most sense. Here, you’ll follow up with your outermost services, typically the ones closest to your customers after migrating your most internal services first. The likelihood of testing in a life environment opens up by gradually migrating users. Choose simpler applications that don’t deal with highly sensitive data, with a high chance of success to start. As you incrementally release, finding small problems in the application is better than finding big problems on launch.

The first core functionality an organization, from our experience, when making the move to the cloud is usually the analytics infrastructure. Since it is not the absolute core, yet a major component of an organization’s data infrastructure, it makes for a less risky and ideal migration target. Moreover, there are various data analysis teams in every organization, and it will be easier to start with a small and innovative group to lead the change. Find this group, and work with them on setting up a BI tool which will work with your cloud data warehouse.

8. Remove the on-premise database-Make use of a bi-directional syncing mechanism between your cloud and on-premise databases. Remove the on-premise database once you have moved all users of the data to the cloud. Let the consumers connect only to the on-premise version by using an on-premise database with one-way synchronization to a cloud-based database. Disable access to the on-premise version and allow cloud-based users access to the new database when you’re ready so the cloud-based version becomes the main database. Like the ones available from Microsoft Azure and Amazon Web Services, use a cloud data migration service. Don’t underestimate the complexity of data migration planning. Before you begin a cloud migration, not paying close attention to your data migration plan could cause migrations to fail to meet expectations, or fail altogether.

9. Switch over production-You switch over production from the legacy on-premise solution to the new cloud version based on the architecture and complexity of your application, and especially the architecture of your datastores and data. There are two common approaches. You can do it all at once. Move the entire application or service over to the cloud. Validate that it works there. Then switch traffic to the cloud stack from the on-premise stack. Or do it a little bit at a time. Test that things are still working after moving a few customers over, and then move a few more customers. Keep doing this until you’ve moved all your customers to the cloud-based application.

Attempting to migrate a licensed, on-premise product to a recurring revenue SaaS (XaaS) solution is probably the most laborious task a business can take up. The shift to a SaaS-based model for a product firm demands a crucial change in the company DNA. The advantages are massive, and the vendors that get in front of sea-changes in their sector will thrive. Vendors who are slow to the move to SaaS have seen their company growth and value decline. Forward-looking vendors are aggressively shifting to the SaaS model with encouraging results. But it is crucial to make corrections as necessary while monitoring the progression with appropriate metrics.