--- title: "The Migration That Never Ends" slug: "chapter-9-the-migration-that-never-ends" kind: "chapter" order: 10 label: "Chapter 9" chapter: 9 part: "The Data Layer" partLabel: "Part III" partNumber: 3 epigraph: "Every AI data platform project becomes an ETL project, and every ETL project is stale the day it ships." summary: "Ask a vendor how their AI system will know about your students, your customers, your contracts or your patients, and the answer almost always involves a word that should alarm a CIO: ingest. Your d…" words: 1114 topics: - "How the migration starts" - "What it actually costs" - "Why the copy is always wrong" - "The case for reading in place" - "What changes when the data stays put" --- Ask a vendor how their AI system will know about your students, your customers, your contracts or your patients, and the answer almost always involves a word that should alarm a CIO: ingest. Your data will be ingested. Exported, transformed, loaded, indexed and embedded into the vendor's store, where the model can reach it. The pitch frames this as a one-time step. It is never one time. This chapter is about why, and about the alternative that the Model Context Protocol has made practical. ## How the migration starts The first conversation is reasonable. The AI needs context. The context is in the student information system, the ERP, the CRM, the document management system, the ticketing tool. None of those systems was designed to be queried by a language model. So someone proposes a data platform: a central store into which the relevant data is copied, cleaned and shaped so that the AI can use it. A project is scoped. Six systems, four months, a team of three, plus the vendor's professional services. The budget is approved because the alternative, an AI that knows nothing, is clearly useless. Then the real work begins. Each source system has a data model that nobody fully documents. Each has permissions that the copy must somehow preserve. Each changes with every upgrade. The four months become nine. The team of three becomes five. And on the day the pipeline finally runs clean, it begins to decay, because the source systems keep changing and the copy does not know. ## What it actually costs Institutions rarely total the cost of these projects, because it is spread across budgets and years. When they do, the pattern is consistent. The build is the smaller part. The larger part is maintenance: every schema change upstream breaks something downstream; every new field someone needs requires a pipeline change; every permission model drift creates a compliance question about who can now see what in the copy. Teams that set out to build an AI capability end up running a data integration function, and the AI work waits. Then there is the second copy. The institution already has a data warehouse for reporting. The AI platform wants its own store, shaped differently. Now there are two copies, two pipelines, two sets of permissions to reconcile, and two answers to any question about what the institution's data says. And there is the exit cost from Chapter 4. The pipelines and the shaped data live in the vendor's platform. Leaving means rebuilding them. ## Why the copy is always wrong Even a well-maintained copy is wrong in three ways that matter to an agent acting on behalf of a person. It is late. A nightly sync means an agent answering a question at 9 a.m. is reading yesterday's data. For a student asking whether a payment posted, a nurse asking about a medication order, or a customer asking about an order status, yesterday is wrong. Streaming pipelines reduce the lag at the cost of complexity, but they do not eliminate it. It is permissionless. The source system knows that this advisor may see these students and not those. The copy, almost always, flattens that. Either the AI sees everything in the copy, which is a breach waiting for a prompt, or someone reimplements the source system's permission model in the copy, which is a second system to keep correct. It is partial. The pipeline copied the fields someone thought the AI would need. The question a real person asks needs a field nobody anticipated. The answer is a pipeline change, a ticket and a wait, and the agent says it does not know in the meantime. ## The case for reading in place The alternative is to leave the data where it is and let the agent reach it at the moment of the question, through the source system's own interface, with the asking person's own permissions. This was impractical when every integration had to be hand-built for every AI tool. It became practical when the industry converged on a standard for how an agent discovers and calls tools. The Model Context Protocol, introduced by Anthropic in November 2024, adopted by the other major model developers over the following year and now stewarded by the Linux Foundation, gives a connector a standard shape. A connector to the student information system, written once, can be used by any agent on any platform that speaks the protocol. Chapter 10 describes the connectors in detail and Chapter 11 the broker that governs them. What reading in place buys, concretely: The data is current, because the agent asks the source system now. The data is permissioned, because the connector calls the source system as the person who asked, or with a scope the broker derives from their role, and the source system applies its own rules. The data is complete, because any field the source exposes is reachable without a pipeline change. And there is no copy to govern, secure, reconcile or hand back when the vendor relationship ends. ## What changes when the data stays put A CIO who adopts reading in place as the default will notice four changes in how AI projects run. The first project gets faster. There is no ingestion phase. The team connects one system, through a connector that may already exist, and the agent is useful against live data within days. Syracuse University's first agent started with easily accessible materials and connected additional systems phase by phase, useful from the first week rather than after a migration. The data team gets its time back. Connectors are maintained against the source system's interface, which the source vendor keeps stable because their own clients depend on it, rather than against a bespoke pipeline. Governance gets simpler, not harder. The question "what can this agent see" has the same answer as "what can this person see," enforced by the systems that already enforce it, with an audit log of every call at the broker. And the institution keeps its leverage. Connectors written to a standard belong to the institution and work with the next platform too. The vendor that owns no copy of the data has no hold over the institution that the contract did not grant. There is one caveat. Reading in place depends on the source systems having usable interfaces, and some do not. A legacy system with no API still needs a copy, or an interface built in front of it. The sovereign approach is to make that the exception, scoped to the one system that needs it, rather than the default architecture for everything. The next two chapters describe how the default works.