One Workflow That Either Works or Doesn’t: KMS Technology CEO Jason Wojahn on Modernizing Applications, Data and AI Together

Key Highlights

“The business doesn’t experience applications, data, and AI as three separate programs. It experiences one workflow that either works or doesn’t.”

Jason Wojahn, CEO of KMS Technology, says enterprises organize transformation around technology categories while the business runs on workflows that cut across all of them. The result, he argues, is that application modernization, data migration and AI programs each rediscover the same systems, integrations and business rules at different times, and the business waits in the gaps between them. His answer is to modernize applications and data together, starting with one consequential business workflow rather than a full system inventory, and to measure success by what the business can now do rather than by applications retired.

In this conversation, Jason explains what building and selling a services firm taught him about earning scale, and how he defines the “Execution Economy.”

He describes a six-week agentic engineering engagement with a maritime software provider, why business logic buried in legacy code is the hidden blocker for AI agents, and what the first 60 days of a coordinated engagement look like. He also sets out where software and people each carry the work, the earliest warning sign that a program is in trouble, and a prediction most CIOs may not expect: that some of the fastest AI adopters will still be running the same core systems in three years.

You co-founded and led Thirdera through its acquisition by Cognizant, ran Accenture's global ServiceNow business, and held leadership roles at IBM Global Services. What did building and selling a services firm teach you that you're now applying as CEO of KMS Technology, and what drew you to this company?

Building Thirdera taught me that adding capability and earning scale are two different things. Bring good firms together, and you have more capability on day one. But you earn scale when a client can count on the same quality of delivery regardless of which team shows up.

That takes shared standards, clear ownership, and a delivery model people can actually repeat. It's not simply a matter of bringing teams under one roof. It's about making the combined organization work consistently for clients.

AI now gives us an opportunity to extend that model further. Historically, growth in professional services was closely tied to adding delivery capacity. By combining human expertise, intelligent systems, and reusable intellectual property, we can change how much a team delivers without growing headcount at the same rate.

That's what I mean by the Execution Economy. As intelligence becomes more accessible, competitive advantage shifts toward how reliably organizations turn that intelligence into action.

What drew me to KMS was the engineering depth already here and the opportunity to make that shift real. The goal isn't simply to make engineering teams more productive. It's to build an AI-native services firm that translates greater execution capacity into measurable business outcomes for clients.

After roughly 30 years building global services organizations, outside of work, what do you do to switch off, and what's one habit from your personal life that has quietly shaped how you lead?

Photography is one way I switch off. I remember catching the Flatirons coming out of the clouds. The view changed in a matter of minutes.

It's a small thing, but it reminds me of a habit I value in leadership: slow down long enough to notice what's changing before deciding what to do.

That carries over into how I approach operating reviews. A dashboard can tell you what the numbers are doing, but it doesn't always tell you why. I want to hear from the people closest to the work about what they're seeing before I draw a conclusion.

KMS is moving from AI-enabled services to AI-native execution, with a shift from project-based work to outcome-based delivery. In plain terms, what does a client get under that model that they wouldn't get from a traditional modernization engagement?

Clients don't invest in modernization because they want newer technology. They invest because something in their business needs to work better, faster, or more efficiently.

Traditional engagements often measure success through applications migrated, features completed, or project milestones achieved. Those things matter, but they don't necessarily tell you whether the business is performing any better.

AI-native execution changes the starting point. We begin with the business outcome, then bring together engineering, data, AI, and agentic workflows to achieve it. Clients get a shorter path from business need to demonstrable progress.

Consider a recent engagement with a maritime software provider. The client needed tangible progress on a next-generation cloud platform before committing to a larger development roadmap.

Rather than approaching it as a conventional, lengthy development effort, we structured a six-week agentic engineering engagement. In just 809 total team hours, we delivered a functional foundation covering 35–45% of the total MVP scope—work that had originally been estimated at 6,000–8,000 hours—supported by more than 5,400 unit tests.

What mattered wasn't simply generating code faster. The client had a demonstrable foundation to validate the product direction with stakeholders and inform its next investment decision.

That's the direction we're taking at KMS: making business outcomes central to how we plan, deliver, and measure our work, regardless of whether an engagement uses outcome-based pricing.

