---
title: "Migrate data to an AI agent while your team keeps working"
description: "How to extract data, test an agent in parallel, and reconcile changes at final cutover, with clear source authority and a rollback plan."
author: "Carlos García"
published: 2026-10-27
updated: 2026-10-27
language: en
human_url: "https://kiia.cloud/blog/migrate-data-to-an-ai-agent-without-downtime/"
---

> **In 60 seconds:** The first extraction lets you test the agent against a dated copy. While the team keeps working in the old software, that copy accumulates differences. Preserve the original, keep stable identifiers, and validate fields, relationships, and missing records. Define which source owns each fact and who resolves conflicts. Before the final switch, close source writes or route new arrivals to a traceable queue, apply the delta, and reconcile through an explicit cutoff time. Switch to the new system with human approval and a rollback plan that covers work recorded afterward. Keeping operations moving may require a brief pause in writes; do not promise an uninterrupted transition before testing it.

Suppose a team tracks its work in a case management tool. It exports records to the system the agent will query and starts testing questions. During that week, someone opens a new case, another person corrects a status, and an owner archives a record in the old tool.

The agent can answer correctly about the initial copy while missing those changes. The test needs another question: up to what point does this database represent the operation?

This example and the identifiers below are synthetic. The procedure applies to a lightweight CRM, a master spreadsheet, or a case management system. Extraction and change tracking capabilities must be checked in each environment.

## 1. Separate the initial load from final cutover

Plan an initial extraction, a period of parallel testing, and a final migration of differences. You may need several reconciliations during the parallel period. The last one is complete only when you can account for every change through the cutoff.

Name an operations owner to approve the result and resolve business conflicts, and a technical owner to run loads, record failures, and prepare rollback. Agree which missing fields or relationships block the switch. A case without its official identifier may prevent a reliable lookup even when the rest of the record imported successfully.

[The invisible tax of copying data between systems](/blog/cost-of-copying-data-between-systems/) covers the daily cost of maintaining copies. Here the work is closing a transition while operations are still active.

## 2. Extract the complete scope and preserve the original

Inventory the entities in scope: active and historical records, relationships, notes, and required attachments. Check filters, pagination, fields omitted by the export, and file references. If something cannot be extracted, record the limitation and its owner. A downloaded file does not prove complete coverage.

Save the extraction unchanged in a repository with restricted access. Transform a separate copy and retain the mapping between source and destination fields. Record:

- source system, extraction scope, and filters;
- read start and end times, time zone, and consistency point, if available;
- batch identifier, file version or fingerprint, and counts by entity;
- for each record, source ID, source, extraction time, and available version or last modification time;
- destination ID, transformations applied, and import outcome.

Extraction time tells you when you read a record. It does not establish when the underlying fact was updated. If that time is unknown, store it as unknown. If an export runs while records are being edited and provides no consistent snapshot, document that limitation and prepare a later comparison that also covers that interval.

Keep a stable key, such as `(source system, source ID)`. Using a name as the key can merge two different entities or duplicate one that changed its name.

## 3. Validate content and coverage after loading

Compare source and destination identifier sets. Alongside counts, check required fields, types, dates, relationships, and attachment access. Two databases can contain the same number of rows and different records.

| Synthetic finding | What to check | What to do |
| --- | --- | --- |
| `CASE-A` arrived without an owner | Whether the source lacks the value or the mapping lost it | Fix the mapping or request the value; do not infer it |
| `CASE-B` appears twice | Source keys and the identity rule | Review the match before merging |
| `CASE-C` exists in the official source and in none of the earlier databases | Identity, authorized scope, and official evidence | Open a pending record for review with its provenance |
| A document has a reference but will not open | File existence, link, and permissions | Record the gap and block answers that depend on it |

Distinguish a record skipped during loading from one that was never in the earlier databases. Detecting the latter requires comparison against an authorized official inventory, when one exists and is available. Without it, mark coverage as unverified instead of claiming the migration includes everything.

Create a gap queue with the ID, affected field or relationship, sources checked, evidence, reason, owner, and closure condition. Empty, contradictory, and unverified values need different states. The agent can gather evidence and prepare a review; a person decides uncertain additions and merges.

## 4. Tell the agent which source has authority

Authority belongs to each fact. An external source may own a case's official status, while the internal system owns its assigned staff member and next task.

| Data | Authoritative source | Role of the migrated database |
| --- | --- | --- |
| Official status | Designated official source, queried with authorization | Dated fallback when the official query fails |
| Assigned owner and internal notes | Operational system designated for that phase | Copy during testing; primary record after cutover |
| Agent summary | Linked evidence and versions consulted | Derived content kept separate from original facts |

If the official source does not respond, the agent may show the fallback when the process allows it, with a specific warning: “I could not query the official source. The migrated copy shows an open status, observed at T0; it may be outdated. Verify it before acting.” In production, display T0 as a readable date and time.

An official “no results” response requires an identity and scope check. It is different from an outage and does not authorize silently replacing it with a copy. Retain both pieces of evidence when they disagree. Deadlines and other sensitive actions must remain pending when required verification is missing.

The [litigation second brain](/blog/litigation-second-brain-ai-agents-case-files/) develops the relationship between cases, documents, and review. The [SOP librarian agent](/blog/how-to-build-sop-librarian-agent/) applies a similar hierarchy to procedures and published versions.

