Application Portfolio Modernization for a Federal Biomedical Research Agency

A federal biomedical research agency relied on a diverse portfolio of custom applications to support scientific, administrative, financial, and operational activities.

The environment included legacy .NET, Python, and R-based applications, multiple database technologies, integrations with other federal enterprise systems, reporting platforms, and Microsoft Power Platform solutions. The agency needed to modernize this portfolio while continuing to meet demanding federal requirements for security, accessibility, availability, privacy, and system authorization.

The modernization program is still in progress.

As the initiative evolved, the target architecture changed from the originally planned Azure-centric approach to an AWS-based modern application architecture built around:

• PostgreSQL
• Python
• GraphQL
• Apollo Federation
• Kubernetes
• React
• modern CI/CD and DevSecOps practices

At the same time, Stackular continues to support and develop solutions across the Microsoft Power Platform, including Power Apps, Power Automate, and Power BI.

The result is an ongoing transformation of a federal application portfolio toward a more modular, cloud-native, automated, secure, and maintainable architecture while operating inside the rigorous security and authorization requirements of a federal healthcare and research environment.

The Challenge

The agency's information technology organization supports a portfolio of custom applications ranging from relatively simple web solutions to complex transactional applications.

Those systems interact with numerous internal and external federal data sources and enterprise platforms. The original environment included custom .NET, Python, and R/RStudio applications as well as Oracle and SQL databases.

The organization needed to modernize the portfolio without disrupting business operations.

The challenge went well beyond rewriting old code.

The modernization needed to address:

• legacy application architectures
• multiple programming languages
• aging database platforms
• complex system integrations
• secure cloud deployment
• application security
• automated testing
• CI/CD
• accessibility
• federal security assessment
• Authority to Operate requirements
• vulnerability management
• ongoing operational support
• low-code development
• reporting and analytics

Every application also operates within a federal environment where security requirements influence architecture, development, deployment, operations, documentation, and change management.

Modernizing a Portfolio Rather Than a Single Application

A portfolio modernization program is fundamentally different from replacing one application.

Individual systems may have different:

• business purposes
• architectures
• databases
• integration requirements
• security requirements
• users
• performance characteristics
• levels of technical debt

A single migration strategy therefore does not make sense for every system.

The original modernization scope specifically called for evaluating existing applications, selecting the appropriate technology approach for each, creating detailed architecture and integration designs, and modernizing systems incrementally.

Stackular has continued that application-by-application approach as the broader technology strategy evolved.

The objective is not simply:

Move everything to the cloud.

The objective is:

Determine the appropriate modern architecture for each application while establishing common standards that make the entire portfolio easier to develop, secure, deploy, and operate.

The Architecture Evolved During the Modernization

The original modernization strategy contemplated extensive use of Microsoft Azure.

As the program progressed, the target cloud architecture changed to AWS.

This is an important aspect of large modernization programs.

Architecture decisions should respond to evolving organizational strategy rather than forcing the organization to continue with assumptions made at the beginning of a multi-year initiative.

The resulting target architecture centers on:

AWS
Cloud infrastructure and hosting environment.

Kubernetes
Container orchestration and deployment.

Python
Modern backend application development and services.

PostgreSQL
Target relational data platform for database modernization.

GraphQL with Apollo Federation
A unified API architecture across independently developed services and domains.

React
Modern component-based frontend experiences.

The modernization is being performed incrementally while existing applications continue to support agency operations.

Modern Python Application Architecture

Python is a major component of the target backend architecture.

Rather than recreating legacy applications as large monolithic systems, the modernization creates clearer boundaries between application components and business capabilities.

Python services can provide:

• business logic
• data access
• integrations
• APIs
• background processing
• domain-specific services

This architecture supports greater modularity and makes it easier for individual application capabilities to evolve independently.

GraphQL and Apollo Federation

One of the more significant architectural decisions is the adoption of GraphQL with Apollo Federation.

Large application portfolios often accumulate many APIs over time.

