When MedSync first contacted us, their deployment process was a four-hour ordeal. A .NET monolith serving 200+ healthcare facilities, deployed manually through a series of scripts, database migrations, and prayer. Their CTO described it as “the most stressful four hours of every sprint.” By the time we finished the migration, they were deploying 8 times per day with zero downtime. Here is exactly how we did it.
The Starting Point
MedSync patient records platform had grown organically over seven years. What started as a simple CRUD application had become a 2-million-line .NET monolith with a single SQL Server database containing 340 tables. The application handled patient records, appointment scheduling, billing, lab results, and secure messaging — all in one deployable unit.
Their deployment process looked like this:
- Schedule a 4-hour maintenance window (typically Saturday night)
- Send notifications to all 200+ healthcare facilities
- Take the application offline
- Run database migrations (often 30+ minutes)
- Deploy the new application binary
- Run smoke tests manually
- Bring the application back online
- Monitor for 2 hours for any issues
If anything went wrong at step 4 or later, the rollback procedure took another 2 hours. They deployed every two weeks and lived in fear of each deployment.
Phase 1: Discovery (2 Weeks)
We spent the first two weeks understanding MedSync architecture, domain boundaries, and team structure. We interviewed every engineering team lead, mapped all database dependencies, and profiled the application traffic patterns.
Key findings:
- 80% of traffic was read-heavy (viewing patient records, checking schedules)
- The billing module had the most frequent changes and the most deployment risk
- Lab results integration was the most latency-sensitive component
- HIPAA compliance required strict audit logging and data encryption
- The team had no automated testing beyond a small unit test suite
Phase 2: Architecture Design (3 Weeks)
We designed a target architecture of 12 microservices running on Azure AKS, chosen for MedSync existing Azure investment and AKS HIPAA compliance posture. The services were bounded by domain context:
- Patient Records Service (core CRUD operations)
- Appointment Service (scheduling, availability)
- Billing Service (claims, payments, invoicing)
- Lab Integration Service (external lab system connections)
- Messaging Service (secure patient-provider communication)
- Auth Service (authentication, RBAC, audit logging)
- Notification Service (email, SMS, push notifications)
- Reporting Service (analytics, compliance reports)
- Plus four supporting services (config, gateway, search, file storage)
Each service would have its own database — PostgreSQL for transactional services, Elasticsearch for search, and Azure Blob Storage for medical documents. Inter-service communication would use Azure Service Bus for async events and gRPC for synchronous calls.
Phase 3: Dev Environment (1 Week)
Before writing any migration code, we set up local development environments using Tilt and kind (Kubernetes in Docker). Every developer could run the full system locally with hot-reload. We also created a shared staging environment on AKS that mirrored production configuration.
This investment paid for itself immediately. Developers went from “I will test it in staging after the next deployment” to “I can test it right now on my laptop.”
Phase 4: Migration (8 Weeks)
We used the Strangler Fig pattern, starting with the Billing Service — the highest-risk, most-frequently-changed module. The migration sequence for each service followed a consistent pattern:
- Extract the service code from the monolith into a new repository
- Create a dedicated database and write data migration scripts
- Build CI/CD pipeline with ArgoCD for GitOps deployment
- Deploy behind a feature flag with traffic splitting
- Gradually shift traffic: 1% → 10% → 50% → 100%
- Remove the old code path from the monolith
The Billing Service migration took 2 weeks. By the fourth service, we had the process down to 4-5 days per service. The monolith continued serving traffic throughout — no maintenance windows required.
Phase 5: Testing (3 Weeks)
We implemented a comprehensive testing strategy:
- Contract tests between every service pair using Pact, ensuring API compatibility
- Integration tests running against the full system in staging
- Load tests simulating 3x peak traffic to validate scaling behavior
- Chaos engineering using Litmus to kill pods, inject network latency, and simulate node failures
- HIPAA compliance testing validating encryption, audit logging, and access controls
The chaos engineering phase uncovered two critical issues: the Lab Integration Service did not handle connection pool exhaustion gracefully, and the Messaging Service had a race condition in message delivery tracking. Both were fixed before production cutover.
Phase 6: Results
After 14 weeks of migration work, MedSync new architecture delivered dramatic improvements:
- Deployment time: From 4 hours to 23 minutes (10x improvement)
- Deployment frequency: From biweekly to 8 times per day
- Downtime: From 4 hours per deployment to zero
- Infrastructure cost: Reduced by 50% through right-sized services and auto-scaling
- Incident response: Mean time to recovery dropped from 45 minutes to 8 minutes
- HIPAA audit prep: From 3 weeks to 2 days (automated compliance reporting)
The biggest win was cultural. MedSync engineering team went from dreading deployments to treating them as routine. Feature velocity increased by 300% in the first quarter after migration. The CTO told us: “Saturday deployments used to ruin my weekend. Now I do not even know when we deploy — it just happens.”
Key Takeaways
Every migration is different, but some lessons are universal:
- Start with discovery. Understanding your current system is more important than designing the target architecture.
- Migrate incrementally. The Strangler Fig pattern eliminates big-bang risk.
- Invest in dev environments early. Developer productivity compounds throughout the project.
- Test aggressively. Chaos engineering finds bugs that unit tests never will.
- Measure everything. You cannot prove the migration was worth it without before-and-after metrics.
If your team is dealing with painful deployments, scaling limitations, or compliance headaches, book a free architecture review. We will assess your system and show you what a modern architecture could look like — with specific timelines and expected outcomes.