How to migrate a traditional app to SaaS: Yalantis approach

In 2011, Adobe announced Creative Cloud, a SaaS application to replace the Adobe Creative Suite. In 2013, the company launched Adobe Creative Cloud with monthly and annual subscriptions for different toolsets. At first, this shift was followed by users’ displeasure, petitions, and a 35 percent drop in income. But this disastrous scenario at first glance turned out to be a success a bit later. In 2014, Adobe Creative Cloud saw a 44 percent increase in revenue, with over 700,000 new subscribers. This figure represented 30 percent of the total number of subscribers at the time. 

The further it went, the better it got. In 2017, Statista predicted almost 20 million Adobe Creative Cloud subscribers by 2024. Breaking that forecast, the service reached more than 22 million subscribers in 2020. 

In 2021, Adobe’s financial report for the third quarter of the year stated that Creative Cloud revenue had increased 21 percent compared to the same period the previous year. In terms of money, this amounted to $2.37 billion in revenue. That’s a great example of a successful SaaS cloud migration. 
 
Some other previously strictly dedicated software products are now available online for a monthly subscription. Look at Microsoft’s Office 365 and Kronos. A number of other popular services chose a SaaS model right from the beginning, such as GoSchedule, Twilio, and Shopify. The reasons are clear. We discussed them in our article on SaaS app development. 

Although the Adobe scenario is pretty inspiring, moving from on-premise to SaaS isn’t that sweet. It often entails a lot of technological challenges. That’s why it’s crucial to address an experienced software engineering company that provides SaaS software migration services. In this article, we outline how Yalantis deals with migration to a SaaS business model, describing our experience and sharing valuable tips and recommendations on how to migrate to SaaS properly. 

Moving to SaaS leads to drastic changes to a product as well as to a company’s mindset and strategy. If you aren’t sure about your readiness for a full-fledged shift, try to answer the questions presented below. If you answer yes to all of them, it’s the right time to think about changing your company’s current direction:  

Would your customers benefit from a SaaS solution? 

Considering the advantages that end users will get from a SaaS application, we doubt you will have dissatisfied customers. However, it still might happen. You can explain to your customers what benefits they will get from a SaaS solution with the help of our article on SaaS application development. These benefits include lower costs, better support, feature set flexibility, interface customization, and availability on multiple devices. 

We always recommend our clients collect feedback from their customers regarding possible changes. Their concerns can offer valuable insights during the migration process. 

Will your product meet the needs of a new audience and win the SaaS race?

You should be confident about new audiences recognizing your product as the most appealing option. If your company offers unique services, you hardly need to worry. If it doesn’t, you will have to compete with other providers after joining the SaaS market. With a traditional software provision model, your customers fully pay for your product up front, so they’re likely to continue using it after making the purchase. With SaaS solutions, you have to present your audience with continuous value so they will continue to choose you over other vendors.

Are you ready for strict business and financial plans for scaling your solution?

The ability to scale fast and easy is a double-edged sword. Besides pleasing customers with regular improvements, it also requires continuous work on updates and financial investments. Top management should think about this ahead of time and precisely plan the product development. Don’t cross the SaaS border until you think through the necessary upfront work that we’ll discuss further.  

Are you ready to change the way your teams work?

Migration to SaaS requires skilled specialists with rich expertise to work with IT infrastructure and environments. Ideally, they will be responsible for ensuring high-level data protection, automating deployment and monitoring, and maintaining high availability. These requirements may be met by training the client’s staff or exchanging experience. Yalantis has had cases when our specialists conducted workshops for customer development teams.

Are you ready for the challenging migration process? 

Migrating to a SaaS business model requires significant time and financial investments, a meticulously designed SaaS migration strategy, and a lot of skilled specialists who will be able to face and solve non-evident obstacles on the way. Sometimes, this process is complicated by the architecture of the existing application, which may be unsuitable for SaaS. Since this architecture is the basis of the future SaaS application, specialists may spend a lot of time dealing with its flaws to achieve an efficient design.   
 
However, no matter how tough the migration may seem now, in the end, it will be worth your investments. A SaaS application, besides recovering its costs in the future, will open a range of technological, business, and financial possibilities. The SaaS model will:

• facilitate development of new functionality due to an upgraded architecture design 
• attract new customers thanks to the numerous benefits of SaaS products, such as lower costs, 24/7 support, feature set flexibility, and so on
• increase your revenue thanks to a new monetization model
• smooth the way for your future business expansion 