As applications become more modular, clients can otherwise be forced to understand which backend service owns each piece of information.

Apollo Federation provides a way to compose multiple GraphQL services into a unified API experience.

Conceptually:

Federated application architecture

A modular target architecture for the application portfolio

1. ExperienceReact applicationsReusable, component-based user experiences
2. Unified APIGraphQL + Apollo FederationOne composed schema across independently owned domains
3. Business capabilitiesPython domain servicesModular APIs and application logic

   • Domain A
   • Domain B
   • Domain C
4. Target data layerPostgreSQLModern relational persistence

• AWS + Kubernetes runtimeContainerized deployment and orchestration
• Azure DevOps + PlaywrightCI/CD, automated browser testing, and release confidence
• DevSecOps + federal controlsSecurity scanning, vulnerability management, accessibility, ATO, and compliance evidence

Individual services can maintain ownership of their domains while applications interact with a more consistent API layer.

This provides a stronger foundation for a growing application portfolio than tightly coupling every frontend directly to individual backend systems.

React Frontend Modernization

The target user experience is built around React.

A component-based frontend architecture allows teams to develop consistent, reusable interface patterns while keeping the presentation layer separate from backend services.

This supports:

• reusable components
• responsive applications
• consistent user experiences
• easier testing
• independent frontend development
• integration with GraphQL APIs

Modernizing the frontend separately from backend services also reduces the coupling that frequently makes legacy applications difficult to change.

Containerization and Kubernetes

Modernized applications are deployed using Kubernetes.

Containerization creates a more consistent deployment model across applications and environments.

Applications can package their runtime requirements together with their code instead of relying on individually configured servers.

Kubernetes then provides an orchestration layer for deploying and operating those workloads.

This supports architectural goals around:

• standardization
• scalability
• deployment consistency
• workload isolation
• resilience
• automation
• maintainability

For a federal application portfolio, repeatable infrastructure and deployment practices also support the broader objective of maintaining controlled and documented system configurations.

Database Modernization to PostgreSQL

The existing environment includes legacy Oracle and SQL-based databases.

The modernization program is progressively moving appropriate workloads toward PostgreSQL.

Database modernization includes more than changing the database engine.

Stackular's work includes considerations such as:

• schema redesign
• data migration
• application compatibility
• data integrity
• performance
• security
• integrations
• backup and recovery
• operational support

The migration is still underway, so the case study should intentionally describe PostgreSQL as the target architecture rather than claiming the portfolio migration is complete.

DevSecOps as Part of the Architecture

Security is not treated as a separate approval step after development.

The agency's requirements call for security to be embedded throughout the application lifecycle, including design, development, testing, deployment, assessment, monitoring, and remediation.

Stackular supports the full DevSecOps lifecycle, including:

• CI/CD pipelines
• automated application builds
• automated testing
• deployment automation
• code scanning
• dependency and vulnerability scanning
• secure coding practices
• security gates
• configuration management
• vulnerability remediation
• controlled deployment processes
• continuous monitoring support

This changes security from:

Build the application, then ask whether it is secure.

To:

Build security controls and validation into the process used to create every release.

Azure DevOps CI/CD Pipelines

Although the application hosting strategy evolved toward AWS, Azure DevOps remains part of the software-delivery toolchain.

Stackular uses Azure DevOps pipelines to automate development and deployment activities.

CI/CD pipelines provide repeatable processes for:

• building applications
• running automated tests
• validating changes
• performing security checks
• packaging releases
• controlling deployments

This helps reduce variation between releases and creates evidence around how software moves from source code toward production.

Automated Testing with Playwright

Automated testing is another major component of the modernization strategy.

Stackular implemented Playwright as part of the automated application testing approach and integrates automated tests into Azure DevOps pipelines.

Instead of relying exclusively on manual regression testing after development is complete, tests can run repeatedly throughout the software-delivery lifecycle.

This supports:

