Modernizing public health systems without breaking the mission

There is a particular kind of technical debt that accumulates in public health and federally-affiliated platforms: the kind that forms slowly, in full view, while everyone is occupied keeping the system running.

The platform works. Data moves. Surveillance workflows execute. Reports reach the people who need them. The mission is being served, and that operational continuity is both real and genuinely important. What is also real is the gap between what the system currently is and what it needs to be to remain maintainable, secure, and extensible over the next several years.

This working paper is drawn from a direct engagement with a federally-affiliated public health surveillance platform that had reached exactly that inflection point. The codebase was long-lived. The team was capable. The operational constraints were real. And the accumulated debt — across eight measurable dimensions — had reached a level where the question was no longer whether to modernize, but how to do it without breaking the mission in the process.

Most software modernization discourse assumes a set of constraints that do not apply in public health and regulated government environments. The assumption is that you can take something offline, run a parallel system during a transition, absorb a period of reduced velocity while the new architecture stabilizes, or accept some operational disruption in exchange for a better technical foundation.

Public health surveillance platforms do not have this latitude. Seasonal surveillance cycles create hard operational windows. Influenza data, respiratory illness tracking, and similar reporting workflows are time-sensitive by nature — a deployment that introduces instability during peak reporting season is not a technical inconvenience. It is a public health risk.

Beyond the operational calendar, there are compliance and documentation requirements that constrain how change can be introduced. Changes to systems handling sensitive health data require audit trails, validation procedures, and sometimes formal review before they can be promoted to production. These requirements are not bureaucratic friction. They exist for reasons that people responsible for public health data understand well.

Finally, teams operating in these environments are frequently constrained in ways that do not apply elsewhere. Staffing levels reflect government procurement realities, not technology industry norms. Vendor relationships introduce their own timelines. Contractors cycle in and out. The institutional knowledge that keeps a long-lived system running is distributed across a team that is always smaller than it looks on paper.

A modernization strategy that ignores these constraints is not a strategy. It is a plan for a different organization operating a different system under different conditions.

The most common error in legacy system modernization is treating framework upgrades as the primary objective. Upgrade Django from 3.x to 5.x. Move from Create React App to a modern build toolchain. Pin dependencies to current versions. These are real tasks, and they matter — but they do not, by themselves, constitute modernization in any meaningful sense.

What they do is update version numbers while leaving the underlying architectural problems in place. A 337-line monolithic settings file managing multiple environments through branching conditional logic remains exactly as fragile after a Django version upgrade as it was before. Authentication patterns that have drifted from current security standards are not corrected by a framework bump. A test suite composed almost entirely of HTTP response-code smoke tests does not become a meaningful regression safety net because the framework behind it changed.

The framework upgrade is a necessary component of modernization — you cannot skip it. But it is entry-level work. The substantive modernization happens at the architectural and operational layer: how concerns are separated, how configuration is managed, how security posture is maintained systematically rather than reactively, how deployments are validated before they reach production. Those are the changes that determine whether a system becomes genuinely more maintainable or simply more current.

One of the most practically useful things a modernization assessment can produce is an honest accounting of the full scope of accumulated debt. In the engagement this paper draws from, that accounting covered eight distinct dimensions. Each is worth describing, because the interaction between them is where sequencing decisions have to be made.

Dependency health is the most immediately tangible. Long-lived systems accumulate pinned dependencies with documented security vulnerabilities — not because teams are negligent, but because upgrading a dependency that other components depend on carries real risk when test coverage is insufficient to validate the change safely. The dependency problem and the testing problem are connected.

Security posture is rarely a single finding. In practice it is a cluster: authentication configuration that has drifted from current standards, session and cookie security settings that were introduced and then disabled without removal, API access control patterns that evolved organically rather than being designed to a defined standard. No single item in this cluster is necessarily dramatic. Together they represent a security posture that has not been systematically reviewed against the standard the platform currently needs to meet.

Configuration sprawl is almost universal in long-lived systems. A monolithic settings file that manages all environments through branching conditional logic is harder to understand than a settings architecture that is explicitly organized by environment and concern. Five Docker Compose files maintaining different deployment targets independently, with substantial duplication, means that understanding what any given deployment actually does requires reading through multiple files simultaneously.

Testing gaps in these systems are also structural, not just quantitative. The issue is not simply that coverage numbers are low. It is that the test suite provides false confidence: a test that verifies an endpoint returns HTTP 200 does not tell you whether it returned the correct data, whether it behaved correctly under varied inputs, or whether it would degrade gracefully under error conditions. False confidence in testing is worse than acknowledged absence of testing, because it discourages the investment needed to build real coverage.