Want to know how our clients are benefiting from the SaaS model? Explore how we built a SaaS device management platform for the IoT industry.

Let’s proceed with a detailed examination of the migration process. 

We will carefully guide you through each step of this challenging process, giving some recommendations on planning and redesign like we did in our previous article about development of SaaS solutions. Let’s explore the migration journey through a stage by stage scheme:  

Stage 1: Roadmapping

The roadmapping stage is critical, as it helps the development team and the client see and estimate the amount of work to be done. With a proper migration roadmap, this process will be painless and сost-effective. In general, roadmapping covers: 

• evaluating the existing product, its functional and non-functional aspects, and the client’s business goals 
• analyzing the client’s industry and demand for SaaS solutions among interested audiences
• reconsidering and modifying the product
• migrating data and the updated application to the cloud 

In comparison to the roadmapping stage for SaaS application development, migration consists of a lot more aspects to contemplate, discuss, and plan.  

Research and analysis 

This stage comprises the following steps: 

• Analysis of the existing platform

Business analysts, delivery managers, application architects, and lead developers investigate:

• how the existing platform works: what business goals the client has set and how the solution meets them 
• how it was built: the type of architecture, its condition, integrations, and third-party dependencies 
• how it was written: frameworks, languages, and security measures 

Alongside this, business analysts conduct in-depth research on the industry: how it works, what it requires (compliance with laws, regulations, and standards), and end users’ needs. An important step here is analyzing the database design. Since SaaS products use cloud databases, it’s crucial to decide how to transform current databases if they don’t suit the SaaS model.  

• Communication with the product owner 

This stage involves presenting solutions to the client’s business goals and explaining them. Our team presents customers with estimates on the migration process and benefits they will get with a new business model. Usually, this process covers detailed explanations from various aspects: time frames, costs, development paths, and product expectations. It’s necessary to show what the client can expect in five to ten years. Thus, the team can consider post-MVP versions in the event of a long-term partnership and lay the groundwork for them.

Clients also have to decide on the development path for an existing application. They usually have two options:

Option 1: Stop developing the existing product and concentrate solely on migration. This option is more suitable financially; however, it may result in the client’s customers working with an outdated tech solution for some time. 

Option 2: Develop both applications concurrently. This option requires substantial financial and human resources. In this case, we would need two development teams. The first would support the existing application, and the second would deal strictly with migration to SaaS.  

The choice depends on the client’s capabilities and priorities. 

• Presenting the prototype 

After discussions, business analysts and UX designers start creating a functional product prototype. To create a brand-new product design, they take into account functionality of the existing application and enhancements approved by the client. They usually use fictitious user data to demonstrate the product at its best. 

After approving the prototype, it’s time to plan the whole work process. 

Strategic planning

It’s rarely possible to follow an ideal plan of action when we’re talking about migration. Project and delivery managers have to precisely define time and budget limits for each stage of migration. Sometimes, it requires a lot of time and labor to remove bugs from an existing application. To make this process painless for all stakeholders, the Yalantis team prefers to gradually restructure business processes and change the architecture. 

As soon as delivery and project managers set deadlines for each step, they start breaking the process into workstreams and allocate tasks among the development team. They pay extra attention to accurate scheduling, as it’s necessary to decide in what sequence to replace particular components so they don’t affect the work of other components, such as third-party dependencies. All of these aspects can affect customers’ work routines. 

At the strategic planning stage, the team also has to consider the specifics of the product’s design, operations, and business flows. For example, if application architects have to redesign a monolithic architecture into a microservice architecture, they can face a number of problems associated with rebuilding a data model and downtime of the existing service during migration. The team must find ways to minimize all losses and avoid damaging the client’s reputation or dissatisfying the client’s customers.

After the client approves the plan, the next step is to work on the architecture. 

Read also: How we built an all-around medical SaaS solution

Stage 2: Architecture and database assessment and redesign 

Before starting on the architecture redesign, application architects evaluate the condition of the existing architecture to assess the scope of work.  

Architecture assessment 

Generally, application architects use the architecture trade-off analysis method (ATAM) and perspective-based analysis method (PBAM) to assess the architecture’s condition and its suitability for a SaaS model. 

• With ATAM, architects determine which components to eliminate or preserve to get a well-balanced design that they can use for a new delivery model. Alongside this, they look for ways of maximizing benefits and minimizing losses. 
• With PBAM, architects, taking into account the client’s business goals and future product scaling, consider how well the optimized architecture will comply with SaaS requirements. 