• regression testing
• functional validation
• UI testing
• release validation
• earlier defect detection
• CI/CD quality gates

The original contract specifically requires automated testing, CI/CD integration, performance testing, security testing, and Section 508 validation as part of the application-development lifecycle.

Federal Security Requirements

Modernizing applications for a federal agency introduces requirements that do not exist in many commercial projects.

The environment is governed by federal security and privacy frameworks including:

• FISMA
• NIST SP 800-53
• NIST Risk Management Framework
• NIST SP 800-218 Secure Software Development Framework
• HHS security requirements
• agency-specific security policies
• privacy requirements
• federal configuration standards

The environment is categorized at a Moderate impact level for confidentiality, integrity, and availability.

That means security considerations affect technical decisions throughout the lifecycle.

Authority to Operate

Applications cannot simply be developed and placed into production.

Federal information systems must operate through the agency's Security Assessment and Authorization process.

Stackular supports applications throughout that process.

Many applications within the portfolio have already been migrated and continue to operate within the agency's authorization framework, while the broader modernization remains in progress.

Rather than publish an artificial application count, the more accurate description is that Stackular supports ongoing modernization and authorization across the application portfolio.

Security Assessment and Authorization Support

Stackular actively participates in the security processes required to move and maintain systems in production.

That includes support for:

• system security documentation
• architecture documentation
• security-control evidence
• Security Assessment Plans and Reports
• independent assessments
• security interviews
• penetration-test remediation
• vulnerability remediation
• POA&M management
• contingency planning
• annual assessments
• continuous monitoring

POA&M and Vulnerability Remediation

Security findings in federal systems are not simply added to a backlog indefinitely.

Findings are formally tracked through Plans of Action and Milestones, with remediation expectations based on severity.

Stackular works with agency security teams to:

• review findings
• understand technical root causes
• develop remediation approaches
• implement fixes
• provide supporting evidence
• update documentation
• support reassessment

This makes vulnerability management an ongoing engineering responsibility rather than an occasional security exercise.

Secure Software Development

Stackular's application-development practices operate within requirements derived from:

• OWASP secure coding guidance
• NIST SP 800-218
• federal secure coding standards
• agency configuration requirements

This is incorporated into normal software engineering rather than treated as separate documentation work.

Section 508 Accessibility

Accessibility is another core requirement of the environment.

Federal applications must comply with Section 508 of the Rehabilitation Act.

Stackular performs accessibility testing and remediation as part of application delivery.

Application teams therefore need to consider accessibility throughout:

• design
• development
• automated testing
• manual validation
• defect remediation
• release acceptance

Accessibility becomes part of the product-development definition of quality rather than something evaluated only after an application is complete.

Microsoft Power Platform

The modernization program is not limited to traditional custom development.

Stackular also supports and develops applications using the Microsoft Power Platform.

This includes:

• Power Apps
• Power Automate
• Power BI

Stackular continues to build new Power Platform solutions as part of the broader application portfolio.

Choosing Low-Code or Custom Development

Not every business requirement needs a custom React, Python, and Kubernetes application.

One of the responsibilities of an application-modernization program is choosing the appropriate implementation model.

Some requirements may be better suited to:

Power Apps

for rapidly creating structured business applications.

Power Automate

for approvals, notifications, integrations, and workflow automation.

Power BI

for reporting and analytics.

Other requirements need the flexibility, scale, integration model, or user experience of a custom application.

Maintaining both capabilities allows the organization to choose technology based on the business problem rather than forcing every requirement through the same development model.

Reporting and Data Visualization

The agency's reporting portfolio includes technologies such as:

• Power BI
• Tableau
• Business Objects

Stackular's role has primarily been to support the reporting environment already in place rather than undertake a wholesale replacement of the agency's BI architecture.

That ongoing support remains part of the broader application and data portfolio.

Application Integration

Modernized applications exist within a broader government technology ecosystem.

The modernization therefore requires careful attention to:

• APIs
• identity
• network boundaries
• data formats
• security
• reliability
• dependency management

