Modernization Assessment and Roadmap for a Public Health Surveillance Platform

The challenge

The platform had reached an inflection point common to systems that have served a critical function for years while evolving under significant operational and resource constraints. The core functionality was sound. Seasonal data moved. Surveillance workflows executed. The public health mission was being met. But the engineering foundation beneath that functionality had drifted from the standard that a maintainable, extensible, and security-conscious platform requires — and the gap was widening with each passing season.

Several specific areas of concern shaped the assessment scope from the outset.

Settings and configuration architecture had accumulated complexity across environments. Django's settings system had grown to reflect years of incremental change, with environment-specific logic, embedded secrets handling, and configuration values that no single contributor fully understood. Onboarding new engineers or deploying to new environments required institutional knowledge that wasn't documented anywhere.

Security posture had not been systematically reviewed. Dependencies carried known vulnerabilities that had gone unaddressed due to the risk of uncontrolled upgrades. Authentication patterns, data access controls, and the handling of sensitive public health data had evolved organically rather than being designed to meet an explicit security standard. No dependency audit cadence existed.

CI/CD maturity was limited. Builds were not fully automated, test execution was manual in key areas, and deployment required steps that were undocumented or performed by specific individuals. The risk surface for human error in the deployment process was elevated.

Testing coverage was sparse. Unit test gaps were present throughout the codebase, integration testing was largely absent, and no systematic regression coverage existed for the seasonal workflow paths that carried the highest operational risk. Changes to core logic required developers to hold institutional knowledge rather than relying on a test suite to validate behavior.

The application server and runtime strategy had not been revisited since early in the platform's lifecycle. Gunicorn configuration, worker settings, and the approach to serving the Django application had not been reassessed against current load profiles, containerization practices, or infrastructure direction.

The frontend layer carried meaningful accessibility and maintainability debt with direct compliance consequences. The existing datatable implementations did not meet Section 508 requirements — a concrete risk for a federally-affiliated platform. TypeScript was absent entirely from the frontend layer, and the build pipeline relied on a heavily customized Webpack configuration that had grown difficult to maintain. These gaps were addressed during the engagement: TypeScript and modern React patterns were introduced to replace the aging datatables and close the 508 compliance gap, and the scope expanded from there into new feature delivery — Advanced Search functionality, task assignment workflows, and additional capability surfaces the platform needed. The Webpack configuration was assessed and resolved as part of this track.

Underlying all of this was the organizational reality: the platform was operated by a team with real capacity constraints working in a regulated, mission-critical environment where risk tolerance for disruption was low. A rewrite was not the answer. A credible, prioritized, and sequenced plan for improvement was.

System realities and risk areas

Protabyte's assessment identified risk across eight distinct dimensions. The dimensions were not equally urgent — and recognizing that distinction is what makes a sequenced roadmap possible rather than an undifferentiated list of things to fix.

Assessment approach

Protabyte approached the engagement as a structured technical assessment, not a consulting review. The goal was to produce a concrete modernization roadmap grounded in what the codebase actually contained, not what a generic assessment framework assumed it might.

The assessment proceeded across eight dimensions, each evaluated for current state, risk level, and improvement feasibility given the team's capacity and the platform's operational constraints.

Where AI fit in

Public health surveillance platforms are exactly the kind of system where AI-assisted analysis earns its keep. The codebase was large, mixed-stack, and had evolved over several years under real delivery pressure. Settings logic was distributed across multiple files that had diverged from each other. Dependencies had accumulated over time without consistent management. Authentication and security patterns were present in some places and missing in others. The e2e test suite ran in one context; the unit tests barely existed. Understanding where any of this actually stood — across all eight assessment dimensions simultaneously — was a significant surface area problem before it was a judgment problem.

AI tooling was used to compress the archaeology phase of the engagement. Tasks that would have taken days of manual tracing — mapping every place a configuration value was read, identifying all endpoints sharing a particular authentication pattern, surfacing the full dependency graph for a given processing function, auditing comment-to-code consistency across the settings files — were completed in a fraction of the time. This let the engineering work shift quickly from discovery to analysis: from “what is here” to “what does this mean and what should be done about it.”

AI also played a meaningful role in the documentation layer. Turning a set of technical findings spread across three people's notes, multiple file reviews, and a week of codebase examination into a structured requirements specification that both engineers and program leadership could act on is genuinely difficult work. AI-assisted drafting substantially compressed the time between raw findings and polished deliverable — producing the first version of the risk categorization, the phased roadmap structure, and the requirements specification in a form that engineers could then review, correct, and finalize rather than write from scratch.

What AI did not do is provide the engineering judgment the engagement required. Deciding that the CI/CD foundation needed to precede the test coverage investment — because tests without a CI gate provide false confidence rather than real safety — is a sequencing call that requires understanding how these systems interact in practice. Recognizing that the commented-out security flags were more dangerous than fully absent ones, because they created false confidence in anyone reading the configuration, requires knowing what false confidence costs in a regulated environment. Calibrating the phased roadmap to what the team could realistically execute given its operational obligations is an organizational judgment that no tool can make.

Lessons for public sector and regulated organizations

Public sector and government-adjacent platforms carry a particular kind of technical debt: the kind that accumulates in systems that are too important to rebuild and too constrained to keep up with the pace of industry practice. The platform keeps running. The mission keeps being served. And underneath, the gap between what the system requires to be maintained safely and what the engineering foundation actually provides continues to grow.

The organizations that serve these platforms are often fully aware of the problem. They know the dependencies are out of date. They know the deployment process has undocumented steps. They know the test coverage is insufficient for the confidence they need to make changes without risk. What they lack is not awareness — it's a credible, prioritized path forward that respects the system they actually have, the team capacity they actually possess, and the risk tolerance that serving a mission-critical public function actually requires.

This is where the rewrite reflex does the most damage. When a long-lived system reaches an inflection point, the default recommendation from many consultants is some version of "start over." It's analytically defensible in the abstract, and completely disconnected from organizational reality. A rewrite requires sustained investment the organization may not have. It requires migrating a running system without disrupting the operational workflows that depend on it. It introduces a multi-year period during which both systems must be maintained. And it discards the institutional knowledge embedded in a codebase that has been serving a real function for years.

The more valuable answer — and the harder one to produce — is a credible modernization roadmap that works within constraints rather than pretending they don't exist. One that distinguishes between debt that carries immediate risk and debt that can be safely sequenced later. One that gives a team a realistic improvement cadence rather than a transformation mandate. One that makes the system incrementally better, safer, and more maintainable without requiring a bet-the-organization investment to execute.

AI-assisted analysis changed what's possible in this kind of engagement. The archaeology of a large, long-lived codebase — understanding what the code actually does, mapping structural relationships, surfacing risk concentrations, identifying dependency chains — has historically been the slow, expensive part of any modernization assessment. Applied thoughtfully, AI tooling compresses that timeline significantly, allowing an assessment engagement to go deeper in less time, and to produce recommendations grounded in specific code realities rather than general pattern-matching.