How We Completed a Stalled Federal Grant Platform Modernization and Secured ATO on AWS GovCloud

The situation

The platform was the federal agency's system of record for managing the full grant lifecycle. Through it, federal staff tracked program milestones, ran quarterly grantee audits and assessments with supporting evidence, and managed budget allocation, approval, and spend review against awarded funds. By the time we were brought in, the system was already in production, but the modernization around it had stopped.

A succession of prior development efforts had each touched a partial migration off ASP.NET WebForms toward AWS. None had finished. The codebase carried inconsistent patterns, an unclear roadmap, and a backlog of unresolved defects. Forward progress had effectively halted.

The platform worked. The transformation around it had stopped transforming.

That is the brief that lands on a federal program manager's desk when the timeline is slipping, the inherited code is no one's favorite, and the next quarterly audit is already on the calendar.

The challenge

Six problems had to be solved in parallel, not in sequence:

1. Stabilize an inherited codebase with multiple partial migrations and no single architectural authority.
2. Establish a technical roadmap that prior teams had never produced, and align the agency to it.
3. Resolve technical debt and the defect backlog that had eroded confidence in the program.
4. Finish the modernization workstreams, including grantee audit and assessment, federal staff budgeting, and lifecycle milestone tracking.
5. Stand up real release and deployment processes where none had existed before.
6. Achieve Authority to Operate for production federal use of a financial management system on AWS GovCloud.

The approach

The operating model

Before any code changed, we set the cadence. We took on full architectural ownership of the platform, established a single technical roadmap, and put a small senior team on the engagement across .NET engineering, cloud infrastructure, and security. Governance was simple and traceable: a single roadmap, a single backlog, a single release pipeline, and direct stakeholder visibility into each call as it was made.

Early in the engagement, the priority was stabilization, not feature work. Resolving inherited defects and aligning the migration target came first, because trust had to be rebuilt before scope could expand.

Stabilization is a feature. You cannot ship audit and budgeting workflows on a foundation that nobody trusts.

The technical architecture

We targeted modern .NET, specifically .NET 6/8 with ASP.NET Core MVC, as the destination for the WebForms code prior teams had only partially carried over. Where existing migrations had diverged across modules, we converged them on a single application architecture, shared cross-cutting concerns (authentication, authorization, logging, configuration), and a common data access pattern against the SQL backend.

Three workstreams ran in parallel inside that architecture:

• Grantee audit and assessment. Quarterly review workflows with structured evidence attachment, federal-side review, and a full audit trail.
• Federal staff budgeting. Allocation, approval, and spend review against awarded grants, with the segregation of duties and approval thresholds the program required.
• Lifecycle milestone tracking. The connective tissue tying awards, grantees, audits, and budgets together across the full lifecycle.

Cloud and infrastructure on GovCloud

The platform runs in AWS GovCloud (US). EC2 hosts the application tier; managed SQL (Amazon RDS for SQL Server) backs the data layer. The surrounding posture is what a federal financial system in GovCloud is expected to look like: VPC and subnet segmentation with restrictive security groups, an application load balancer fronting the tier, S3 for artifact and evidence storage, CloudWatch for centralized logging and monitoring, IAM for least-privilege access, and KMS for key management on data at rest.

This was deliberately a conventional GovCloud architecture. For an ATO target, conventional is a feature: every piece of the surface area maps cleanly to a documented control.

Release and deployment

When we arrived, there was no release process to speak of. We established CI/CD on Bitbucket Pipelines, with environment promotion from development through test to production, automated build and deploy steps, and gated approvals where compliance required them. Release artifacts became reproducible, deployments became routine, and the path from a merged change to a production release became something the agency could actually plan around.

Continuous delivery is a compliance posture as much as it is an engineering practice. Repeatable, auditable releases are what make controls hold under review.

ATO partnership

Authority to Operate, on AWS GovCloud, for a federal financial management system, is the part of this engagement that is hardest to fake and most expensive to underestimate. We treated it as a partnership with the agency's security organization, not a deliverable to be handed over at the end.

The work spanned three threads. The first was technical: implementing and evidencing the security controls required under FISMA Moderate and NIST 800-53, hardening the GovCloud posture, and ensuring that logging, access management, encryption, and configuration management produced the artifacts assessors actually look for. The second was documentation: producing the System Security Plan and supporting artifacts to the standard a federal financial system requires, and keeping them in lockstep with the running configuration as it evolved. The third was procedural: walking the system through the agency's assessment and authorization process alongside its security organization, answering findings, closing gaps, and bringing the program to sign-off.

The result was a production ATO on GovCloud for a system that, by virtue of the dollars flowing through it, was always going to be examined closely.

The outcome

What we delivered, and what changed because of it:

• $800M to $900M in federal grants administered annually through the platform, post modernization.
• Authority to Operate achieved for production federal use on AWS GovCloud, under FISMA Moderate (NIST 800-53).
• A stalled multi-vendor migration was completed and stabilized on a single, modern .NET architecture.
• Grantee quarterly audit and assessment workflows shipped, including evidence submission and federal review.
• Federal staff budgeting workflows went live, covering allocation, approval, and spend review against awarded grants.
• Lifecycle milestone tracking was completed, tying awards, grantees, audits, and budgets together end to end.
• CI/CD and deployment processes were established where none had previously existed, on Bitbucket Pipelines with environment promotion and gated approvals.
• The inherited defect backlog was resolved, restoring confidence in the program.

The program was delivered and handed off. The platform continues to administer roughly $850M in annual federal grant disbursements on the architecture and ATO posture put in place during the engagement.

Estimated ROI

Industry-comparable benchmarks for federal grant platform modernizations at this scale, paired with an ATO on GovCloud, point to $3M to $6M in annual operational savings, driven by faster audit cycles, reduced manual oversight, and lower hosting and maintenance burden. The figure is benchmark-derived rather than engagement-measured. The compliance and audit risk reduction on roughly $850M in annual grant disbursements is the larger, harder-to-monetize benefit.

What we took from it

Five lessons that apply well beyond this program:

1. Rescue work is a stabilization problem before it is a feature problem. When you inherit a stalled modernization, the first deliverable is a credible roadmap and a clean release pipeline. Feature velocity is downstream of both.
2. A single architectural authority is not optional on a multi-vendor inheritance. Without it, partial migrations stay partial.
3. For an ATO target, boring infrastructure is the right infrastructure. Conventional, well-documented services map cleanly to controls. Novelty costs you in evidence.
4. Treat ATO as a partnership, not a checkpoint. Implementing controls, producing evidence, and closing assessor findings is engineering work, security work, and program work simultaneously. Staff it that way from the start.
5. CI/CD is a compliance lever. Repeatable, auditable builds and deploys make controls evidenceable, and they make the program something federal stakeholders can plan around.