Can Legacy VSAM Data Power AI Initiatives Without a Full Migration?

Can VSAM data be used for AI without migrating off the mainframe?

Yes, VSAM files can feed AI systems like RAG pipelines and LLM-based agents through data virtualization and API exposure, without moving the underlying records off the mainframe. The core idea is to leave the system of record in place and add a translation and access layer on top of it, rather than treating "AI-ready" as synonymous with "migrated."

This matters because most banks and insurers have already made a bet on caution over speed. According to Celent's 2025 IT Spending in Banking report, roughly 72% of global banking IT budgets go toward maintaining existing legacy systems, leaving comparatively little room for large-scale replacement projects. Rewriting or migrating core systems that process this much daily transaction volume carries real operational risk, so the practical question for most institutions isn't "should we migrate," it's "can we get value from this data as it sits today."

Why isn't legacy data already AI-ready?

Legacy data isn't AI-ready because it was designed for batch, record-oriented processing decades before anyone anticipated embeddings, semantic search, or LLM context windows, not because the data itself is low quality.

Three specific characteristics of mainframe data create friction for AI systems:

• Fixed-format records. VSAM data is stored as flat, positional byte layouts rather than named fields, so a value's meaning is defined by its offset and length, not a label.
• Copybook-defined structure. COBOL copybooks describe how to interpret those byte layouts, but they're written for compilers, not for anything resembling a JSON schema or a vector embedding pipeline.
• No native semantic layer. There's nothing in a VSAM file that tells an LLM "this field is a policy number" versus "this field is a claim amount." That mapping exists only in application code, documentation, or institutional memory.

This is why data can be simultaneously business-critical, accurate, and still practically invisible to an AI system without an intermediate translation step.

What are VSAM record types, and why does the type matter for AI access?

VSAM (Virtual Storage Access Method) supports a few core record organizations, and which one you're dealing with affects how straightforward AI-oriented access will be:

• KSDS (Key-Sequenced Data Set): records are stored and retrieved by a defined key, similar in spirit to an indexed database table. This is the easiest VSAM type to expose as a queryable API, since the key structure already gives you a natural lookup pattern.
• ESDS (Entry-Sequenced Data Set): records are stored in the order they were written, addressed by relative byte address. There's no built-in key, so exposing this cleanly usually requires adding an index or key mapping in the access layer.
• RRDS (Relative Record Data Set): records are addressed by a fixed relative record number, which works well for sequential or slot-based access patterns but doesn't map naturally to arbitrary lookups.

For AI use cases specifically, KSDS files tend to be the fastest path to value, since their key structure lines up well with the kind of "look up this customer/policy/account" query an AI agent or RAG pipeline actually needs to make.

What does "augmenting" legacy data for AI actually mean in practice?

Augmenting legacy data means adding a structured, semantic, and accessible layer on top of the existing records, without altering the records themselves. Concretely, that usually involves four things happening together:

1. Schema translation: converting the copybook's positional field definitions into a named, structured format (JSON, XML, or a relational-style schema) that downstream systems can actually parse.
2. Metadata enrichment: attaching business meaning to fields that otherwise have none: labeling a raw field as "policy_number" or "claim_status," documenting valid value ranges, and recording data lineage.
3. Real-time API exposure: wrapping read (and where appropriate, write) access to the underlying VSAM data in a REST or event-driven API, so modern applications and AI agents can query it like any other service instead of requiring a mainframe session. In practice, this looks like exposing dataset content over HTTP with server-side filtering, for example, reading only records matching a status or amount condition, rather than pulling the entire file and filtering client-side.
4. Embedding generation: once data is available in structured, labeled form, it can be selectively converted into vector embeddings for semantic search or RAG retrieval, for example, turning claim-history summaries or policy terms into embeddings an LLM can search against for context.

None of these four steps requires moving the VSAM file itself. They're additive: the mainframe keeps doing exactly what it's doing today, while a parallel layer makes that same data legible to modern systems.

