Decide per table: migrate, historize, or archive — with a traceable compliance rationale instead of a PDF attachment.
In short: When a company changes platforms, each table needs a decision: does the data move into the new system, get archived, or get retained purely for legal compliance? The agent classifies legacy data into exactly these three categories — driven by GoBD and Swiss FADP requirements, plus industry-specific frameworks like BankG (Swiss banking), VAG (insurance), and GMP (pharma). Stack: Claude (Anthropic direct) or Azure OpenAI Switzerland for data residency, JiVS as the historization platform, structured output validated against a curated compliance ruleset. Result: hundreds of decisions in hours instead of weeks, each with reasoning and an audit trail. The compliance officer stays in the loop — the agent proposes, the human signs off.
When a company changes platforms, it has to decide for each table whether the data goes into the new system, gets archived, or is retained purely for legal reasons. Manually, that's weeks of compliance work. A data model with a few hundred tables — typical for grown ERP, banking, or insurance systems — means a few hundred individual decisions, each with its own regulatory rationale. The call isn't technical, it's compliance-driven: the same table can be migrated in one company and historized in another, depending on business context and retention obligation.
It gets more complex industry by industry. In banking, BankG and FINMA circulars introduce retention periods that run differently per data type — customer transactions, KYC records, internal voucher data. Insurers operate under VAG and industry-specific contract-data obligations; pharma adds GMP retention for production and batch data. Across the top of all of that sit GoBD (relevant when a German parent company is involved), Swiss FADP, and GDPR. Each table needs a defensible decision — and the rationale has to be audit-ready, not something to be reconstructed two years later from emails and Excel attachments.
The agent receives two inputs: the source schema (which tables, fields, and data types) and a structured retention ruleset (GoBD, Swiss FADP, plus the industry-specific frameworks relevant to the company). For each table it evaluates the ruleset against the data characteristics — data type, presence of personal data, business relevance derivable from sample data — and classifies into one of three categories: migrate (data lives on in the new system), archive (removed from the active system but retrievable from an archive system), or historize (retained for legal purposes only, no active access, often with a deletion date). Each decision is written as a Decision Record with reasoning, the cited ruleset clauses, and a reference to the sample data — structured, not free text.
Model-side: Claude (via Anthropic direct) for longer reasoning chains over ruleset combinations; Azure OpenAI Switzerland when Swiss data residency is a contractual condition. Tool-side, the agent reads source schema and sample data via JiVS connectors, writes decision records into a searchable register, and produces an audit-log entry per decision. Guardrails: structured-output validation against the compliance schema, hard escalation on ruleset conflicts (e.g. BankG retention pulling against Swiss FADP deletion claims for the same table), cost caps per classification run, and a curated eval set of historically decided cases per industry.
Important: the agent doesn't make final decisions. It classifies, justifies, files. Historization decisions are regulatorily binding — anyone building black-box automation here risks fines no compliance officer will retroactively own. Instead, the agent moves the compliance work up the stack: away from reading individual table definitions, toward reviewing aggregated decision batches.
A Swiss bank — composite, not a real client — is preparing for a core-banking platform change. In the inventory: roughly 80 legacy tables from the predecessor system, a mix of regulatorily mandatory historization candidates (customer transactions with ten-year BankG retention, KYC records, voucher data for the tax authority) and tables with retention discretion (internal calculation helper tables, archivable reporting snapshots, technical audit logs). The agent — Claude via Azure OpenAI Switzerland for data residency, wired into a JiVS instance — works through the table inventory using the curated ruleset (BankG, FINMA circulars, Swiss FADP). For each table it produces a decision record: classification, cited ruleset clauses, reasoning text, deletion date (if historized), and a reference to the sample data the agent drew on for the classification. The compliance officer reviews the decision register in batches, escalates the ruleset conflicts, and signs off the rest.
Typical effect: historization decisions for several hundred tables emerge in hours instead of weeks — directional, not a published benchmark. Every decision ships with a traceable compliance rationale that references specific ruleset clauses rather than Excel-based experience. Auditors get a searchable decision register: per table, the classification, the ruleset, the reasoning, and the human confirmation as one connected record — instead of PDF attachments a compliance officer spent weeks assembling. As a side effect, a reusable ruleset emerges: the same classification logic carries through later platform changes or audit cycles, without someone restarting from scratch.
Migrating means: the data is actively moved into the new system and lives on there — it's part of the ongoing business process. Archiving means: the data is removed from the active system and placed in an archive system, but remains retrievable when needed — typical for reporting snapshots or audit access. Historizing means: the data is kept only because of legal obligation, with no business-process access, often with a defined deletion date at the end of the retention period. The call isn't technical, it's compliance-driven — the same customer-transaction table can be migrated in one company and historized in another, depending on the business context and the retention obligation in play.
Default coverage: GoBD (relevant where a German parent company or DE distribution presence is involved), Swiss FADP (the revised Swiss data-protection act), GDPR (EU scope). Industry-specific: BankG and FINMA circulars for Swiss banking, VAG for insurance, GMP retention for pharma and medical-device production data. The ruleset is held as a structured DSL — new frameworks can be added without rebuilding the agent itself. Important caveat: the agent interprets a ruleset that a compliance officer has curated and approved. It doesn't replace that compliance officer — and final regulatory responsibility stays with the client, not the tool vendor.
Every agent decision is a reasoned proposal, not a binding classification. Standard workflow: the compliance officer reviews the decision register in batches — typically filtered by industry, data type, or risk score — and signs off. For edge cases where the ruleset produces contradictory requirements (e.g. BankG retention pulling against an FADP deletion claim), the agent escalates directly to data protection or legal instead of proposing a classification of its own. The audit trail documents per table: who decided what when and why, which ruleset clauses were cited, which sample data was the basis. That turns later audits into a reading exercise rather than a reconstruction.
This use case sits in the Agent Systems & Workflows practice and connects to neighboring migration and audit use cases.
Practice: how agents are built, operated, and made audit-ready in production environments — patterns, guardrails, platform choice.
Prepare migration objects per backlog entry — parse schema, detect Z-tables, propose mappings, escalate cleanly.
Audit-ready diff reports with discrepancy classification and sign-off packages for cut-over.
Automatically reconcile Z-fields, Z-tables, and modified customizing entries against the standard data model.
Historization is a compliance decision, not a tooling problem. In a non-binding 30-minute discovery call we'll first talk through whether an agent is the right lever for your data structure at all.
Book a discovery call