The move toward GraphQL and Apollo Federation provides a more structured API foundation for new applications while existing integrations continue operating during the transition.

Modernizing Without Stopping Operations

One of the most significant realities of portfolio modernization is that the legacy environment cannot simply be turned off while the replacement is being built.

The organization continues performing its mission throughout the transformation.

That requires Stackular to simultaneously:

• support existing applications
• remediate existing systems
• develop new capabilities
• migrate databases
• modernize application architectures
• maintain security authorization
• address production issues
• improve automation
• retire technical debt

Modernization is therefore managed as a continuous transformation rather than a single cutover event.

A Multidisciplinary Delivery Team

Stackular provides a multidisciplinary team supporting the modernization effort.

The team's responsibilities span areas including:

• application architecture
• software development
• database engineering
• DevSecOps
• automated testing
• Power Platform development
• application security
• accessibility
• production support

That breadth is important because successful modernization requires coordination across disciplines.

Changing the programming language without changing deployment, testing, security, database, and operational practices would leave much of the legacy operating model intact.

Key Technical Decisions

Why Move the Target Architecture from Azure to AWS?

Large modernization programs evolve.

The original modernization plan emphasized Azure technologies, but the agency's broader cloud strategy ultimately moved the target architecture toward AWS.

Rather than force the portfolio into the original architecture, the modernization adapted to the organization's current strategy.

The key principle is that modernization should serve the organization's long-term technology direction—not the assumptions made when the original program began.

Why PostgreSQL?

PostgreSQL provides a modern relational database platform capable of supporting a broad range of transactional application workloads.

Moving applications away from legacy database dependencies also creates opportunities to simplify licensing, deployment, development, and cloud operations.

The migration remains in progress and is being performed deliberately rather than through a single high-risk cutover.

Why Python?

Python provides a flexible application-development platform with a large ecosystem and strong support for APIs, services, automation, data processing, and future AI workloads.

It also supports the move toward smaller, modular backend services.

Why GraphQL?

Modern application experiences often require information from several backend domains.

GraphQL allows client applications to request the data they need through a structured API model without becoming tightly coupled to internal service boundaries.

Why Apollo Federation?

Federation allows individual domains to maintain independently developed GraphQL services while presenting a unified schema to application consumers.

This is especially useful in a portfolio architecture where services may evolve at different rates.

Why Kubernetes?

Kubernetes establishes a common container orchestration model across modernized applications.

This supports standardized deployment, scaling, configuration, monitoring, and operational practices.

Why React?

React provides a mature component-based architecture for modern web applications.

A shared frontend approach also makes it easier to create reusable design patterns and development practices across multiple applications.

Why Keep Azure DevOps When Hosting on AWS?

The software-development toolchain and the application-hosting platform do not need to be the same cloud.

Azure DevOps can continue to provide source-control and CI/CD capabilities while automated pipelines deploy applications into AWS environments.

This avoids unnecessary tool changes when the existing engineering platform already supports the required software-delivery lifecycle.

Why Playwright?

Modernization requires confidence that replacing application components does not unintentionally break existing functionality.

Playwright provides automated browser testing that can be incorporated directly into CI/CD pipelines, allowing critical workflows to be validated repeatedly as systems change.

Federal Modernization Is More Than Cloud Migration

This engagement demonstrates an important distinction.

Moving an application from a government data center into a cloud environment does not necessarily make it modern.

Modernization also requires reconsidering:

• application architecture
• APIs
• database platforms
• deployment
• automated testing
• security
• observability
• accessibility
• development practices
• maintenance

The modernization program therefore combines technology migration with changes to how software itself is designed, delivered, secured, tested, and operated.

Business and Mission Results

Because the portfolio modernization is ongoing and the agency has not published quantitative outcome metrics that Stackular can cite, this case study should not invent performance or cost savings.

The strongest outcomes are currently architectural and operational.

Ongoing Modernization of a Mission-Critical Federal Portfolio

