In Short
To comply with Uganda’s health-data privacy laws, SolDevelo migrated the Vxnaid healthcare system from AWS EC2 and RDS to local, on-premises physical servers. SolDevelo adapted the deployment model to match national data sovereignty requirements, executing a migration without requiring changes to the application code.
When the Best Architecture Isn’t the One You Started With
Cloud is often the natural choice for deploying modern healthcare applications. It provides scalability, managed services, automation, and a well-established security model.
But infrastructure decisions are never purely technical.
For healthcare systems, particularly those handling sensitive patient information, questions of data governance, local control, connectivity, operational ownership, and national requirements can be just as important as scalability.
That was the situation we encountered with Connect for Life (CfL), where SolDevelo supports an implementation known as Vxnaid, deployed for Infectious Diseases Institute (IDI) in Uganda.
As an AWS Partner, SolDevelo regularly helps organizations build and optimize cloud infrastructure. But when the requirements for Vxnaid shifted, we worked to deliver the architecture the client actually needed. The decision was made to migrate the deployment from AWS to infrastructure hosted on-premises in Uganda.
A Changing Landscape for Digital Health in Africa
There is a broader context behind decisions like this. African healthcare systems are increasingly placing emphasis on data governance, sovereignty, security and local ownership of digital infrastructure.
This does not mean that African healthcare is moving universally away from cloud computing. In fact, the opposite is also happening: cloud infrastructure is being used for major regional initiatives, including the WHO African Regional Health Data Hub.
The trend is therefore less about cloud versus on-premises and more about who controls the infrastructure and the data, where that infrastructure is located, and what deployment model makes sense for a specific health system.
Uganda has developed dedicated health-data protection and confidentiality guidelines, as well as guidelines governing health-data access, sharing and usage. These regulations align with the country’s Data Protection and Privacy Act and its broader digital-health strategy.
At the same time, the WHO African Region has identified data governance, interoperability, digital infrastructure and national ownership as important components of the development of stronger health-information systems.
For organizations operating healthcare systems in this environment, local infrastructure is a deliberate architectural choice – not a step backwards from the cloud. For IDI and Vxnaid, that choice meant moving the existing AWS deployment to infrastructure located in Uganda.
The Starting Point: Moving AWS EC2 + RDS to Physical Infrastructure
The existing Vxnaid deployment consisted of a relatively straightforward architecture:
- Application services running in Docker containers on Amazon EC2
- A PostgreSQL database hosted on Amazon RDS
- Docker volumes containing application data
- AWS providing the underlying infrastructure and network environment
The target environment was fundamentally different. Instead of a single cloud environment, the on-premises installation consisted of two separate physical servers:
- An application server, running the Docker-based Vxnaid application.
- A database server, hosting the application’s database.
This introduced a key requirement for the migration: reproducing the complete state of the running system outside AWS without changing the application itself.
The goal was simple: Move the application and its data, not redesign the application.
Pre-Migration Dry Run: Validating Docker & RDS Transfers
Before touching the production environment, we performed a complete migration dry run. Validating the migration procedure beforehand – from moving containers to restoring the database – prevented unexpected issues during the actual cutover.
The migration process consisted of three main elements:
1. Migrating Docker Containers
The Vxnaid application was already packaged as Docker containers, which made the application layer considerably easier to move between environments.
The target server did not need to reproduce the AWS infrastructure itself. It simply needed to provide a compatible environment in which the existing application containers could run.
This is one of the practical advantages of containerization: the underlying infrastructure can change substantially while the application packaging remains largely the same.
2. Migrating Docker Volume Data
Containers represent only part of an application’s state. We also needed to migrate data stored in Docker volumes.
The volume contents were transferred to the new environment and restored into the corresponding locations on the application server. This ensured that the application did not simply start from a clean installation, but retained the state accumulated by the existing deployment.
3. Migrating the Database
The database presented a similar challenge.
The source database ran on Amazon RDS, while the target database would run directly on the dedicated on-premises database server. We performed a database dump from the RDS environment and restored it onto the physical database server.
The dry run allowed us to validate the complete chain:
- Database path: RDS → database dump → on-premises database
- Application path: AWS Docker deployment → container and volume migration → on-premises application server
Once both paths were validated, we had a repeatable migration procedure ready for production.
Zero-Downtime Cutover: Friday Night Production Migration
The actual migration was carried out in the late hours of a Friday. For a healthcare system, minimizing disruption is more important than making the migration convenient for the engineering team. Performing the cutover outside the normal working period gave the team a significantly better maintenance window and reduced the impact on users.
The production migration followed the procedure established during the dry run:
- The existing AWS deployment was taken to its final migration state.
- Application data and Docker volumes were transferred.
- The RDS database was exported and restored on the dedicated database server.
- The application was brought online on the new infrastructure.
The key advantage of having performed the dry run was that the production migration was no longer an experiment. We already knew the procedure. We have worked closely with the local team during this procedure in order to facilitate a successful transition.
The final step was changing the DNS entry to make the domain point to the new environment – for which we prepared beforehand by setting a low Time-to-Live (TTL) value – it ensured the old IP was not cached for long on DNS servers across the world.
HTTPS: Fixing a Problem Before It Became a Problem
There was another important part of the deployment that went beyond simply moving the application. During the deployment, we updated the application’s HTTPS configuration to meet the local environment’s security requirements.
This turned out to be particularly important for compatibility. The initial certificate configuration caused connection errors on older Android devices. Modern browsers and operating systems can sometimes hide certificate-chain problems because their trust stores contain newer intermediate certificates or are more forgiving about how chains are constructed. Older devices are often less forgiving.
Rather than treating this as an application problem, we addressed the underlying infrastructure issue and configured the server with the appropriate full certificate chain.
This is a good example of why infrastructure migrations are rarely just a matter of copying files from one server to another.The surrounding environment matters, too. A deployment that works in one environment can expose previously hidden problems when moved to another.
Why AWS Expertise Doesn’t Mean “Everything Belongs in the Cloud”
SolDevelo is an AWS Partner, but true technical partnership means putting client outcomes ahead of platform preference.
It would have been easy to approach the project from the perspective of: “We specialize in AWS, therefore the solution should stay in AWS.”
But that would have ignored the customer’s actual needs. Our role is not to maximize cloud resource consumption, but to deliver working, reliable systems that respect our clients’ constraints.
In this case, that meant taking an application originally deployed using EC2 and RDS, and moving it to two on-premises servers in Uganda. The underlying engineering principles remained the same:
- understand the existing architecture
- understand the target environment
- protect the customer’s data
- establish a repeatable migration procedure
- test before production
- minimize downtime
- validate the resulting system
- solve infrastructure problems as they appear
The platform changed. The engineering discipline did not.
The Value of Platform-Flexibility in Modern Health Engineering
Modern infrastructure engineering increasingly means being comfortable across multiple environments.
Cloud platforms provide enormous advantages, but organizations frequently have compelling reasons to maintain workloads on-premises:
- data governance requirements
- local ownership of infrastructure
- connectivity considerations
- operational policies
- organizational requirements
- regulatory or contractual constraints
- integration with existing local infrastructure
The correct architecture is the one that satisfies all technical, legal, and operational constraints.
For Vxnaid, the answer was an on-premises deployment.
Thanks to containerization and thorough pre-migration testing, we executed that transition without fundamentally redesigning the application.
The Takeaway: Pragmatic Infrastructure Over Platform Dogma
From a purely technical perspective, this project was a straightforward migration: shifting containerized services and an RDS database onto dedicated physical servers.
But the broader value lay in adapting the infrastructure to real-world operational constraints. Cloud platforms offer immense advantages, but factors like national data sovereignty, local governance laws, and field-level device compatibility dictate what architecture actually makes sense. True infrastructure engineering means evaluating the client’s context, choosing the right tools for their environment, and executing the transition safely.
Navigating complex infrastructure requirements?
AWS, on-prem, or hybrid – the right architecture is the one that solves your real-world constraints. Partner with an engineering team that puts your business objectives first.