## 5. Set rules for the parallel period

During testing, keep the old tool as the write location for the operational data it still owns. The destination receives identified loads; agent responses and proposals stay separate from those records. If the team needs to annotate the destination, give those notes their own fields that the next import cannot overwrite.

| Phase | Where the team works | What the destination allows |
| --- | --- | --- |
| Parallel testing | Old tool for new records and operational changes | Queries and proposals; no real external messages or writes |
| Closing the delta | Source closed to writes; new arrivals in a controlled queue | Loading and reconciliation, with outgoing automations paused |
| Approved cutover | New system | Authorized writes; old tool read only |

Operations resolves conflicts about meaning; the technical owner fixes transformations and retries. Avoid “latest wins” when fields have different owners. If an unexpected edit appears on both sides, retain both versions and send the conflict for review.

## 6. Calculate and apply the final delta

Call the initial extraction point T0 and the cutoff time Tc. The delta must cover additions, updates, and deletions between those points, along with any gap during the first read interval.

If the source offers versions, a change history, or reliable modification timestamps, check their meaning, time zone, precision, and handling of deletions before using them. Read with overlap around the last confirmed checkpoint and deduplicate by ID and version to cover interval boundaries. Advance the checkpoint only after applying and validating the batch.

Without that history, take a fresh full extraction and compare by ID and a fingerprint of normalized fields owned by the source. A missing ID may indicate a filter, an export failure, or a deletion. Verify the reason before deleting anything.

| Change since T0 | Treatment at Tc |
| --- | --- |
| New `CASE-D` | Create it while retaining the source ID |
| Corrected status for `CASE-A` | Update the field owned by the source and retain its history |
| Confirmed deletion of `CASE-B` | Apply the agreed archive or deletion rule, including the agent's search index |
| Test note created at the destination | Keep it separate; do not overwrite it during import |

Rehearse the delta before Tc. Repeating a batch must leave the same result without duplicating records or triggering notifications. Record which rows were applied, rejected, or left in conflict.

At Tc, close every source write channel, including integrations and scheduled jobs. If requests must keep arriving, capture them in a queue with an ID, time, content, and owner. Apply the final delta, reconcile IDs and critical fields through Tc, and verify the indexes the agent queries. After approval, process the queue once in the destination and reconcile its outcomes.

Schedule the cutover with operations and support available. If you cannot close writes or capture every change, keep the parallel period open until you can. The [AWS cutover guide](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html) describes freezing ingestion, backing up, synchronizing, and validating before completing a migration. That pattern informs this sequence; it does not require using its platform.

## 7. Cutover checklist and rollback

Before authorizing the switch, review these items with operations:

- [ ] Original extraction and final backup retained; restoration rehearsed and mapping versioned.
- [ ] Tc, time zone, scope, and closure of every source writer confirmed.
- [ ] Additions, updates, and deletions reconciled; failed batches and blocking gaps resolved.
- [ ] Remaining exceptions accepted by a named owner, with limited scope and a review date.
- [ ] Agent queries tested against new, corrected, and archived records, including an unavailable official source and an outdated fallback.
- [ ] Permissions checked by role, without widening access during migration or index rebuilding.
- [ ] Queued arrivals accounted for and rules for resuming automations approved.
- [ ] Go/no-go owner, rollback conditions, and observation window agreed.

Define rollback triggers before cutover: a broken critical relationship, changes that cannot be reconciled, or unauthorized access, for example. Agree who stops writes and who decides whether to fix the destination or return to the source.

If no new destination writes have occurred, you can return to the preserved source after checking its state. If they have, first preserve those changes and the pending queue, compare them, and reapply them to the chosen system under review. Restoring the earlier copy without recovering later arrivals would lose work.

Keep the old tool read only during the agreed window. Permanent retirement follows acceptance, dependency checks, preservation of the required archive, and closure of the rollback window. You can retain a recovery path without keeping two systems editable.

## Sources and scope

Official references reviewed on **October 27, 2026**. Alongside the cutover guide cited above, the [AWS DMS data validation documentation](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) describes comparing source and destination rows and reporting mismatches. We use it as a reconciliation reference; the authority rules, gap queue, and examples in this article are design proposals. We assume no export or API capabilities in a particular tool and make no promise of zero interruptions.

To prepare a transition with Kiia, bring an anonymized schema, your source map, and the current editing rules. Those inputs let us define the initial extraction, tests, and cutover acceptance criteria.

## Frequently asked questions

### Can I keep using the old software while testing the agent?

Yes, if you define where each change is recorded and how it reaches the destination. During testing, keep the old software as the only write location for the data it still owns. Date the initial copy and bring subsequent changes across through controlled reconciliation.

### How do I recover changes made after the first extraction?

Compare stable identifiers and reliable versions or modification timestamps, covering new records, updates, and deletions. Without that history, compare a fresh full extraction against the original and review the differences. Before final cutover, stop source writes or route incoming work to a traceable queue until the delta is closed and validated.

### When can I shut down the old tool?

After reconciling the delta through the cutoff time, resolving blocking gaps, testing queries and permissions, and obtaining the owner's approval. First keep it read only during the agreed rollback window. Permanent retirement requires checking the historical archive, dependencies, and applicable retention requirements.