Title

The hidden constraint in US federal transformation planning

Section
Insight
Summary

The US federal government spends more than $100 billion on technology every year. Around 80% of that goes on keeping existing systems running. The remainder must fund everything else: cloud migrations, legacy decommissioning, shared platforms, and AI-enabled service redesign.

That ratio matters. Most of the budget is already committed to keeping existing systems running, leaving comparatively little for transformation work. The existing software estate – the contracts, licenses, entitlements, and renewals – controls what can change, when it can change, and how much flexibility agencies have.

As it stands, most transformation programs decide their technical and architectural direction first, then review the estate afterward. However, the earlier agencies understand the software estate, the more space they have to make deliberate choices about what to keep, what to retire, what to negotiate, and what to shape the transformations around.

What the public sector context adds

In federal government, fragmentation isn't just a software management problem. It is reinforced by the way funding, procurement, and organisational accountability work. Software contracts frequently cut across fiscal years, with rules around colors of money adding another layer of constraint. GSA Schedules, GWACs, and SEWP can simplify compliant buying, but do not in themselves create visibility across the software estate. Departments, component agencies, bureaus, and independent entities may each hold separate commercial relationships with the same vendor, making it difficult to see commitments and renewal exposure as a single portfolio. None of this is unusual, and none of it reflects on how programs are run. It is simply the environment. But it does leave programs with less room to maneuver, making a clear view of the software estate particularly important.

Four constraints every transformation program should plan around

In this environment, four common software constraints can become particularly problematic when surfaced late. 

  1. Renewal timing: A legacy contract may have a year or more to run when the system is ready for decommissioning, or a major renewal may land mid-migration. Mapping these calendars early creates room to plan whether to retire or renew on their own terms.

  2. Vendors negotiating from strength: If a software contract expires mid-transformation, an agency may have little choice but to renew, weakening negotiating leverage. Mapping renewals against the transformation roadmap early gives agencies more time to create options and negotiate before they end up in a weaker position.

  3. Architectural decisions made without commercial context: A target platform might be ideal on from a technical standpoint, but commercially problematic because of existing commitments, exit terms, or pricing models. Bringing commercial and technical perspectives together early means these factors get weighed before the decision is made. 

  4. The hidden estate: Individual teams often procure tools, licenses, and SaaS subscriptions to meet immediate needs, and these naturally accumulate outside any central view. Each may be small on its own, but together they shape migration timelines and running costs.

These conditions are difficult to manage when they surface late. When the estate is visible early, agencies have more room to plan around them deliberately, before they harden into constraints.