Modernising a Legacy Pharma CRM for US Market Entry

The challenge

For a European healthcare tech company, compliance in EMEA mainly means GDPR, and that is familiar ground. The US works differently. SOC 2 Type II, HIPAA technical safeguards and GxP validation for pharma workflows each add their own architecture constraints, and the platform had not been designed with them in mind. Adding compliance to a mature monolith without a clear architecture plan quickly creates technical debt, and that debt can block the very market entry it was meant to support.

The platform was a tightly coupled PHP monolith with over 660 database tables, built step by step over many years and never systematically documented. The internal team spent most of its capacity on maintenance and had no room for modernisation. Before any architecture decision, the coupling hotspots and data flows had to be reverse-engineered into a reliable “as-is” map.

The market-entry deadline was fixed. The US pharma CRM market has a strong incumbent, Veeva Systems, with deep compliance credibility, offline sync and regional localisation. Entering it without proven compliance readiness, a credible architecture and comparable performance would not work commercially. The architecture work had to produce a validated, concrete direction within weeks, and a working proof of concept was mandatory.

My task: define the technical direction end to end, lead the Platform team and deliver a validated architecture with a working proof of concept in under three months.

What do SOC 2, HIPAA and GxP mean for a software platform?

The US has no federal privacy law like GDPR, so US customers check software vendors against a set of standards instead. SOC 2 Type II is an independent audit report on how a service company protects customer data, with its controls tested over a period of 3 to 12 months. Many US enterprise buyers ask for it in their vendor security review. HIPAA is the US law that protects patients’ health information. Its Security Rule asks for technical safeguards in five areas: access control, audit controls, data integrity, user authentication and secure data transmission. There is no official HIPAA certificate, so a vendor has to show how its system meets these rules. GxP is the family of “good practice” rules in pharma and life sciences. For software it means validation: proof that the system works as intended and keeps reliable, traceable records. In the US, the FDA rule 21 CFR Part 11 covers electronic records and signatures.

Together, these rules decide how data is stored, who can see it, what is logged and how changes are released. That is why they shape the architecture itself, and why they were defined as quality goals before the target design was drawn.

What I did

1. Aligned stakeholders and set measurable quality goals

   Before any architecture decision, I ran stakeholder and capability-mapping workshops using BTABoK, linking CRM features to revenue, compliance obligations and field-rep efficiency. Then I defined about 15 quality-attribute scenarios covering availability, latency, offline sync, extensibility, customisation and regionalisation. These scenarios became binding acceptance criteria for every later architecture choice, so the target design had to meet what the business actually needed.

   Technical details

   • Quality targets: 99.0% uptime SLA, p95 latency under 200 ms, offline sync, extensibility, customisability and regionalisation across 3+ deployment regions.
   • Quality-attribute scenario: a short, testable statement of how the system must behave, for example how fast it must respond under a given load.
   • BTABoK: the Business Technology Architecture Body of Knowledge, a framework that ties architecture work to business value.

2. Reverse-engineered the 660-table PHP monolith

   I did a deep current-state analysis with TOGAF ADM: coupling hotspots, database schema dependencies and BPMN process flows. With 660+ tables and no systematic documentation, this needed both technical depth and a structured method. The result was an “as-is” architecture with a risk register that captured every pattern likely to break during modernisation, before any target design was proposed. You cannot strangle a monolith safely without a reliable map of it.

   Technical details

   • TOGAF ADM: the Architecture Development Method of TOGAF, a widely used enterprise architecture framework. BPMN is a standard notation for drawing business processes.
   • Strangler approach: new services take over parts of the old system one by one while the old system keeps running, so there is no big-bang switch.