CI/CD maturity in government-adjacent systems often reflects procurement constraints as much as technical choices. When the only automated workflow in a repository is a dependency review scan, and there is no automated test gate, no linting, no type-checking pipeline, and no build validation on pull requests, every change merges and deploys without automated validation of any kind. In a system with compliance obligations and operational dependencies, this is a material risk surface.

Frontend architecture accumulates debt differently than backend systems, but it accumulates it reliably. In the engagement this paper addresses, the frontend carried a Section 508 accessibility compliance gap in datatable implementations — a concrete regulatory risk for a federally-affiliated platform — alongside the absence of TypeScript and a heavily customized Webpack configuration with fifteen build-specific development dependencies. These were not cosmetic issues. The 508 compliance gap required remediation. The TypeScript absence created a maintenance overhead that compounded with every new component. The Webpack configuration made routine frontend development slower than it should have been.

The application server strategy, in many long-lived systems, has simply not been revisited since early in the platform's operational history. A WSGI server configuration that worked well under original load profiles and deployment patterns may carry fragilities that compound as the platform changes — particularly if the server requires custom patching to function correctly, which creates its own compounding fragility as the base image evolves.

Infrastructure redundancy covers the operational visibility and resilience characteristics that determine how well a system supports incident response. Health checks that return HTTP 200 without validating downstream service availability, logging that is file-based without structured output suitable for ingestion into a log management system, and no integration with centralized alerting — these characteristics mean that when something goes wrong in production, the response begins with manual log file inspection rather than structured query and alerting.

One of the most practically useful tools for communicating a multi-dimensional assessment to engineering directors and program owners is a two-axis matrix that plots each assessment dimension by risk severity against remediation effort. This is not a novel framework — it is a standard prioritization tool — but it is particularly valuable in modernization contexts because it separates the urgent from the hard.

The four quadrants produce four distinct recommendations. The high-severity, low-effort quadrant deserves immediate attention: these are the items that carry real risk and can be addressed quickly. In the engagement this paper draws from, enabling session and CSRF cookie security flags that were present in configuration but commented out is a clear example — the fix is a configuration change, and the risk of leaving it as-is is real.

The high-severity, high-effort quadrant requires planned investment. Replacing a patched application server, decomposing a monolithic settings architecture, or building meaningful test coverage from a sparse baseline all belong here. The risk is real, but the work is substantial. These items need to be sequenced into a roadmap with realistic effort estimates, not addressed reactively.

The medium-severity, low-effort quadrant can often be folded into adjacent work. Infrastructure health check improvements, structured logging configuration, and other lower-risk operational improvements typically do not require a dedicated project — they can be incorporated into other tracked work without disrupting the sequence.

The medium-severity, high-effort quadrant is where strategic frontend and architectural work belongs. TypeScript migration, build toolchain replacement, and component architecture improvement are legitimately high-effort. Their immediate risk profile is lower. They should be scheduled after the foundation is stable enough to support them without adding risk to an already constrained improvement capacity.

The failure mode that Protabyte observes most consistently in public sector and regulated-environment modernization programs is good analysis followed by poor sequencing. The assessment is accurate. The list of things that need to be addressed is correct. The organization then attempts to address them in parallel, or in an order that creates compounding risk rather than reducing it, and the program stalls.

Sequencing in modernization is not primarily about project management. It is about managing dependency chains. Some improvements are prerequisites for others. Attempting them in the wrong order means doing work twice, or introducing instability that the downstream work then has to account for.

Security posture and dependency remediation belong at the front of any modernization sequence. Not because they are the most visible or the most technically interesting, but because they carry the most concrete and immediate risk. A platform with active authentication gaps and pinned dependencies carrying documented CVEs is accumulating liability with every week that passes. Those items need to be addressed before the team invests significant time in improvements that provide less immediate risk reduction.

CI/CD automation is a prerequisite for almost everything else. It is not useful to build meaningful test coverage before there is an automated test execution gate in the deployment pipeline. It is not useful to introduce TypeScript before there is a type-checking step in CI. It is not useful to decompose settings architecture before there is an automated environment validation step that catches configuration errors before they reach production. The CI/CD foundation does not have to be perfect before other work begins — it has to be functional. But it has to be functional earlier in the sequence than many roadmaps place it.

Testing strategy also has its own internal sequence. The first priority is not comprehensive coverage — it is coverage of the paths that carry the greatest operational consequence if failures are introduced. In a surveillance platform with seasonal workflows, the paths that matter most are the ones that handle data ingestion, transformation, and reporting for the peak reporting periods. Those paths need regression coverage before any change touches them.

A phased roadmap for this type of engagement should be organized into three broad stages, each with a clear entry criterion and a defined deliverable that the next phase depends on.

The first stage addresses security posture and foundational stability. Its job is to reduce the immediate risk surface without requiring the kind of broad codebase changes that depend on a test safety net that does not yet exist. Authentication configuration, security flag remediation, and the highest-severity dependency upgrades belong in this stage. So does the CI/CD foundation — not the full build pipeline, but the automated test execution gate and linting that makes further work safer.

