Make old systems useful to AI without replacing them.
Critical records often sit in systems that are decades old: flat-file exports, green-screen ERPs, scanned archives, and databases with cryptic column names. Data.co connects to them as they are, normalizes the data, and puts it behind the same policy and audit as everything else.
Migration is the expensive answer to a reading problem.
Many modernization projects begin because people cannot get answers out of an old system. Full migration is slow, risky, and often unnecessary for that goal. The system still works; it is just hard to read.
Data.co reads from what the system can produce: database replicas, scheduled exports, report files, and document scans. It maps fields to understandable names, records lineage back to the source, applies classification labels, and makes the result available to search, RAG, and agents under policy. The legacy system remains the system of record.
From export file to governed dataset.
- 1
Connect
Use JDBC, ODBC, file drops, SFTP, or scanned-document ingestion, whichever the source supports.
- 2
Profile
Inspect fields, formats, code tables, and data quality issues before anything is exposed.
- 3
Normalize
Map cryptic fields to documented names, decode codes, standardize dates and units.
- 4
Label and link
Apply classification and record lineage so every value traces to its source row or page.
- 5
Expose under policy
Publish to the catalog, search, and agents with access rules like any modern source.
What we commonly connect.
Mainframe extracts
Fixed-width and EBCDIC files with copybook-based field definitions.
Legacy ERP and AS/400
Read-only database replicas and scheduled report outputs.
Scanned archives
OCR with page-level provenance, so extracted text links back to the image.
Access and spreadsheet sprawl
Department databases and workbooks consolidated with ownership recorded.
Retired systems
Read-only archives of decommissioned applications kept queryable for retention.
One legacy record, before and after.
An illustrative order-history extract from an older ERP. The source field names are typical of systems built around short column limits.
| Source field | Raw value | Normalized field | Notes |
|---|---|---|---|
| CUSNO | 0004471 | customer_id | Leading zeros preserved as text |
| ORDDT | 1240318 | order_date | Century-flag date decoded to a calendar date |
| STCD | H | order_status | Code table: H = on hold, documented by the business owner |
| UNPRC | 0001250 | unit_price | Implied two decimals, currency from the plant table |
| TAXID | Present | tax_identifier | Labeled PII; masked for analytics roles |
What makes legacy data trustworthy to an AI.
The risk with legacy sources is not that AI cannot read them; it is that it reads them confidently and wrongly. A status code that meant one thing before a 2009 process change and another after, a date field reused for a different purpose, or a duplicate customer table kept for a retired branch will all produce fluent, incorrect answers. Profiling exists to find those before anyone asks a question, and the mappings that resolve them are reviewed by people who know the system.
Success criteria are best written as checks your team can rerun: a set of questions with answers already known from existing reports, reconciliations of totals against the legacy system's own output, and a lineage trace for every value an answer cites. When a normalized dataset passes those checks and has an owner who will maintain its mappings, it is ready to be exposed to search, RAG, and agents under policy.
We do not write back to your legacy systems.
Connectors to legacy sources are read-only unless you explicitly configure otherwise, and any write path is subject to policy and approval.
Questions buyers ask
Do we have to migrate off the old system?
No. Data.co reads from it and leaves it as the system of record. Many teams later decide to retire a system once its data is accessible elsewhere, but that is a separate decision.
How do you deal with undocumented fields?
Profiling surfaces patterns and code values, and subject matter experts confirm meanings. Those mappings become documentation in the catalog.
Can AI help with the mapping work?
Local models can suggest field descriptions and mappings for human review. Accepted mappings are recorded as configuration, not left to a model at query time.
Is this a services engagement or software?
Both are available. The connectors and normalization run in Data.co Control; Managed Services can do the mapping work if your team lacks the time.
How much load does this put on the old system?
We prefer replicas and scheduled exports over queries against production, and schedule extraction around the system's batch windows. Source owners set the limits.
What about scanned documents with poor image quality?
OCR quality is checked during profiling, and pages that read poorly can be routed to human review or excluded. Every extracted passage links back to its page image, so a reader can check the original.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.