3. Designed a compliance-ready target architecture with Go microservices

   Using Domain-Driven Design, I split the platform into about 10 autonomous Go services across bounded contexts such as Accounts, HCP (healthcare professional), HCO (healthcare organisation), Samples and Compliance. Each service uses hexagonal architecture to keep domain logic separate from adapters, so compliance can be tested and validated for each service on its own. Services talk through Apache Kafka events to support near-real-time pharma supply chain workflows. The design also answered Veeva’s strengths directly: offline mode through a progressive web app cache layer, and regional compliance through a Kubernetes cluster per region. Every technology choice was recorded in an Architecture Decision Record with its business reason.

   Technical details

   • Stack: Go 1.22, PostgreSQL, Apache Kafka, Terraform and Kubernetes, Prometheus and Grafana.
   • Hexagonal architecture: the business logic sits in the middle and talks to the outside world (APIs, database, Kafka) only through ports and adapters, so each part can be tested and replaced on its own.
   • Architecture Decision Record (ADR): a short document that records one technical decision and the reason for it.

4. Proved the design with a working Go pilot service

   I led the Platform team directly to build the Accounts service as the reference implementation. It was the bounded context with the highest data coupling, so it gave the clearest test of the design. We benchmarked the Go pilot against the equivalent PHP endpoint: throughput went up more than 4 times and p95 latency dropped by about 60%. Chaos testing checked the service against the availability scenarios.

   Technical details

   • Service: domain core with ports and adapters, REST and gRPC adapters, PostgreSQL repository, Kafka producer, unit and contract tests with over 80% coverage.
   • Delivery: reusable Terraform modules (VPC, RDS, EKS), a multi-stage GitHub Actions pipeline that replaced CircleCI, and Kubernetes deployment with Helm.

5. Set up governance and a phased migration roadmap

   I delivered an Architecture Playbook with service templates, coding standards, the ADR workflow and a mandatory threat-model and quality-attribute checklist for every new service. Data flows were mapped to GxP and GDPR controls, with audit logging and validation SOPs. The rest of the migration was grouped into three waves (Customer 360, Territory Management and Analytics), each with go/no-go criteria tied to the quality-attribute KPIs. The final output was an executive briefing that compared the target platform with Veeva on feature parity and on differentiators such as real-time analytics and an open stack, together with a 6-month migration roadmap and a budget model.

Results

In under three months the company had:

• An approved target architecture of about 10 hexagonal Go microservices, designed for SOC 2 Type II, HIPAA and GxP from the start.
• A working Accounts service in Go with over 4× the throughput and about 60% lower p95 latency than the PHP version, plus CI/CD, Kubernetes deployment and chaos tests.
• A reliable “as-is” map of the 660-table PHP monolith, with a risk register.
• About 15 quality-attribute scenarios that every architecture decision had to meet.
• An Architecture Playbook and a mapping of data flows to GxP and GDPR controls, with audit logging and validation SOPs.
• A live 6-month migration roadmap in three waves, each with go/no-go criteria, and a budget model.

What I learned

Market expansion shows platform limits that normal operations keep hidden.

A platform that works well in one regulatory environment, with a familiar customer base, can look perfectly healthy until you try to take it somewhere new. The US market only revealed problems that were already there. Compliance architecture and product architecture are the same decision: you cannot make a system HIPAA-compliant by adding compliance features to a design that wasn’t built for it. And a pilot with measured results removes more risk than a perfect architecture document. The 4× result from the Go service did more for stakeholder confidence than any diagram could.

Evidence and further reading

• Related projectFrom COBOL mainframe to cloud-native microservices: the unified DevOps platform for SIXT Leasing SEAnother legacy system moved to microservices.
• Service · this siteCloud migration consultingHow compliance such as SOC 2, HIPAA and GxP is built into a migration.
• Article · this siteArchitecture in an Unstable World: a practical framework for geopolitical riskHow regulation becomes an input to architecture decisions.

“Architecture in an Unstable World” was also published on CloudTweaks.

Skills and technologies

• Legacy modernisation
• Healthcare and pharma CRM
• SOC 2 Type II
• HIPAA
• GxP
• Compliance architecture
• TOGAF
• BTABoK
• Domain-Driven Design
• Hexagonal architecture
• Go microservices
• Event-driven architecture
• Apache Kafka
• PostgreSQL
• Kubernetes
• Terraform
• GitHub Actions
• Architecture Decision Records
• Quality-attribute scenarios
• Team leadership

← All projects