Monolith to Microservices Case Study for Healthcare SaaS
See how we moved a healthcare SaaS platform from a monolith toward a modern, scalable, and distributed architecture.
OUR CUSTOMER
Therapy Management SaaS
TherapyBOSS is a healthcare SaaS platform for therapy companies and home health agencies. The solution helps home health professionals coordinate patient care, manage referrals and scheduling, complete electronic documentation, track reassessments, and communicate within care teams. At the time, the web and mobile platform had more than 3,000 providers signed up.
THE CHALLENGE
Scaling Beyond a Legacy Monolithic Architecture
TherapyBOSS was originally built as a monolithic application, with all core functionality hosted on a single on-premise server and supported by one shared database. While this architecture was suitable at the early stage of the product, it became a limitation as the platform grew and user activity increased. The platform needed a more scalable cloud-based application structure to support further product development.
The main challenge was to modernize the system without disrupting a SaaS platform used by thousands of customers for their daily workflows..
The core challenge was compounded by several underlying issues:
- Single point of failure
The entire application depended on one server and one database. If a critical component failed, the whole system could become unavailable, affecting essential care management workflows. - Performance limitations
As user activity increased, the monolithic architecture created bottlenecks. Scaling the entire application was possible, but it did not fully solve database load issues or service-level performance constraints. - Growing infrastructure costs
Since individual parts of the system could not be scaled independently, the client had to allocate more infrastructure resources to support the entire application, even when only specific functions required additional capacity. - Complex and risky deployments
In a tightly coupled system, even minor updates could affect other parts of the application. This made releases slower, more resource-intensive, and riskier for a platform supporting healthcare operations. - Limited scalability
Adding new features or expanding existing functionality further required changes across the application structure. This slowed down product evolution and made it harder to support growing business and user demands. - High dependency between functionalities
Closely connected components made maintenance, debugging, and issue isolation more difficult. A change in one area could create unexpected effects elsewhere, increasing development effort and the risk of downtime.
THE SOLUTION
Monolith-to-Microservices Migration
To overcome the limitations of the original monolithic architecture, we modernized TherapyBOSS in several stages. The goal was to improve performance, reliability, deployment speed, and scalability.
Implement an Interim Architecture
The web application and database were hosted on a single Windows server, with all builds and deployments handled manually. As a full architectural rebuild was not feasible at once, Romexsoft first introduced an interim architecture to improve system stability and performance.
The team implemented several key changes:
- added a second web server to reduce the load on the original server
- introduced Nginx load balancing to distribute traffic between two web servers
- migrated from MySQL to MariaDB to improve database performance
- set up database replication to distribute database load across different nodes
- moved from Windows Server to Linux Ubuntu to improve security and create better conditions for infrastructure automation.
These changes helped the platform handle growing user activity and improved the overall user experience for the next stage of product development under the modernization.
Moving Toward Microservices
Once the interim architecture reached its limits, our engineering team started a deeper modernization. They began gradually breaking the monolith into microservices by extracting selected functionality from the core application and moving it into separate services with dedicated resources.
One of the first separated components was the synchronization logic between the web and mobile applications. This functionality was moved out of the core system and treated as an independent service.
At this stage, our team also implemented several important architectural changes:
- added two instances for each microservice
- introduced load balancing between service instances
- framework modernization from Struts to Spring MVC and later to Spring Boot.
Strengthening Reliability and Scalability
To reduce the risk of downtime, our specialists redesigned the infrastructure so that key services were duplicated across separate physical servers.
The updated setup included:
- two instances for each microservice
- load balancers to distribute requests
- separate resources for the core web application and microservices
- dedicated infrastructure for DEV and PROD environments
- duplicated services to keep the system available if one physical server failed.
This helped remove the single point of failure and made the application more resilient under growing load.
Automating Delivery and Testing
To address manual deployment challenges, we introduced automation into the delivery process. The team implemented:
- Jenkins for CI/CD automation to reduce manual deployment effort and make releases more predictable
- Selenium and Cucumber for automated regression testing to help the team verify critical changes more efficiently
- separate DEV and PROD environments to support safer releases and reduce the risk of production issues.
Improving Infrastructure Management and Monitoring
As the architecture became more complex, we added tools to simplify infrastructure management and improve overall system visibility:
- Proxmox to get more controlled administration of the expanded infrastructure
- Zabbix for monitoring the web app, microservices, and hardware infrastructure to detect potential incidents earlier.
Redesigning the Database Layer
The data storage was also modernized to address performance bottlenecks, reduce the impact of SQL-related limitations, and support the new architecture.
Romexsoft introduced:
- MariaDB for the core web application to support existing SQL-based business logic and improve database performance
- MongoDB for microservices to provide a more agile and scalable data layer for separated services
- Apache Kafka for asynchronous operations and real-time data streams
- MariaDB Galera Cluster with MaxScale to improve request processing and fault tolerance.
The Used Toolkit
THE RESULTS
Scalable Application Structure
As a result of Romexsoft’s work, TherapyBOSS moved from a single monolithic setup toward a more distributed and scalable application structure. The core application no longer had to carry all functional load, as selected workloads could run outside the main system.
Our specialists prepared the product for continued feature growth, higher user activity, and further modernization. The updated infrastructure setup also made it easier for the engineering team to monitor the expanded system, identify potential issues earlier, and support more stable operations.
WHY ROMEXSOFT
Modernization Partner for Healthcare SaaS
Romexsoft is an AWS Advanced Tier Services Partner and with vast and well-rounded experience in application modernization on AWS. Our specialists assess legacy healthcare software limitations and modernize existing systems where improvements create the most business and technical value.
To support every stage of application modernization, we deliver:
- Modernization assessment for a clear improvement path
- Infrastructure modernization to strengthen scalability and reliability
- Database modernization for fewer performance bottlenecks
- CI/CD automation for safer, more predictable releases
- Automated testing to verify changes faster and prevent regression
- Infrastructure monitoring setup to improve system visibility.
Frequently Asked Questions
What parts of a legacy application should be modernized first?
Legacy application modernization should start with the areas that create the highest operational risk: infrastructure reliability, database performance, deployment processes, testing, and monitoring. After the system is stabilized, selected functionality can be gradually separated or rebuilt, starting with components that are easier to isolate and have a clear impact on scalability, performance, or maintainability.
How can legacy software be modernized without disrupting daily operations?
A gradual modernization approach helps development teams improve legacy systems without disrupting daily operations. The process usually starts with infrastructure stabilization, database performance improvements, monitoring, environment separation, and deployment automation. Then, selected functionality can be modernized step by step while providers continue using the platform.
Why is automated regression testing important during application modernization?
Automated regression testing is important during application modernization because even small changes can affect existing functionality in unexpected ways. As infrastructure, databases, deployment processes, or application components are updated, automated tests help verify that critical workflows still work as expected.
For healthcare software, this is especially important because users rely on the platform for daily care coordination, scheduling, documentation, and other operational workflows. Regression testing helps detect issues earlier, reduce manual testing effort, and make releases safer throughout the modernization process.
Can application modernization be done without a complete migration to microservices?
Yes. The right modernization approach depends on the current state of the application, its technical limitations, business goals, and the level of change the system can safely support. That is why modernization should usually start with a technical assessment.
In many cases, meaningful improvements can be achieved through infrastructure stabilization, database optimization, CI/CD automation, automated testing, monitoring, and selected code or architecture updates. A microservices migration may be useful when specific parts of the application need to scale, change, or operate independently, but it should be introduced only when it solves a clear technical or business problem.
