Modernizing Decades of Legacy Systems at a Large Supply Chain Company

We recently started working with a large supply chain company headquartered in Cleveland, Ohio. We cannot disclose the company name at this stage. What we can describe is the problem class, the approach we are taking, and where AI-assisted engineering is making a measurable difference in the early phases of the engagement.

The company operates critical systems that have been built and extended over decades. This is not unusual for large supply chain operations. What makes the environment complex is the number of technology generations that coexist and depend on each other.

The current landscape includes mainframe systems that handle core transactional workloads, Lotus Notes applications that still support operational workflows, Azure cloud services running alongside on-premises infrastructure connected through VPN tunneling, and several systems that operate partially or fully offline. There are additional components built on technologies that have been deprecated by their vendors but remain in production because they are load-bearing.

None of these choices were irrational when they were made. Mainframes were the correct platform for high-volume transactional processing when these systems were designed. Lotus Notes was a reasonable workflow tool for its era. VPN tunneling was the standard approach for connecting distributed facilities to centralized infrastructure. Each layer made sense at the time it was added.

The problem is not that any individual system is wrong. The problem is that the connections between them have accumulated into a dependency graph that no single person fully understands. Documentation, where it exists, reflects the system as it was at the time of writing, not as it is today. Institutional knowledge is distributed across teams, and some of it has left with the people who built the original systems.

Legacy modernization in environments like this is slow for a specific reason: the discovery phase is expensive.

Before you can plan a migration, you need to understand what exists. Which systems talk to which other systems. What data flows between them. Which integrations are documented and which are informal. Where the actual business logic lives versus where people assume it lives. What happens to downstream processes when an upstream system changes behavior.

In a typical engagement, this discovery work is manual. Consultants interview stakeholders. They read whatever documentation they can find. They trace connections by examining configuration files, database schemas, network diagrams, and middleware logs. They build spreadsheets and diagrams that attempt to represent the current state.

This process takes months. It produces artifacts that are often incomplete because the system is too large for any team to map exhaustively in a fixed timeline. And by the time discovery is done, some of what was documented has already changed.

We are using Anthropic's Claude Code throughout this engagement. Not to replace the engineering work, but to change the rate at which we can process information and produce useful artifacts.

Here is what that looks like in practice.

Stakeholder knowledge capture. We conduct interviews with engineers, operations staff, and system administrators who have direct experience with specific parts of the landscape. These conversations produce raw notes, often unstructured, sometimes contradictory. Claude Code helps us process these notes into structured system descriptions, identify conflicts between different accounts, and surface questions we need to ask in follow-up sessions. What used to take days of synthesis after each round of interviews now happens in hours.

System mapping. We feed Claude Code configuration files, database schemas, API definitions, network diagrams, and integration specifications. It helps us build dependency maps that show how systems connect, what data flows between them, and where the integration points are. These maps are not perfect on the first pass. They are starting points that we validate with the teams who operate the systems. But the starting points are substantially more complete than what manual analysis produces in the same time.

Documentation generation. Legacy environments often have incomplete or outdated documentation. We use Claude Code to generate current-state documentation from the artifacts we collect: system inventories, data flow diagrams, integration maps, risk assessments. Engineers review and correct these documents, but the first draft comes from synthesis of the raw inputs rather than from scratch writing.

Proof of concept assembly. As we identify modernization candidates, we need to demonstrate that proposed changes are feasible without disrupting production systems. Claude Code accelerates the assembly of proof-of-concept implementations that test specific integration patterns, data migration approaches, or replacement architectures. These POCs help stakeholders evaluate options based on working code rather than slide decks.

This engagement is in its early stages. We have not yet completed a full migration of any major system. We are in the phase of understanding the landscape, identifying the highest-value modernization targets, and building the organizational alignment needed to execute changes safely.

Claude Code does not eliminate the need for experienced engineers who understand distributed systems, legacy integration patterns, and the operational realities of supply chain environments. It does not replace stakeholder relationships or institutional knowledge. It does not make hard architectural decisions.

What it does is compress the time between collecting information and producing useful artifacts from that information. In an engagement where the discovery phase typically consumes a disproportionate share of the timeline and budget, that compression matters.

The supply chain industry has specific characteristics that general-purpose technology consultants often underestimate. System uptime requirements are tied to physical operations. A warehouse management system outage during peak shipping season is not an IT ticket. It is a revenue event. A demand planning failure cascades through procurement, manufacturing, and distribution. An integration failure between an ERP and a 3PL system can stop shipments.

Our team has worked in these environments. We understand that modernization plans need to account for seasonal load patterns, parallel-run requirements, rollback strategies, and the reality that some systems cannot be taken offline for migration without affecting customers.

This experience shapes which questions we ask during discovery, which systems we prioritize for modernization, and how we sequence changes to minimize operational risk. Claude Code helps us move faster through the analytical work. Domain experience determines whether we are moving in the right direction.

This engagement reinforces something we have observed across our work in regulated and operationally complex industries. The bottleneck in legacy modernization is not usually the implementation. It is the understanding.

Teams spend months trying to build a complete picture of what exists before they can begin planning what to build. That picture is never truly complete, and the longer the discovery phase takes, the more likely it is that organizational momentum stalls.

AI-assisted engineering, used responsibly, changes that dynamic. It does not make the problem simpler. It makes the analytical work faster. And in engagements where the analytical work is the critical path, faster analysis means earlier progress.

We will share more about this engagement as the work progresses and as we have results to report. For now, the early phase has confirmed what we expected: the combination of domain knowledge, engineering experience, and AI-assisted tooling produces measurable acceleration in the part of the work that typically takes the longest.