The second stage addresses structural platform improvements. With a baseline of CI/CD automation in place, this stage can tackle dependency stabilization broadly, settings architecture decomposition, application server strategy, and the beginning of systematic test coverage expansion starting from the highest-risk paths. These are the improvements that make the platform structurally safer to change — not just currently better, but genuinely more maintainable going forward.

The third stage addresses frontend modernization and longer-term architectural work. It depends on the second stage having established a foundation that can absorb change without adding operational risk. TypeScript migration, build toolchain resolution, component architecture improvements, and net-new feature development built on the modernized frontend foundation all belong here. When this stage is reached, the team is working in an environment with meaningful test coverage, functional CI/CD, and a security posture that has been systematically reviewed. Frontend work in that environment feels different than frontend work in a system carrying all of those outstanding concerns simultaneously.

The bar width in a phased roadmap visualization should represent relative effort — not calendar time, which depends on team capacity — so that readers can understand the investment profile of each phase without anchoring on dates that will inevitably shift.

The frontend track in the engagement this paper draws from illustrates a pattern that appears frequently in government and federally-affiliated systems. Accessibility compliance — specifically Section 508 — creates a non-negotiable remediation requirement. The datatable implementations on the platform did not meet 508 standards. That is not a suggestion or a best practice recommendation. It is a compliance gap that has to be closed.

What is interesting about that entry point is what it enables. Addressing 508 compliance in aging datatable components requires introducing modern React patterns. Introducing modern React patterns is more maintainable with TypeScript. TypeScript migration surfaces places where the Webpack configuration is creating friction. Resolving the Webpack configuration simplifies the build pipeline. A simplified build pipeline reduces the overhead of adding new features to the frontend.

None of those subsequent improvements were the original objective. The original objective was 508 compliance. But a well-sequenced frontend modernization track can carry all of them in one sustained effort, because each step creates the conditions for the next one to be easier. The engagement did exactly this: TypeScript was introduced, the aging datatables were replaced with accessible implementations, and the frontend scope then expanded to include Advanced Search functionality and task assignment workflows — features the platform needed, now deliverable on a foundation that could support them.

The lesson is not that 508 compliance is a trick for getting frontend modernization funded. The lesson is that entry points matter. A modernization track that begins with a concrete compliance requirement has a clearer mandate, clearer success criteria, and clearer stakeholder support than a track that begins with an abstract recommendation to modernize the frontend.

Technical roadmaps for modernization are necessary. They are not sufficient. The programs that fail — and there are many — tend to fail not because the technical analysis was wrong but because the operational layer was not planned alongside the technical one.

The operational layer covers the human and process side of the change: who deploys changes and how, what the runbook looks like for each phase of the roadmap, how compliance documentation requirements are satisfied for each change category, what the validation procedure is before a change is promoted to production, and what the rollback path looks like if something goes wrong during promotion.

In regulated environments, the absence of clear answers to these questions is not a planning gap that can be resolved later. Compliance with federal guidelines may require documented validation procedures for changes to systems handling protected health data. If those procedures are not defined before the change is made, the change may need to be rolled back or re-validated after the fact — which is more expensive and more disruptive than defining the procedures in advance.

Key-person dependency is another operational-layer failure mode. Many long-lived government systems survive on the institutional knowledge of one or two individuals who know how the system actually behaves, how the deployment actually works, and where the undocumented exceptions to the design actually live. A modernization program that does not explicitly surface and redistribute this knowledge creates a situation where a personnel change can halt the improvement effort entirely.

Stakeholder communication is the third dimension. The connection between a technical finding — "the test suite provides no behavioral coverage" — and its operational consequence — "we cannot safely make changes to the reporting workflow without risking an undetected regression" — is not obvious to non-technical stakeholders. Making those connections explicit, in language that operations and program leadership can act on, is part of the engagement. Programs that treat technical findings as self-explanatory tend to lose stakeholder support at the moment when it is most needed: when the first phase of improvement work is slower than everyone hoped and the second phase looks expensive and complicated.

A maturity assessment that scores each of the eight dimensions on a current-state and target-state basis, displayed as a radar or spider chart, gives engineering directors and program owners a fast way to understand where investment is most needed and how far each area needs to travel.

The dimensions map directly to the categories discussed in this paper: security posture, dependency health, configuration management, test coverage, CI/CD maturity, frontend architecture, application server strategy, and infrastructure redundancy. Each is scored on a simple five-point scale. Current state is derived from direct assessment findings. Target state reflects the standard appropriate to the platform's operational context and compliance obligations — not a theoretical ideal, but a realistic designation for the kind of platform this is and the obligations it carries.

