Legacy modernization
Data modernization: A practical guide for getting it right
During the shift to digital, many organizations aspired to become digital-native, but relatively few achieved it. We are seeing a similar pattern in the AI era: while a small number of companies are AI-native, becoming AI-first is a more realistic ambition for most established organizations.
Why can’t every organization become AI-native?
Let’s start with the definition of AI-native. An AI-native organization is one whose products, operating model and technology foundations have been designed around AI from the outset. An AI-first organization does not need to have been built around AI. Instead, it deliberately redesigns its strategy, workflows and operating model to take advantage of AI.
For most established organizations, becoming truly AI-native is difficult because AI is only one part of a much more complex technology landscape. A typical enterprise runs a mix of legacy systems, SaaS products, traditional machine learning applications and newer LLM-enabled products, all built for different purposes and operating assumptions. They cannot all become AI-native at the same pace.
A better way to think about an AI-first organization is as a smart traffic-management system. Not every part of the organization needs to move at the same speed, and not every problem needs AI. Becoming AI-first means deliberately deciding where AI adds value, what it should be responsible for and where people or existing technology remain the better choice.
Much enterprise AI adoption still begins with individual productivity: helping people perform existing tasks faster. While useful, these gains alone rarely amount to organizational transformation. Scaling AI requires moving beyond individual productivity toward greater autonomy and organizational change.
One useful way to think about organizational AI adoption is across three stages:
AI-assisted: AI supports existing workflows, focusing on individual productivity.
AI-enabled: AI is embedded into processes and operations, elevating team productivity.
AI-first: Redesign products, processes and operating models around what humans and AI can accomplish together, focusing on organizational productivity.
Reaching this AI-first stage requires organizations to rethink how people and AI work together, where is the boundary between people and AI and adopt a risk-based tiered autonomy model.
Six shifts to build an AI-first team
Transitioning into an AI-first team requires six fundamental shifts in how we work:
From execution to judgment: As AI takes on more execution work, human contribution increasingly shifts toward judgment: deciding what to delegate, evaluating outputs and determining when intervention is required. In one legacy modernization project, agents perform much of the execution and evaluation, while developers decide what agents can do independently and where human approval is required. Their role shifts from authoring every part of the solution to designing its flows, decision points and controls, becoming more architectural in nature. This also creates opportunities to shift controls earlier in the delivery lifecycle, embedding validation and guardrails into AI-first workflows.
2. From T-shaped to E-shaped: AI can help people work effectively across a broader range of activities without eliminating the need for deep expertise. E-shaped is the concept introduced by Marc Andreessen (Co-founder of a16z), describing people who have:
Deep vertical core: Maintaining deep, specialized expertise in a primary craft.
Multiple horizontal bars: Developing real, functional capabilities in server adjacent disciples simultaneously like product, design and engineering.
The AI “backbone”: Using AI as the vertical connector that makes these multiple horizontal “arms” possible. AI acts as a force multiplier, allowing a single person to execute high-level tasks in areas where they aren’t naturally experts.
In one project, a product manager built much of a prototype directly, shortening a feedback cycle that would traditionally have required coordination across product, design and development. The result is not that everyone becomes an expert in everything, but that the boundaries between roles become more permeable.
3. From document to managed context: Documentation remains important, but AI creates a new requirement: organizational knowledge must also be structured and accessible as usable context. On some AI-enabled projects, requirements, specifications and architectural decision records are moving closer to the codebase so both people and AI can use them. Teams therefore need to treat context as an engineered asset, not knowledge scattered across documents, systems and people's heads.
4. From tool to partner: Earlier AI developer tools largely assisted with bounded tasks such as code completion or generation. Agentic systems can now take on multi-step activities, use tools and interact with other systems. That changes the challenge from simply providing AI capabilities to defining what work can be delegated and under what controls. Protocols such as MCP are one mechanism for connecting agents to a wider ecosystem of tools and information.
But becoming AI-first does not mean imagining an organization in which every activity is performed by an agent. The more realistic model is hybrid: people remain accountable for outcomes while AI takes on different levels of execution depending on the task. The goal is to use AI where it performs well, rather than assuming it can solve every problem.
5. Engineering practice as safety net: Faster AI-assisted delivery only creates value if teams can detect and recover from mistakes quickly. Practices such as automated testing, continuous integration, observability, security controls and small reversible changes become more important as AI increases the pace of delivery. As AI generates more change than people can realistically review manually, traditional code review alone cannot provide the necessary control. Practices such as TDD and BDD therefore gain renewed importance by providing automated ways to determine whether changes behave as expected.
6. From individual learning to feedback: Every interaction with AI can reveal useful information: where prompts work, where context is missing and where controls fail. Teams need mechanisms to capture those lessons and improve shared instructions, context, tools and workflows rather than leaving the learning with individual users.
Building AI-first organizational capabilities
The six shifts describe how teams work differently. Scaling them across an enterprise requires shared infrastructure, policies, data and engineering practices that make AI-first ways of working accessible and safe.
A clear AI stance: People need to understand how AI is expected to be used, where its use is restricted, what decisions can be delegated and where human accountability remains essential.
Most existing operating models were designed around people as the primary actors. An AI-first operating model needs to redefine that boundary explicitly, determining where AI executes autonomously, where people remain in the loop and how responsibility passes between them.
AI-ready data and context: AI systems need secure access to reliable internal data, documentation, code and business context. Improving availability alone isn't enough; that information also needs sufficient quality, meaning and governance for AI systems to use it correctly.
The consequences can be significant. In one client example, a product expected to take about three months stretched to around ten months, partly because legacy systems and APIs had been designed for human interactions rather than agents. A process that was straightforward for a person could require an agent to coordinate 10 or 20 API calls. Organizations therefore need to consider agent experience alongside customer experience.
Strong engineering practices: Automated testing, observability, continuous delivery and reversible changes provide the technical safety net teams need to experiment with AI without sacrificing reliability. AI amplifies the foundations already in place. Teams with strong engineering practices can move faster because they have mechanisms for validating and controlling change; weak foundations simply allow problems to scale faster too.
Customer-centricity: AI can dramatically increase the speed at which teams produce software, but speed has little value if teams are solving the wrong problem. Clear customer outcomes provide a North Star for deciding where AI should and shouldn't be applied.
AI-enabled internal platforms: Internal platforms can make approved AI capabilities easy to access while encoding organizational guardrails around models, data, tools and permissions. Done well, they make the safe path the easiest path. As systems become more agentic, platforms also need to govern what agents can access and do, and where human intervention is required. Organizations like Spotify with strong engineering platform capabilities (Backstage, Fleet Management) move much faster with AI adoption than those without.
Becoming AI-first is therefore less about adopting more AI tools and more about redesigning how work happens around them. Established organizations will continue to operate a mix of legacy, traditional and AI-enabled systems, with people and AI taking on different roles across that landscape.
The goal is not to make every system AI-powered or every activity agent-driven, but to determine where AI creates value and build the operating model, data, controls and engineering foundations to support it. Organizations may never become AI-native, but they can still become deliberately and effectively AI-first, achieve meaningful business impacts.