There are simpler approaches, such as coupling and application domain scoping. Using them, architects evaluate how application components relate to each other and how they communicate in the event that some are disabled. If the remaining components work smoothly in an independent manner, the architecture can be considered successful and doesn’t require drastic redesigning. 

However, if some changes in the code base break the logic throughout the whole solution, specialists will have to reconsider the system inside and out. An example of a bad architecture is a monolithic architecture in terms of package organization in code. A monolithic architecture is usually transitioned to microservices so each component can work independently and transmit data to other components through APIs.

Application architects also use architecture quality attributes to assess the architecture, such as:

Read also:  How to implement the most suitable software architecture for your business 

Besides assessing the architecture, it’s important to carry out a database analysis. 

Database assessment and redesign

The database redesign occurs at the same stage as the architecture redesign, since specifics of working with data affect the choice of cloud solutions for processing it. For example, if we are talking about streaming data that will pass through mobile devices, architects will need to use cloud platform services such as AWS Kinesis. These services collect and process a large amount of streaming data in real time. 

At this stage, architects think over the cloud deployment model and database sharing between multiple customers.

Cloud deployment models

When working with a SaaS application, it’s possible to support different cloud deployment models depending on the client’s needs. 

• The private cloud model enables customers to store data on independent cloud servers. 
• The public cloud model means all customers use a shared cloud and infrastructure. 
• The hybrid model entails the parallel use of public cloud and on-premises data centers or a private cloud. The precise mix usually depends on client and customer needs. For example, if a customer insists on isolated physical data storage, we will use this model and adjust the architecture to it.
• The multicloud model is used to store data and maintain an application’s functionality in cloud data storage from multiple cloud providers. This choice is good in terms of hedging against sudden incidents. For example, if one cloud storage fails, the application will still be accessible via cloud storage from another provider. 
• The hybrid multicloud model assumes the use of both public cloud storage and private storage.

Database sharing 

If the client chooses a public cloud model, customers (independent organizations or “cloud tenants”) will use the same hardware, storage, and network. There is a possibility that some customers would like to work separately from others at the database level. Generally, there are two ways of separating customer data: 

• Physical separation into several databases, which gives freedom in management but also requires more financial resources
• Logical division into data schemas within one database, which is a cheaper option that entails certain risks, since data of all users is kept in one place

After the cloud deployment and database sharing models are chosen, it’s time to work on the architecture redesign. 

Architecture redesign

Without a microservice architecture, it would be tough to create a SaaS application since microservices are the most suitable type of architecture for a SaaS product considering future scaling. The best option is to consider a layered microservice architecture. In this case, architects break the architecture down into several logical layers:

• Functional layer
• Integration layer for third-party integrations 
• Data layer 

The advantage of this approach is that developers can freely work with each layer in isolation. If the client wants to change an integration partner or re-optimize the database, work with the corresponding layers won’t affect other logical layers, and the application will work smoothly while work is in progress. 

Yalantis’ experience in transitioning from a monolithic architecture to microservices

Yalantis specialists worked on transitioning a monolithic to a microservice architecture for a large logistics company. During work on this project, our task was to divide the monolithic application into microservices. Each microservice had to be responsible for a specific feature. We configured their proper communication and data exchange between them. We also set up the CI/CD pipeline and automated the application testing process.

The responsible team also carried out data replication to ensure stable application performance in the event that a data center is not working well.

However, it’s important to remember that cases vary. With IoT or machine learning, architects would consider completely different scenarios.

Read also: The importance of IoT testing services: a performance testing framework

Additional aspects to take into account when working on the architecture design

At the architecture redesign stage, application architects also consider the following: 

• Service-level agreement (SLA). The SLA covers the service’s recovery time objective (RTO), recovery point objective (RPO), durability, latency, and high availability. Application architects have to create conditions under which the service will meet the requirements set for these metrics in terms of the application’s performance, availability, and quick recovery in case of a sudden incident. 

Otherwise, poor service performance may affect all stakeholders: 

1. The client may experience financial losses due to a poorly working service
2. Dissatisfied users may leave the service
3. The reputation of the development company will be tarnished

• Security measures. Besides implementing mechanisms for managing keys and secrets, assigning roles and responsibilities, and encrypting customer data, there are other aspects of ensuring application security that application architects need to take care of. It’s important to comply with security requirements for storage of users’ personal data within a particular industry and region. 

