Mike Phillips Tech

What government agencies actually pay — and why the sticker price is almost never the real number

By Mike Phillips

When a federal agency signs a contract for a new enterprise software platform, the number in the press release is almost never the number that matters. After a decade embedded inside those procurement processes — at the U.S. Department of State, the National Institutes of Health, and DISA — I watched agencies consistently underestimate what they were actually buying. Not because the procurement officers were careless. Because the real costs aren’t in the contract.

They’re in everything that comes after it.

This isn’t a theoretical concern. Organizations routinely self-estimate 20–30% wasted spend across software categories, with public sector entities often facing even greater waste due to decentralized procurement. A recent analysis found that the federal government could save an estimated $3 billion annually simply by restoring genuine competition over software contracts — money currently absorbed by vendor lock-in, licensing complexity, and structural procurement gaps that most agencies lack the internal capacity to close.

Understanding where those costs hide is the first step to controlling them.

The Six Hidden Cost Categories No RFP Captures

1. Implementation: The Gap Between “Configured” and “Done”

Enterprise platforms are sold as configurable. What that means in practice is that someone has to do the configuring — and that someone is almost never the vendor at the price quoted.

During the State Department’s ServiceNow deployment, we discovered early in the engagement that the base implementation scope covered the platform infrastructure, not the agency’s actual workflows. Every bureau had distinct process requirements. Every integration with legacy systems required custom development. Every deviation from the out-of-the-box configuration — and there were dozens — was a change order.

Implementation costs for large federal ITSM deployments routinely run 1.5x to 3x the licensing cost in the first year. That multiplier almost never appears in the initial procurement estimate.

What to look for: Ask vendors for reference customers in similar-sized public sector environments and request their actual Year 1 total cost of ownership, including implementation hours, change orders, and integration work. Get it in writing before the contract is signed.

2. Licensing Complexity: The Invisible Tax

Enterprise software publishers — Microsoft, Oracle, SAP, ServiceNow — have built licensing models of extraordinary complexity. This isn’t accidental. Complexity serves the publisher by making it nearly impossible for government procurement teams to accurately assess whether they’re in compliance, let alone whether they’re optimized.

The practical result: agencies frequently buy the wrong license tier, the wrong module bundle, or the wrong user count — and don’t discover it until renewal or audit. The cost of a single software license can vary by $200 per unit between agencies buying the same product — a disparity that compounds across an enterprise with tens of thousands of users.

At one agency I supported, we identified mid-engagement that the contracted license tier didn’t actually cover the reporting and analytics modules the agency had planned to use. Expanding the license added six figures to a contract that had already been signed. The procurement team had relied on vendor assurances during the RFP process rather than independent verification of module scope.

What to look for: Before any enterprise software procurement, bring in independent licensing specialists — not the vendor’s implementation partner — to validate that the proposed license structure actually covers the intended use case. The cost of that review is trivial compared to a mid-implementation license expansion.

3. Data Migration: The Cost That Always Surprises

Every enterprise software replacement involves data. Existing records, active cases, historical logs, user accounts, workflow states — all of it has to move from the old system to the new one. And it almost never moves cleanly.

Data migration in federal environments is particularly expensive for three reasons: data quality in legacy systems is often poor, security and compliance requirements constrain tooling options, and institutional knowledge about the data’s structure frequently lives in people rather than documentation.

On a State Department case management migration I worked on, we mapped a legacy system used across multiple financial offices and visa processes. The data model was inconsistent across bureaus, documentation was incomplete, and several field definitions had been informally repurposed over the years in ways that weren’t recorded anywhere. The migration scope tripled from initial estimates before we finished discovery.

What to look for: Require vendors to conduct a formal data assessment — not a data migration estimate — before procurement scope is finalized. The assessment should identify data quality issues, schema inconsistencies, and security constraints. Any estimate produced without a proper assessment is a guess.

4. Training and Change Management: The Costs Agencies Cut First

When budgets tighten during implementation — and they always do — training and change management are the first line items to shrink. This is a false economy that the data consistently exposes.

Agencies that underinvest in user adoption typically see platform utilization plateau well below intended levels. In ITSM deployments, low adoption means teams continue to route requests through email and informal channels alongside the new system, creating duplicate workflows and eliminating the efficiency gains the platform was procured to deliver.

I’ve watched agencies spend millions on ServiceNow deployments and then fail to achieve even basic incident management adoption across their user base because end-user training was compressed into a two-hour webinar. The platform technically worked. Nobody used it correctly.

What to look for: Change management and training should be treated as non-negotiable line items, not discretionary add-ons. Industry benchmarks suggest allocating 15–20% of total implementation budget to change management for enterprise platforms in complex organizations. For public sector environments with distributed workforces and legacy process cultures, that number should be on the higher end.

5. Ongoing Administration: The Headcount You Didn’t Budget For

Enterprise software platforms don’t run themselves. They require dedicated administrators — people who understand the platform’s configuration, manage user provisioning, handle integrations, respond to incidents, and own the upgrade cycle.

In the private sector, this is usually absorbed by existing IT operations teams. In federal environments, it’s frequently treated as an afterthought during procurement, with the assumption that existing staff will absorb the workload. That assumption consistently fails.

A platform like ServiceNow in a large federal environment requires at a minimum one or two dedicated platform administrators, plus subject-matter expertise for each configured module. If that capacity doesn’t exist in-house — and at most agencies, it doesn’t — the agency either under-administers the platform (degrading performance over time) or returns to the vendor for managed services at rates significantly higher than what an FTE would cost.

What to look for: Before procurement, agencies should conduct an honest internal capacity assessment. If the organization cannot staff dedicated platform administration, the total cost of ownership calculation must include either the cost of hiring or the cost of vendor-managed services — not the optimistic assumption that existing IT staff will figure it out.

6. Vendor Lock-In: The Exit Cost Nobody Prices

The final hidden cost is the one that accumulates silently until the agency decides to change platforms — at which point it becomes very visible.

Procurements labeled as “competitive” are often written in ways that guarantee the incumbent wins. Once an agency has configured a major enterprise platform, migrated its data into that platform’s proprietary schema, and trained its staff on that platform’s workflows, the practical cost of switching vendors is enormous — often comparable to a new implementation. Vendors price their renewals accordingly.

This isn’t a new problem, but it has gotten worse as platforms have become more deeply integrated into agency operations. The more an agency customizes, the more it pays to leave.

What to look for: Procurement teams should evaluate exit cost alongside entry cost. Contract terms should require data portability in open, documented formats. Agencies should assess the degree to which proposed customizations will create lock-in before committing to implementation scope, and build contractual protections for migration assistance into the original agreement.

The Structural Problem Behind All of These Costs

These aren’t isolated mistakes. They reflect a structural mismatch between how enterprise software is sold and how government procurement works.

Vendors compete on licensing price because that’s what RFPs evaluate. The costs that don’t appear in the licensing price — implementation, integration, migration, training, administration, lock-in — are real, but they’re downstream of the procurement decision. By the time they materialize, the contract is signed, and the vendor has leverage.

The agencies best positioned to manage these costs are the ones that treat total cost of ownership as a first-class procurement criterion rather than an afterthought. That means requiring detailed implementation scoping before award, bringing in independent technical advisors, building data portability requirements into contracts, and protecting training and change management budgets from the pressure to cut.

None of that is complicated. All of it requires procurement teams to push back on vendors during the phase when vendors are most reluctant to be pushed — before the deal is done.

The agencies that do it right spend more time on procurement and less time cleaning up implementations. The ones that don’t spend years paying for it.