The Department of Government Efficiency (DOGE) spotlighted federal IT, and for good reason. We’re still running some of our most critical missions on legacy systems written in obsolete COBOL and Fortran, or strung together with spaghetti code we’ll never fully unpack. And the engineers who built them? Long gone. This makes innovation hard and compromises security.
Everyone agrees we need to modernize. The real problem lies in “how.” Too many efforts start with fear of breaking something, disrupting operations, or taking the blame. So we over-plan, over-architect, or try to bolt modern needs onto fragile, outdated tech that wasn’t built for today’s missions.
But delay is risk. The longer we wait, the harder, more complex, and more expensive modernization gets. We don’t need another planning cycle. We need to ship value now. Start small. Learn fast. Iterate.
Modernization requires an evolutionary approach to technology, design, and culture. Tech, process, people: That’s how we move the mission forward.
From Waterfall Paralysis to Incremental Progress
Legacy systems scare even those fully committed to modernization. I’ve seen it firsthand. At one space defense operations center, the 1980s system was so tightly coupled that no one knew what might break if you touched a line of code. So, what happens? People default to waterfall. Document everything, test forever, avoid perceived risk. But that just freezes the mission in the past.
The Strangler Pattern is a better approach. Instead of ripping out the old system entirely, you start by building new capabilities alongside it. No big bang cutover, just steady, manageable progress.
Take that same operations center. Start by replacing something contained, like the mission scheduling interface. Modernize just that piece and route functionality to a new system. Prove it works. Once that piece is stable, move on to reporting or telemetry ingestion. This isolates risk, builds trust, and lowers fear of operational disruption or failure. It gives teams confidence to move forward without breaking what still works.
Start With 1:1, but Don’t Stop There
Modernization often starts with a 1:1 rebuild. Sometimes, replicating legacy features in a modern stack and demonstrating stability is the only way stakeholders are comfortable moving forward. But that’s just a starting point. The real opportunity comes after, and that’s where validation matters.
Not every feature from the legacy system is necessary. Features built around old constraints or patched in as workarounds may no longer make sense. Without talking to users, we risk recreating outdated workflows in shinier packaging and calling it progress.
Modernization has to be both technical and human. To build software users love, you have to build it with them — not just for them. Engineers need to understand the code, what’s reusable, and what’s fragile. But human-centered design means grounding every product decision in a deep understanding of user needs and pain points in a real-world context. Users should have an opportunity to explain what they do and why. If a user says, “I need this table to generate a report,” ask: “What decision does that report support?” That’s how we uncover what matters and deliver outcomes for mission impact
At its core, modernization is about changing how we work. The only way to know if we’re on the right track? Ship something. Watch how people use it. Gather feedback. Iterate. Rethinking workflows is how we stop rebuilding the past and start delivering for today’s mission.
Rethink How We Buy, Rethink How We Build
The biggest barrier to modernization is culture, not tech. Legacy systems aren’t just code; they’re decades of process, paperwork, and fear-based decision-making baked into how we operate. Without a shift in mindset, no amount of new tooling will move the mission forward.
The change has to start with how we buy. Too many contracts focus on delivering a checklist of features for requirements written five years ago rather than shipping outcomes to solve real user problems in real operational environments, now.
We’ve all seen it: teams afraid to walk away from bad programs because of sunk costs. So they double down. Plan more, test longer, and hope it will get better. It never does.
The better path is continuous modernization. Start small, deliver something real, validate it with users, and scale. This lowers risk and allows teams to evolve systems as the mission changes.
It’s time to stop playing defense with legacy tech and start building for the future.
As Rise8’s Director of Growth, Carlo is focused on creating and cultivating a great customer and employee experience to support the scaling of Rise8. As a conduit to government and commercial prospects, Carlo educates on the culture and expertise of Rise8, and ways to partner to deliver outcomes that matter. Before becoming a Riser, Carlo served six years as an acquisition officer managing software programs within the Air Force and Space Force. Carlo was one of the first project managers turned product manager at Kessel Run, responsible for delivering the first major product adopted by AOCs across the globe. The Air Force sent Carlo to the Space Force to help stand up the Space Force’s first software factory, Kobayashi Maru, and Section 31, where he served as the Director of Product. Despite helping lead digital transformation efforts for two major organizations, there was only so much he could do as a Captain. Wanting to continue to pursue his passion and to have an even larger impact outside of the military, he separated and decided to rejoin forces with Bryon at Rise8 to continue enabling innovation through people, culture, and software.
Leave a Reply
You must be logged in to post a comment.