Your program just accepted delivery of a new system. The vendor built it, hardened it, got it through the authorization gate. The AO signed. Mission accomplished.
Then the IT organization that operates the accredited environment where the system now lives discovers what just landed on them.
The system runs on three hardened container images that need patching when upstream CVEs emerge. It includes a containerized PostgreSQL instance that needs persistent storage, backup automation, upgrade migration handling, and monitoring. Its service mesh configuration affects the existing platform and other tenants. Its health endpoints exist but the monitoring stack — Prometheus, Grafana, alert rules — needs configuration by an IT team that's never seen the system. Its persistent volumes and log storage consume cluster resources that weren't in the capacity plan.
This cost wasn't in anyone's estimate — not because anyone overlooked it, but because it falls in the gap between the vendor's scope, the program's scope, and the IT organization's planning cycle. It's one of the most predictable costs in fielding a new system, and one of the least visible before delivery.
I've been on both sides of this. As Division Chief at the Space Warfighting Analysis Center, I received systems into accredited environments and experienced the integration work firsthand. Now I deploy commercial products into hardened enclaves and scope this cost specifically — because knowing it early changes the conversation for everyone involved.
Why integration costs don't get estimated
Three structural reasons, and none of them are anyone's fault:
The vendor's scope ends at delivery. The contract covers building, hardening, and delivering the system. Integration into the receiving IT environment is outside the vendor's statement of work because it wasn't in the requirements. The vendor may not even know which IT environment the system is deploying to, or what that environment already operates.
The program office focuses on capability. The program's central question is "does it work?" — which is exactly the right question for the program to own. Capability delivery and operational absorption are different problems managed by different organizations with different budgets. Integration costs sit on the boundary between them, which is why they tend to fall through.
The IT organization is excluded from planning. The operations team that will maintain the system is often not part of the requirements discussion, the architecture review, or the authorization process. They learn about the new system when they receive a deployment request. By then, the integration cost is a fact, not a decision — the system is authorized, the mission needs it, and the only question is which existing work gets deprioritized to absorb the new burden.
What the integration burden actually looks like
For a typical system arriving at an accredited platform — a web application with a database, a cache, and an object storage dependency — the IT integration work includes:
Container image maintenance. The system runs on 3-5 hardened container images. When upstream CVEs emerge — and they emerge monthly — someone has to rebuild the images, scan them, verify the application still works, and push the updates through the deployment pipeline. If those images carried hundreds of CVEs before hardening, and the hardening was done by the vendor who is no longer under contract, the IT organization inherits the patching responsibility without the vendor's context on how the images were built.
Database operations. If the enclave has no managed database, the system includes a containerized database with persistent storage. That database needs backup automation (typically CronJobs to persistent volumes), upgrade migration handling (major version upgrades require dump-and-restore), monitoring (connection pool exhaustion, storage growth, replication lag), and someone who understands the schema well enough to troubleshoot production issues.
Service mesh impact. The system's VirtualService, DestinationRule, and NetworkPolicy configurations exist within a shared Istio mesh. A misconfiguration doesn't just break the new system — it can affect existing tenants on the same platform. The IT team needs to review these configurations against the platform's existing mesh topology, and that review requires understanding both the platform and the application.
Monitoring gaps. The system has health endpoints, but the platform's monitoring stack needs alert rules, dashboard panels, and escalation paths configured for a system the IT team has never operated. Without this, failures are discovered by users, not by monitoring — and the incident response time reflects it.
Storage and compute consumption. Persistent volumes, container resource requests, and log volume are real costs against cluster capacity. If the IT organization planned capacity for the existing tenant load, a new system arriving without capacity planning means either degraded performance for existing systems or an unplanned infrastructure expansion.
What it costs
Cleared IT operations staff bill at GSA Schedule rates of $145-$200/hr, with commercial cleared rates at $200-$325/hr. The integration work for a single system arriving at an accredited platform typically runs:
| Integration task | Effort | Cost (GSA $175/hr) |
|---|---|---|
| Image patching pipeline setup | 2-3 days | $2,800-$4,200 |
| Database operations setup (backup, monitoring, migration) | 3-5 days | $4,200-$7,000 |
| Service mesh review and configuration | 1-2 days | $1,400-$2,800 |
| Monitoring and alerting configuration | 1-2 days | $1,400-$2,800 |
| Capacity planning and storage provisioning | 1 day | $1,400 |
| Documentation and runbook creation | 1-2 days | $1,400-$2,800 |
| Total initial integration | 9-15 days | $12,600-$21,000 |
Then the ongoing cost: patching, monitoring, incident response, and platform upgrades that affect the system. At 4-8 hours per month of steady-state operations, that's $8,400-$16,800 per year at GSA rates. Over a 5-year ATO lifecycle, a single system adds $42,000-$84,000 in unplanned IT operations cost — assuming nothing breaks.
At commercial cleared rates, those numbers run 15-85% higher.
What the program office can do
You are in the best position to solve this, because you control the contract and the requirements.
Include the IT organization in pre-award discussions. Before you award a contract for a system that will deploy to an accredited environment, ask the receiving IT organization: "What will it cost you to integrate and operate this system?" If they haven't been consulted, they can't answer — and the integration cost doesn't disappear because nobody asked.
Require a deployment test before contract award. A one-week fit screen against a hardened baseline produces the specific findings that drive integration cost. The missing managed services, the image vulnerability posture, the service mesh conflicts, and the IT integration burden are all visible in the findings register. This is the vendor's investment in proving their product deploys — and it surfaces the integration costs that otherwise arrive as surprises after delivery.
Scope IT integration in the contract. If the vendor is responsible for integration support during the transition period — image patching documentation, runbook creation, knowledge transfer sessions with the IT team — include it in the statement of work. If the vendor's scope ends at delivery, make that explicit so the IT organization can plan and budget for the work they'll absorb.
Ask the vendor about IT operations cost. "What is the estimated annual operations cost for the receiving IT organization?" Most vendors haven't had a reason to think about this — their product was designed for environments where the infrastructure is managed for them. Asking the question early gives the vendor an opportunity to scope it, and gives the IT organization the information they need to plan.
The pattern is the same every time
A program office funds a capability. A vendor builds and delivers it. An IT organization inherits the integration and operations work. When that work isn't scoped in advance, the IT team either absorbs it from existing capacity, requests additional resources, or flags a timeline delay — all of which are harder conversations after delivery than before.
The integration cost is real, predictable, and cheaper to scope early. The program office is well positioned to bring the vendor and the IT organization into the same conversation before contract award — which is when the cost is easiest to plan for and the hardest decisions are cheapest to make.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems, as Cybersecurity Chief at the Air Force Lifecycle Management Center, and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO) — roles where he experienced integration costs from every angle: the IT team absorbing them, the acquisition office driving them, and the program office discovering them.
If your program is accepting delivery of a system that will deploy to an accredited environment and nobody has scoped the integration cost, contact Millabs. The conversation is free and the answer is specific.