Applications are progressively moving from legacy architectures toward modern cloud-native technologies while remaining operational throughout the transition.

Modern Application Architecture

The target architecture establishes reusable standards around:

• React
• Python
• PostgreSQL
• GraphQL
• Apollo Federation
• Kubernetes
• AWS

Integrated DevSecOps

Security testing, automated testing, vulnerability management, and controlled deployment are incorporated into the development lifecycle.

Automated Quality Engineering

Playwright and Azure DevOps pipelines provide repeatable automated validation throughout development and release processes.

Federal Security Compliance

Stackular supports applications through ongoing federal security assessments, authorization activities, documentation, POA&M remediation, vulnerability remediation, and continuous monitoring.

Accessible Federal Applications

Section 508 accessibility testing and remediation are integrated into application delivery.

Database Modernization

Legacy databases are progressively being migrated toward PostgreSQL as part of the broader application transformation.

Low-Code and Custom Development

Power Platform provides a complementary development model alongside custom cloud-native applications.

Continuous Mission Support

The organization can continue using critical applications while modernization occurs incrementally rather than requiring a disruptive portfolio-wide replacement.

Technologies Used

• Amazon Web Services
• Kubernetes
• PostgreSQL
• Python
• GraphQL
• Apollo Federation
• React
• Microsoft Power Platform
• Power Apps
• Power Automate
• Power BI
• Azure DevOps
• Playwright
• CI/CD
• DevSecOps
• Automated Testing
• Infrastructure as Code
• Automated Security Scanning
• Dependency Scanning
• Vulnerability Management
• NIST SP 800-53
• NIST SP 800-218
• FISMA
• Authority to Operate
• POA&M Remediation
• Section 508 Accessibility

Lessons for Federal Application Modernization

Treat Portfolio Modernization as a Program, Not a Migration Event

Large portfolios cannot usually be replaced simultaneously.

Organizations need an architecture and delivery model that allows old and new systems to coexist while transformation occurs incrementally.

Allow the Target Architecture to Evolve

A multi-year modernization program should not blindly preserve technical decisions made at its beginning.

Cloud strategies, organizational priorities, and technology capabilities change.

Architecture governance needs to accommodate those changes without losing consistency.

Standardize Patterns Without Forcing Every Application to Be Identical

Common technologies and engineering practices create efficiency.

But individual systems may still have different requirements.

The goal should be standardized architectural patterns—not one architecture mechanically applied to every workload.

Build Security into the Delivery Pipeline

Federal security requirements should not appear for the first time immediately before production.

Secure coding, vulnerability scanning, dependency review, automated testing, configuration management, and documentation should be part of normal development.

Treat ATO as an Engineering Requirement

Authority to Operate is not simply paperwork owned by a security team.

Architecture choices, software dependencies, configurations, testing, documentation, and vulnerability remediation all contribute to whether a system can receive and maintain authorization.

Engineering teams must participate directly.

Automate Regression Testing During Modernization

Modernization changes many layers simultaneously.

Automated testing provides confidence that changing infrastructure or architecture has not unintentionally changed business functionality.

Accessibility Belongs in the SDLC

Section 508 issues are much easier to address when accessibility is considered during design and development rather than treated as a final compliance exercise.

Use Low-Code Where It Makes Sense

Not every requirement needs Kubernetes and custom application development.

Power Platform can deliver significant value for appropriate workflows while custom development remains available for requirements that need greater flexibility.

Separate the Development Toolchain from the Hosting Platform

Moving workloads between clouds does not necessarily require replacing every engineering tool.

Keeping effective tools while changing the runtime platform can reduce disruption and allow modernization teams to focus on business applications.

Modernization Should Improve the Operating Model

Changing technology without improving:

• testing
• security
• deployment
• monitoring
• architecture
• documentation

leaves much of the legacy problem intact.

A successful modernization changes both the applications and the way the organization delivers software.

Frequently Asked Questions