A worldwide search engine for medical providers, built in 2011 and substantially unchanged since 2013. The assessment found that unsupported and retired platform components, no reliable documentation, rising operating cost, and compliance gaps make a controlled rewrite the responsible option.
MediAtlas is a valuable data product, but it is no longer a supportable software product. Keeping the relational provider database preserves the business asset and avoids a high-risk data conversion. Rebuilding the application, search, delivery platform and operating model removes the constraints that patching cannot address.
The platform depends on Azure Cloud Services (classic), retired in 2024, unmaintained client packages, and a .NET Framework application that cannot benefit from modern .NET platform capabilities. Patching is increasingly a bespoke operation.
No current architecture, deployment, data-flow, or interface documentation exists. Two remaining maintainers rely on tribal knowledge, and release changes cannot be estimated or safely reviewed with confidence.
Always-on role instances, duplicated indexing, manual recovery work, and broad privileged access create a high fixed cost. The platform spends more to remain available than a right-sized modern service needs.
The score reflects verified observations from the fictional codebase, cloud subscription, release history and stakeholder interviews. The lowest scores are deliberately different from the Contoso stability case: lifecycle support, maintainability, governance and cost control dominate this decision.
| Domain | Score | Assessment signal |
|---|---|---|
| Architecture | 18% | Tightly coupled web, indexing and import jobs |
| Code & documentation | 12% | No maintained documentation or automated tests |
| Security & privacy | 24% | Shared accounts and incomplete data-flow records |
| Cloud & cost | 19% | Retired hosting model and permanent overprovisioning |
| Delivery | 16% | Manual releases and no repeatable environment build |
| Search & data | 31% | Provider database is sound; index pipeline is brittle |
| Observability | 21% | No traceable search or import failure path |
| Resilience | 41% | Database backup exists; recovery is untested |
Evidence: the web UI uses KnockoutJS bindings interwoven with server-rendered views and business rules; deployment targets retired Cloud Services (classic); dependencies have no owner or upgrade path. Impact: any urgent browser, security or hosting change can turn into an unbounded rewrite under pressure. Recommendation: replace the application layers deliberately, with the existing database as a governed system of record.
Evidence: there are no current API contracts, field lineage, retention decisions, or operational runbooks. Impact: onboarding, incident response, privacy requests and supplier assurance depend on individual memory. Recommendation: use AI-assisted code analysis to accelerate discovery, then validate every generated artifact with domain experts before using it as the rewrite baseline.
“Rewrite” does not mean discarding the business. It means retaining the validated provider database and rules that are confirmed during discovery, while replacing layers whose support, safety and cost characteristics cannot be corrected independently.
| Decision factor | Continue patching | Controlled rewrite |
|---|---|---|
| Platform support | Retired hosting and legacy dependency exposure remains | Supported runtime and repeatable hosting baseline |
| Delivery confidence | Manual releases and undocumented coupling | Contract tests, CI/CD, runbooks and observable releases |
| Cost trajectory | Fixed capacity and increasing specialist maintenance | Right-sized services; estimated €168k annual reduction after transition |
| Data risk | Low change now, but weak governance evidence | Database retained; lineage, access and retention controls formalised |
The migration starts only after the assessment evidence has been accepted. The existing relational provider database remains the source of truth. New read models and search indexes are rebuilt from it, validated in parallel, and switched over feature by feature.
Use AI to inspect code paths, extract candidate business rules, map database usage and generate first-pass technical documentation. Product, clinical-data and engineering owners review the output; no generated statement becomes a contract without validation.
Create documented APIs and import pipelines on .NET 10. Replay provider changes into the new index, compare relevance and completeness by country and language, then introduce the new Nuxt experience behind controlled rollout flags.
Containerise services and run them on Azure App Service. Add CI/CD, infrastructure-as-code, cost budgets, alerting, documented recovery exercises and service ownership before retiring the legacy application.
A supported, current runtime for secure APIs, background processing, performance improvements and a sustainable engineering baseline.
A maintainable, component-based web experience with server rendering where valuable, explicit API boundaries and accessible UI patterns.
Selected for its strong multilingual analysis, geographic search, relevance controls, aggregations and index lifecycle management—important for global provider discovery. Capacity can be tuned to the actual workload rather than permanently sizing for peak.
Portable container images, consistent environments and managed application operations replace a retired hosting model and manual server-style release work.
The assessment did not recommend moving every workload to the same hosting model. The target estate uses Azure managed services for predictable application operations and carefully sized IaaS for search workloads that need direct control over memory, storage and topology. This replaces permanently overprovisioned legacy roles and a search tier sized for peak traffic all year.
Docker images run on Azure App Service with autoscaling, deployment slots and managed TLS. The team pays for an appropriate baseline and scales the public search API for demand instead of operating always-on Cloud Services roles in every environment.
Elasticsearch runs on reserved, right-sized Azure virtual machines. This gives control over disk performance, memory and node placement for multilingual and geo-search indexes without buying an oversized managed search capacity. Non-production nodes are smaller and shut down outside agreed working windows.
Infrastructure-as-code applies tags, budgets and ownership. Index lifecycle policies move historical data to lower-cost storage, scheduled ingestion reduces compute waste, and monthly capacity reviews use actual query, indexing and latency data—not estimates from 2013.
| Optimisation | How it is achieved | Modelled annual reduction |
|---|---|---|
| Legacy hosting | Retire always-on Cloud Services roles; use App Service baseline, autoscaling and scheduled non-production capacity. | €72k |
| Search platform | Right-size reserved IaaS nodes, lifecycle indexes and separate production from lower-cost test capacity. | €48k |
| Operational overhead | Automated delivery, repeatable environments, monitored imports and fewer manual recovery activities. | €48k |
| Total after the transition period | €168k / year | |
In this fictional case, AI is a supervised engineering capability. It creates a measurable speed advantage, while accountable people and deterministic validation remain responsible for the released software and provider data.
The delivery plan targets a 40% faster rewrite compared with a manual-only baseline. AI analyses legacy code and database access, proposes dependency maps and API contracts, and produces first-draft technical documentation, migration tests and implementation scaffolding. Engineers review the output, verify it against the live system and retain ownership of every design and pull request.
The gain comes from reducing repetitive discovery, documentation and test-writing work—not from reducing quality gates. Architecture review, security review, acceptance tests and release approval remain mandatory.
An ingestion service uses the OpenAI API to turn unstructured supplier records into a defined schema: practice name, specialty, address components, languages, source attribution and confidence notes. Structured responses are checked against controlled vocabularies, country-specific address rules, duplicate matching and the existing provider database before a record can be published.
Low-confidence, contradictory or incomplete records go to a data-steward review queue. The model is never the final authority on a provider’s credentials, clinical information or search ranking; source provenance, deterministic rules and human approval remain auditable.
The rewrite creates the evidence and controls the legacy system lacks. Compliance is planned into data, design and operations—not added as a final audit task.
Data inventory, lawful-basis records, minimisation, retention schedules, access controls, processor agreements and documented support for data-subject requests.
Risk ownership, incident handling, supplier controls, logging and recovery testing proportionate to the organisation’s actual scope and obligations.
Accessible search flows, keyboard use, semantic markup and testable WCAG-informed acceptance criteria for the public-facing experience.
AI is used for engineering discovery with protected inputs, review gates and traceability; it does not make clinical or provider-ranking decisions without separate governance.
These services and resources cover the technical decisions illustrated in this fictional assessment.
Get evidence-led findings and a prioritised roadmap.
Modernise legacy applications on a supported .NET baseline.
Apply AI to engineering workflows with appropriate governance.
Build secure, manageable and cost-aware cloud operations.
Further reading: Modernizing legacy .NET applications.
An architecture assessment makes the support, risk, cost and migration trade-offs visible—so a rewrite is a reasoned investment, not a leap of faith.