For instance, when Yalantis’ team was building a SaaS appointment scheduling solution, developers had to ensure compliance with HIPAA requirements for healthcare facilities. This is an advanced appointment scheduling platform for a medical practice that allows patients to find NPI-based doctors, book appointments with them, make online and offline payments for doctor appointments, and so on. Read this case study to see how we developed this SaaS solution.

Regulatory compliance may also closely correlate with the client’s business goals. For example, if the client plans to distribute the application to regions other than the USA, application architects must address this early. They will need to build the application so it complies with the GDPR, for example.

Once the architecture and database redesign is over, developers can start working on code.  

Stage 3: Codebase update

Depending on the condition of the existing codebase, there are two options developers can choose from:

• Rewrite code from scratch if it’s initially impossible to adjust it to the new delivery model because of unsuitable frameworks or programming languages. It’s better to start over to avoid unpredicted problems in the future.
• Work on the existing code by optimizing it and writing new functionality if its state is suitable for the cloud platform.

If developers go for the second option, they will go through the following stages:

1. Code optimization. Developers analyze code and optimize it. This may relate to rewriting certain parts of code that weren’t written according to best practices, have security weaknesses, or contain an excessive number of unnecessary elements. 
2. Code updating. Developers build new components that are necessary for SaaS solutions and may not be available in traditional applications — for example, admin dashboards for customers and support teams, additional functionality for billing and account management, and other elements. 
3. Code merging. This allows developers to combine different pieces of code that they worked on independently during optimization into a single codebase.
4. Code migration. In simple terms, this is a transfer of the codebase from one system to another.

When the application is ready for data migration, the next step is to test it to identify weaknesses in the code and send reports to developers to fix vulnerabilities found.

Stage 4: Testing 

At this stage, testers evaluate the stability of the application’s performance; conduct penetration testing, functional testing, and load testing; and test integration units to make sure that all components work accurately and work together smoothly. To avoid leaks of real data, testers and developers work with fictitious data.

As soon as the QA team confirms that the application works correctly and the development team finishes optimizing vulnerable spots, it’s time to migrate data.

Read also:  Unit testing for web software: why it’s necessary and which frameworks to use

Stage 5: SaaS Data Migration

Data migration is a rather complicated process that requires preparation and a detailed SaaS migration plan. Before starting migration, it’s crucial to wisely choose a:

• data migration model
• data migration strategy
• data migration tool 

Let’s go through each of these choices in detail.

Choosing a migration model

The migration model a client selects will depend on the time the client can afford to spend on migrating data and the amount of acceptable downtime:

Partial data migration occurs through a gradual transfer of data over several sessions. This option isn’t particularly convenient, however, because it requires the service to be unavailable for long periods of time. Sometimes, clients can’t afford this variant because the industry they operate in requires 24/7 availability and stable performance. 

There are other cases when it may be possible for customers to not use a service for a couple of hours, for example. In this case, the team can use those hours and gradually migrate data. However, this scheme will work only if data migration engineers can choose acceptable time windows and be sure that no customer will need to use the service at those times. It’s important to take into account customers’ time zones and analyze usual periods of activity.

The process usually goes like this:

1. Data engineers determine the precise amount of time they can use to transfer data. 
2. Data engineers conduct user and database segmentation, i.e. they group customers by shared characteristics such as company size, industry, and type of subscription model. 
3. After segmentation, new users are automatically transferred to the new service, whereas old users continue to work with the old service while specialists gradually migrate their data. 
4. When engineers have migrated all data to the new database, the team deactivates the old service. 

Full data migration involves transferring all data in one go. The problem with this method is that the service will be unavailable to customers for a long time. The amount of data to migrate determines the length of time. In some cases, migration can take a few days or a week.

Data mirroring is a form of data replication. With data mirroring, data migration specialists copy data from an old application to a new one in real time. This method is more user-friendly because customers can continue working with the existing application without noticing any changes. With data mirroring, the team can also gradually move a certain number of users to the new service to check how the functionality works. 

Microservice migration is used to gradually and invisibly transfer data to the cloud storage of a new application. For microservice migration, developers deploy a newly created microservice and transport it to a new environment with data associated with the functionality this microservice is responsible for. The old components send data incrementally to the new microservice and over time the whole service acquires data from the old application.

If data migration occurs when the service is down, DevOps have to take into account that some data may be damaged or unexpected bugs may appear in the middle of the process. If this happens, they have to be ready to call for a team and solve all issues. Such a migration requires careful work on CI/CD pipeline jobs, advanced data backups, and officers-in-charge who can solve any problem quickly.