The gap between current and target on each dimension tells a different story than a list of findings. A dimension with a large gap and a current-state score of one requires more investment than a dimension with a moderate gap and a current-state score of three. When gaps are plotted visually, the priorities become intuitive rather than requiring interpretation.

This visualization is particularly useful in stakeholder conversations because it separates the assessment (this is where we are) from the roadmap (this is where we are going) from the investment argument (this is how we get from one to the other). Those three conversations are related but distinct, and conflating them tends to produce confusion rather than clarity.

One of the most important things a modernization assessment needs to communicate — and one of the things that is most difficult to convey to non-technical stakeholders — is that the eight dimensions are not independent. The decisions made in one area constrain and enable the decisions available in others.

Dependency health and testing coverage are interdependent. Upgrading a pinned dependency that other components rely on is not safe without test coverage sufficient to validate that the upstream change has not altered behavior in ways the system does not expect. Building that test coverage before attempting dependency upgrades is the correct sequence. Attempting the dependency upgrades without the coverage means either accepting unvalidated risk or doing the coverage-building twice — once before to make the upgrade safe, and once after to account for the behavior changes the upgrade may have introduced.

CI/CD maturity and test coverage are interdependent. A test suite that is not connected to the CI pipeline provides no protection against regressions introduced in the normal development workflow. Many teams have test suites that run manually, infrequently, and only on the full system — which means that individual changes are never validated by the tests before being merged. The value of a test suite is proportional to how consistently it runs. A limited suite connected to CI is more valuable than a comprehensive suite that runs only when someone remembers to run it.

Security posture and configuration management are interdependent. Security settings that are present in configuration but disabled are more dangerous than settings that are absent entirely, because they create false confidence. A reviewer who sees session cookie security flags in the configuration file concludes that they are enabled. If they are commented out, that conclusion is wrong — and the wrong conclusion is worse than no conclusion at all. Configuration architecture that is difficult to read and reason about creates conditions where security settings are misunderstood, misapplied, or disabled without the omission being visible.

Frontend modernization and CI/CD maturity are interdependent in the specific context of TypeScript. Introducing TypeScript to a frontend layer is not just a change to the source files — it is the introduction of a type-checking step that needs to be enforced at the CI level to be meaningful. TypeScript without a CI type-check gate provides type safety only for developers who choose to run the type-checker locally. The value of the TypeScript investment is fully realized only when the CI pipeline validates it on every pull request.

A modernization assessment is not an audit and it is not a roadmap handed down from outside the team. It is a structured technical engagement that produces a prioritized, sequenced plan grounded in what the system actually contains, what the team actually has capacity to execute, and what the operational constraints actually require.

The starting point is direct examination of the codebase across the eight dimensions. Not a survey. Not a checklist. Direct examination of what the settings architecture actually looks like, what the test suite actually covers, what the CI pipeline actually validates, what the dependency list actually carries. AI-assisted analysis can substantially compress the time required to do this work across a large, long-lived codebase — surfacing structural patterns, dependency relationships, and risk concentrations that would take weeks to map manually. The analysis remains human-led. The judgment about what matters and how to sequence it is not delegable to tooling.

The output is a phased roadmap with clear sequencing rationale, explicit entry criteria for each phase, and effort estimates calibrated to the team's actual capacity. It accounts for operational constraints — cannot disrupt the system during peak reporting periods, changes to regulated components require documented validation procedures — rather than ignoring them in the interest of a cleaner plan.

Equally important is what the engagement communicates to stakeholders who are not in the codebase every day: a clear account of where risk is concentrated, why the sequence is what it is, and what the platform will be in a position to do at the conclusion of each phase that it cannot do now.

The public health surveillance platform that this paper draws from completed its assessment engagement in the summer of 2025. The team left with a three-stage roadmap, a clear understanding of which items required immediate attention and which were safely sequenced later, and a shared documentation of the risk concentrations that had previously been held in individual institutional knowledge rather than in any formal record.

The frontend track, which began as a 508 compliance remediation, became a delivery track for Advanced Search functionality and task assignment workflows — features the platform needed that were now buildable on a TypeScript and React foundation that the compliance work had established. The Django security work addressed authentication configuration, session security settings, and API access control patterns as a cluster rather than treating any single item as the primary concern. The Webpack configuration, which had been a persistent friction point, was resolved as part of the frontend modernization track.

None of this required a rewrite. It required a credible, prioritized, sequenced plan for improvement — one that worked within the team's capacity, respected the operational constraints of a mission-critical regulatory environment, and addressed risk in the order that risk actually demanded.

That is what responsible modernization in public health and regulated government environments looks like. Not a transformation mandate, but a realistic improvement cadence that leaves the system genuinely better, safer, and more maintainable at each stage of the sequence.