How does this compare to other legacy-integration approaches?

There's no single right answer here. The right approach depends on latency requirements, write-vs-read needs, and how much existing investment you have in each layer.

Approach	What it does	Best for	Tradeoff
Full migration	Moves data and/or logic off the mainframe entirely	Systems being sunset or fully replatformed	Highest cost and risk; long timelines; not reversible easily
Data virtualization / APIzation	Exposes existing data via API without moving it	AI/RAG use cases, real-time lookups, incremental modernization	Adds a dependency layer; mainframe still needs to be available and performant
Change data capture (CDC)	Streams changes from the mainframe into a modern data store as they happen	Analytics, near-real-time dashboards, feeding a data lake	Introduces data synchronization and consistency considerations
Copybook-to-schema translation	Converts copybook structure into a reusable schema definition, often as a first step before APIzation	Any project needing structured access to raw VSAM/COBOL data	Requires accurate copybook parsing; garbage-in-garbage-out risk if copybooks are outdated or undocumented

For most banks and insurers exploring AI use cases specifically, data virtualization/APIzation, often combined with copybook-to-schema translation as the underlying step, offers the best balance: it's fast to stand up, doesn't touch the system of record, and directly produces the kind of structured, queryable interface an AI agent needs.

Why is API-based access a better fit than RPA for AI-driven legacy access?