Enterprises often run separate programs for application modernization, data and cloud migration, and AI, each with its own vendor and budget. Why do these end up paying for discovery, integration and testing twice, and where does the duplicated cost actually show up?

The fundamental problem is that enterprises organize transformation around technology categories, while the business operates through workflows that cut across all of them.

An application modernization team examines legacy systems and their dependencies. A data team studies many of those same systems to understand how information moves. Then an AI team arrives and has to rediscover the business rules and integrations needed for an agent to actually perform work.

You're paying multiple teams to understand different parts of the same operating environment, often at different times.

The duplication shows up in system discovery, integration development, data reconciliation, regression testing, and documenting business logic. But the biggest cost is often the time lost between those activities.

The AI initiative waits for the data foundation. The data program depends on changes to legacy applications. Meanwhile, the business is still waiting for the result that justified the investment.

That's why we believe applications and data need to be modernized together, with the intended business workflow driving the priorities.

It doesn't mean every system needs to be replaced or every dataset consolidated before work can begin. It means understanding which dependencies matter to the outcome, addressing them together, and building reusable capabilities along the way.

The business doesn't experience applications, data, and AI as three separate programs. It experiences one workflow that either works or doesn't.

Much of what a company knows about how it operates is buried in legacy code that nobody has fully documented. How does that undocumented business logic become the hidden blocker for AI agents, and what goes wrong when teams try to deploy agents on top of it anyway?

One of the most underestimated challenges in enterprise AI is that a tremendous amount of business knowledge isn't sitting in documentation or a clean data model. It's embedded in decades of application code, integrations, database procedures, and manual workarounds.

Think about pricing exceptions, approval thresholds, customer eligibility rules, or compliance requirements. Those rules determine how the business actually operates, but they aren't always visible to a new AI system.

An agent can interact with an application through an API and still make the wrong decision if it doesn't understand the rules governing that transaction.

For example, an agent might be technically capable of processing a customer request, but that doesn't mean it has the context to handle an exception correctly. A technically successful transaction can still be a business failure.

This is why making systems accessible to agents isn't the same as making them agent-ready.

Modernization needs to uncover the relevant business logic, validate it with people who understand the operation, and make those rules accessible and enforceable through governed interfaces and controls.

AI can help accelerate code analysis, documentation, and dependency discovery. But business and engineering experts still have to determine which rules are valid, which need to change, and how they should be applied.

The real modernization challenge isn't simply connecting an agent to a legacy system. It's making the knowledge embedded in that system reliable and usable across the business.

What does coordinated modernization look like in practice, and why do you argue it should start with one business workflow rather than a full system inventory? Could you walk us through how an engagement like that begins in the first 30 to 60 days?

It's easy for modernization to become an exercise in cataloguing everything that's wrong with the technology estate. You can spend months building a comprehensive inventory and still be no closer to improving how the business operates.

A system inventory has value, but it shouldn't become a prerequisite for making progress.

I'd start with one consequential business workflow: something that matters to the organization, has a clear owner, and has a measurable opportunity for improvement.

In the first 30 days, the priority would be understanding how that workflow operates today. Where does work slow down? Where do people manually move information between systems? Which applications, data sources, integrations, and business rules are involved?

Just as importantly, we establish a baseline and agree on what better performance looks like. That might be faster processing, fewer errors, lower operating costs, or reduced manual intervention.

Over the next 30 days, the focus shifts to building and validating an initial working increment. That means modernizing the specific data flows, interfaces, or business logic the workflow depends on, rather than attempting to transform the entire environment at once.

If agents are involved, we also define what they can recommend, what they can execute, and where human approval is required.

The objective in that initial period is to demonstrate measurable progress where feasible, not promise a production-ready transformation in 60 days.

Each workflow should also leave something reusable behind: an integration pattern, a governed data capability, or an execution framework that makes the next workflow easier to modernize.

That's how modernization starts to compound. You're building the organization's ability to execute differently.

KMS acquired Addepto, bringing in a team that is 97% AI engineers, and KMS is expanding Velox, its platform for orchestrating AI-driven workflows. How do the two fit into a modernization programme, and where do people, as opposed to software, still do the heavy lifting?

Addepto brings specialized expertise in data engineering, machine learning, and AI. KMS brings digital engineering, application modernization, integration, and software quality capabilities. Together, those strengths allow us to address the application, the data behind it, and the intelligent workflows operating across them as parts of the same transformation.