We have described the most common migration models. The choice of model depends on the client’s business model and expectations. Thanks to SaaS model opportunities, we can adjust the migration process to specific clients’ needs.

Choosing a SaaS migration strategy

While a data migration model is a method for transferring data to cloud storage, a data migration strategy is a plan for successfully migrating data according to the chosen model. You can read about these strategies in detail in our article dedicated to cloud migration strategies. 

In this article, we’d like to emphasize the importance of choosing a proper migration strategy. By applying a migration strategy, data engineers optimize an existing database format so it can work smoothly with a new delivery model. Let’s compare two situations to make this clearer. 

There are some ideal scenarios for working with data. For example, the team can use the lift-and-shift strategy if they don’t need to somehow change the database itself to adjust it to SaaS requirements. With the lift-and-shift strategy, the team simply generates identical tables and diagrams in a new data storage and synchronizes them or transfers them using snapshots. This process is easy. 

However, there are less rosy scenarios. Sometimes, when transferring data from one huge SQL database, the engineering team needs to separate it into several NoSQL databases. This significantly complicates the process. Before the migration, engineers have to carry out excessive data processing, decomposition, denormalization, and other procedures.

With a well-thought-out migration strategy, SaaS data migration will go smoother.

After the data migration model and strategy have been approved, the team can jump to migrating data.

Read also:  Vital things to consider when choosing a database for your app

Aspects to consider when choosing data migration tools

Cloud providers offer custom tools for migrating data to their services, such as database migration services from AWS, Azure, and Google. Before migrating data, information technology experts have to consider all requirements and risks in terms of data security. These tools must meet a number of criteria:

• Reliability. Since SaaS data migration is a serious and time-consuming process, it’s crucial to make sure the chosen tool will work without interruption throughout the whole process.
• Security. It’s necessary to choose only those tools that meet the security requirements of certain acts, standards, frameworks, regulations, or policies, since data migration engineers are migrating sensitive user data and have to avoid data leaks.
• Flexibility. Cloud-based services have no problem with flexibility. You never know what can happen during data migration. Thanks to the flexibility of data migration tools, such as the ability to adjust to any changes in the middle of the migration process, data migration specialists can solve unexpected problems faster. 
• Pricing. The cost of migration depends on the amount of data and the time it will take to transfer this data to cloud storage. It’s necessary to calculate all costs before choosing the most suitable option

Data migration is closely related to the stable operation of the network, so it’s crucial to check everything in advance.

We have almost reached the end. After data migration is completed, there are some final touches left.

Final stages: Testing, deployment, and metering

These processes are similar to those for developing a SaaS application. 

After data has been migrated, the QA team checks the application’s stability. A group of users called beta testers conduct user acceptance testing, or UAT, right before the release. They utilize a test environment to check how the application copes with real business and functional tasks, whether it responds correctly to user requests, and if there are any problems working with real data. If the QA team gives their approval, it’s time to deploy the application to the production environment.

After the application has been released, it’s necessary to constantly monitor the system and server performance, keep track of component load and other health indicators, and detect processes that need to be optimized.

The next steps are collecting user feedback, gathering and analyzing statistics on the service’s performance, and working on post-MVP versions of the application.

Yalantis actively supports process automation at each stage of building or migrating an application and encourages clients to follow this practice. This specifically concerns application testing, deployment, and monitoring. Such an approach is useful not only for our company but also for our clients because process automation can help them spend less money on human resources yet receive a high-quality application.

For example, when designing an application’s architecture, we usually consider implementing mechanisms for automated incident management that will notify the network operation center (NOC) or on-call team of sudden incidents. With risk assessment and management strategies designed in advance, these specialists will be able to cope with any problem effectively and quickly. 

We also use CI/CD pipelines for continuous integration and deployment and automate the process of code verification with static application security testing (SAST) tools to identify vulnerabilities and resolve them in real time. 

You can read more about such measures in our article about developing a SaaS application from scratch.

Read also: Our SaaS development expertise

The process of migrating from traditional applications to SaaS solutions is time-consuming and resource-intensive. However, these efforts will bring the client an innovative solution with the enormous capabilities and benefits of SaaS products and present them with a ticket to a bright future. Yalantis provides SaaS software migration services and has experience migrating traditional applications to SaaS in different domains. Based on this first-hand experience, we have come up with our own cost-effective and efficient application migration strategy that we are ready to apply to your solution.