RPA (screen-scraping a mainframe's terminal interface to move data) is a reasonable stopgap for simple, low-volume tasks, but it's a poor long-term foundation for AI initiatives specifically, for three concrete reasons.

RPA breaks when the interface changes, and AI workloads make that worse, not better. RPA bots interact with legacy systems by simulating keystrokes and screen navigation, so they depend on the screen layout staying constant. Industry analysis of workflow automation approaches finds RPA failure rates of 25-35% in environments with frequent UI changes, along with 40-60% higher maintenance costs over time compared to more stable integration methods. One industry estimate puts the share of RPA maintenance cost attributable specifically to UI changes, rather than new business logic, at 60-70%. An AI agent making frequent, unpredictable queries against a system multiplies the number of interaction points that can break, the opposite of what you want underneath a production AI workload.

RPA is inherently slower than API access, since it has to navigate a UI step by step rather than making a direct data call, a meaningful problem when an AI agent needs a fast response to stay useful in a live conversation or workflow, rather than a batch job that can tolerate delay.

RPA typically requires broader access privileges than a well-scoped API. Because a screen-scraping bot needs to operate the interface the way a human user would, it often needs full "user"-level access to the terminal session, rather than a narrowly scoped, read-only credential limited to specific fields. For regulated banks and insurers, that's a meaningfully larger attack surface and a harder thing to audit than a purpose-built API key, which cuts directly against the compliance requirements discussed below.

None of this means RPA has no place. It remains a legitimate, fast way to bridge a genuine short-term gap where no other integration path exists yet. But building a durable AI initiative on top of RPA-scraped data means inheriting all three of these weaknesses permanently, rather than treating them as temporary bridge costs. The augmentation approach described above (schema translation and real API exposure) produces a more stable, faster, and more auditable foundation, which matters more for an AI system running continuously in production than for a one-off automation task.

A worked example: claims data in a hypothetical regional insurer

Consider a hypothetical regional insurer (not a real company) running its claims processing on a VSAM KSDS file, with claim records keyed by claim number and containing policyholder ID, claim type, status code, and adjuster notes as a fixed-length text field.

Today, an adjuster or a batch job accesses this data through a mainframe terminal session or a nightly extract. To make it usable for an AI-powered claims assistant, the flow would look like this:

1. A copybook-to-schema translation step converts the fixed-format claim record into a structured JSON object, with named fields: claim_number, policyholder_id, claim_type, status_code, adjuster_notes.
2. Metadata enrichment attaches business context: status_code values are mapped to human-readable labels ("open," "pending review," "closed"), and claim_type is linked to a shared taxonomy used elsewhere in the business.
3. A real-time, RACF-authenticated API is exposed so a claims-assistant application can look up a claim by key and receive the structured JSON response, live from the mainframe, without a batch delay, while still respecting the same dataset permissions the claim record already had under RACF.
4. The free-text adjuster_notes field is periodically embedded into a vector store, so an LLM-powered assistant can be asked something like "summarize open claims involving water damage from the last 90 days" and retrieve semantically relevant notes, even though the underlying data was never designed to support that kind of query.

The mainframe claims system itself never changes. What changes is that a new layer now understands and exposes what was previously locked inside a fixed-format file, and every request still runs under the caller's own mainframe identity, not a shared service account.

What compliance and security considerations apply specifically to banks and insurers?

Regulated industries need to treat the augmentation layer with the same scrutiny as the core system it's exposing, not as a lower-stakes side project. Three areas deserve specific attention:

• Data residency. If any part of the augmentation pipeline (schema translation, embedding generation, or API hosting) runs in the cloud, confirm where that processing and storage physically occurs relative to applicable data residency requirements for the institution's jurisdiction.
• PII handling. Fields like policyholder ID, account number, or adjuster notes may contain personally identifiable information. Metadata enrichment should include PII classification as a first-class step, not an afterthought, so downstream AI systems can apply appropriate masking or access controls automatically.
• Audit trail and write control. Reads and writes through the new API layer should be logged with enough detail to reconstruct who, or which AI agent, accessed what data and when. A concrete pattern worth adopting: keep write operations (insert/update/delete) disabled by default at the API layer, and require an explicit authorization step (static configuration or a short-lived token) before any AI agent or application can mutate a record, even if it can already read one. That way, giving an agent read access to a legacy system doesn't implicitly give it write access too; the two are separate decisions, and reads keep working under the caller's own identity either way.

None of this is unique to AI use cases specifically. It's the same governance discipline regulated institutions already apply to any new system with access to core data. The difference is that AI systems tend to access data more broadly and more autonomously than a human user would, which makes getting this right upfront more important, not less.

Where does a platform like OpenLegacy fit in?

This isn't hypothetical tooling. It maps directly onto specific capabilities in the OpenLegacy platform. OL Z Gateway exposes VSAM KSDS records directly as HTTP APIs, including read, insert, update, and delete by key, which is exactly the kind of real-time, governed access the claims example above depends on. For broader legacy asset discovery and API generation across mainframe and IBM i systems, not just VSAM specifically, OL CoreIQ automatically discovers and exposes those legacy assets as governed APIs.

OL CoreIQ also ships its own MCP layer today: an AI assistant can connect directly using the same host login a person would use, with credentials scoped to that session and never stored, so no separate platform is needed to get started. Centralized governance of that access through OL Hub's shared identity and access-control layer (the same SSO-based model OL Hub already provides for OL Integration's MCP) is on the roadmap for CoreIQ but not yet wired in. In the meantime, CoreIQ's per-host login model is itself a reasonable governance boundary: access is scoped to whatever that mainframe login already permits, and nothing is persisted beyond the session.

The augmentation approach described in this post doesn't require a specific vendor to work in principle, but purpose-built tooling for schema translation and API generation, like the products above, meaningfully shortens the path from "locked in a fixed-format file" to "queryable by an AI system," without the fragility tradeoffs that come with an RPA-based bridge.

The bottom line

Legacy VSAM data doesn't need to be migrated to become useful for AI. It needs to be translated, labeled, and exposed through an API layer that sits alongside the system of record rather than replacing it. RPA can bridge a genuine short-term gap, but its fragility, latency, and broader access requirements make it a weak permanent foundation for a production AI system. For banks and insurers weighing where to start an AI initiative, augmenting existing mainframe data through real API access is typically faster to make durable, lower-risk, and produces value sooner than committing to a full migration, or a long-term RPA dependency, before any AI use case has even been validated.