Velox supports that approach as KMS's agentic AI orchestration platform for software delivery. It connects specialized AI agents, engineering tools, and shared project context into human-in-the-loop workflows across the software development lifecycle. It extends AI beyond individual developers to the broader delivery team, including product managers, business analysts, testers, and DevOps.

Velox also supports modernization activities such as analyzing existing codebases, reconstructing requirements and business logic from legacy systems, and connecting work across requirements, engineering, and testing workflows. Combined with spec-driven engineering, the objective is to move from business intent to working, tested software through structured workflows with human oversight.

But people remain essential to making that work valuable. They determine which business problems are worth solving, interpret complex business rules, make architectural tradeoffs, and decide how new capabilities fit into the client's operating model.

That's where I see the greatest opportunity for AI-native delivery. As intelligent systems take on more repeatable work, experienced teams can concentrate on the decisions and judgment that determine whether an engagement succeeds.

Your appointment announcement says, "Delivering measurable outcomes is the new standard for AI-native services firms like KMS." Most modernization programs still report on migration milestones such as systems moved or applications retired. Which business outcomes should replace those, and how do you agree on them with a client before work starts?

A retired application is a technical milestone. It's not necessarily a business result.

You can complete a migration on time and within budget, but if the business process still takes the same amount of time, requires the same manual work, and produces the same errors, what have you really changed?

Modernization needs to be evaluated against how the business performs differently because of the investment.

I tend to look at three things first: the time from business need to outcome, where work gets stuck between teams, and how much manual coordination the workflow still requires. Then we connect those operational improvements to cost, quality, revenue, or customer experience.

The specific measures depend on the business. For a manufacturer, it might be unplanned downtime or maintenance response time. For an insurer, it could be claims processing time, cost per transaction, or error rates. For a software business, it might be time to market or release quality.

Before work begins, we need to identify the business owner, establish a credible performance baseline, and agree on a small number of outcome measures and how they'll be tracked. If the data isn't available, that needs to be addressed early.

Technical milestones still matter. Systems need to be secure, stable, and reliable. But those measures should support the business case, not replace it.

The conversation needs to change from "What did we build?" to "What is the business now able to accomplish that it couldn't before?"

That's the standard that ultimately matters.

When a modernization effort stalls or a business case unravels, what is the earliest warning sign that leaders tend to ignore, and what do you do differently when you spot it?

If a modernization program is reporting green milestones but the business owner can't tell me what got faster, cheaper, or better for the customer, I want to know what we're calling green.

The technical team may be delivering what was requested. The budget may be tracking to plan. But those measures don't tell us whether the original business problem is being solved.

When I see that disconnect, I'd get the business owner and engineering lead in the same room and go back to the original baseline. What were we trying to improve? What has actually changed? Where is the work still getting stuck?

From there, I'd agree on one workflow where we can measure a meaningful change. Give the business owner the authority to adjust the scope, then use the result to decide what we fund next.

More reporting won't fix an accountability problem. Someone has to own the result and have the authority to change course.

Looking two to three years ahead, what is one prediction about legacy modernization in an agent-driven enterprise that you're confident about, and that most CIOs would currently disagree with?

Here's my prediction: within three years, some of the fastest AI adopters will still be running the same core systems they run today.

That may sound counterintuitive when so much of the modernization conversation is about replacing legacy applications. But becoming AI-native doesn't mean every system of record has to be replaced first.

The opportunity is to make the capabilities a business already trusts available through governed interfaces, with clear rules for what agents can read, decide, and execute.

Core systems still have an important role. They maintain trusted data, enforce business rules, and manage critical transactions. What's changing is how intelligent systems can operate across them.

That means modernizing the applications, data, and interfaces needed for a specific business workflow. Make the existing capabilities accessible where they can support reliable execution. Replace the parts that can't meet those requirements.

AI will also help accelerate legacy-code analysis, documentation, transformation, and testing. But the harder questions remain: which rules should be preserved, which capabilities need to change, and what authority should agents have?

The bigger risk is making the business wait three years for a core replacement before it can change how work gets done.

I believe the organizations that move fastest will be the ones that modernize selectively and continuously, rather than treating wholesale replacement as the prerequisite for AI-driven execution.