Migration Control Tower

A governed fleet of AI agents that discovers a legacy data estate, plans its migration to BigQuery, proves every row actually moved, and cuts over only with human approval.

Comment

Migration Control Tower — A Governed Agent Fleet for Autonomous Data Migration

Submission for the All Things Agentic Hackathon — Fortified Enterprise Fleet track.

Live product overview · Launch the live Control Tower · Watch the unedited demo · Source repository · Architecture pack

Migration Control Tower overview showing governed migration operations, estate posture, and run evidence

Inspiration

Enterprise data migration is rarely blocked by the absence of another copy tool. The real difficulty is coordinating discovery, dependency analysis, risk, sequencing, execution, validation, recovery, evidence, and approval across teams without losing context or weakening governance.

In many migration programs, this coordination still happens through spreadsheets, tickets, chat messages, and weekend runbooks. Teams may know that rows moved, but cannot always prove which plan was approved, which agent or person made a decision, which policy controlled it, what changed after a failure, or whether the target truly matches the source.

That inspired Migration Control Tower: not a one-off migration script, but a governed control plane for a fleet of institutional agents. It connects to an estate, discovers its assets, constructs lineage, assesses risk, creates a dependency-safe plan, dispatches scalable data movement, validates the result deterministically, learns from confirmed remediations, and permits cutover only after independent human approval.

The architecture follows one rule:

Models interpret. Deterministic code decides.

Gemini can enrich metadata, infer evidence-linked lineage candidates, explain a plan, and propose a recovery. It cannot grant permission, change source facts, declare reconciliation successful, expand approved scope, or approve cutover. Those outcomes remain controlled by typed schemas, policy code, numerical comparisons, legal state transitions, and a separate human identity.

What it does

Migration Control Tower provides a complete operator workflow:

  1. Onboard an estate using a source adapter, a sanitized connection profile, a Secret Manager reference, a target, and an approved Migration Pack.
  2. Validate connectivity without sending credentials to the browser or storing secret values in estate documents.
  3. Discover and assess tables, columns, pipelines, PII exposure, anomalies, dependencies, compatibility risks, and migration readiness.
  4. Build lineage from primary/foreign keys, parsed SQL, declared pipeline reads/writes, and evidence-bound AI candidates.
  5. Create a migration plan with explicit targets, dependency-safe waves, concurrency controls, rollback information, approved scope, and a canonical plan hash.
  6. Execute data movement through Cloud Run Jobs. The bulk data plane does not use an LLM.
  7. Reconcile deterministically using source/target counts, key integrity, aggregates, hashes, tolerances, and current-run execution evidence.
  8. Investigate and remediate failures using prior confirmed memory and bounded Gemini reasoning, followed by deterministic re-execution and re-validation.
  9. Require independent approval bound to the exact run, plan hash, evidence, requester, approver, and expiry window.
  10. Retain audit evidence including state history, agent versions, tools, model usage, policy decisions, trace IDs, data-plane job IDs, approvals, immutable PDF/JSON reports, and SHA-256 hashes.
  11. Answer operator questions through a read-only Gemini assistant whose factual responses cite authorized Control Tower evidence.

The production GCP deployment: public console, durable events, private agent services, Cloud Run Jobs, and retained evidence

Features and functionality

  • Oracle Redwood-style responsive operations console with Overview, Estates, Assessments, Waves, Runs, Lineage, Reconciliation, Policies & Approvals, Agents, Evaluations, Incidents, Memory Bank, Dead Letters, and System Health.
  • Plug-and-play estate onboarding through adapters and Migration Packs instead of source-specific branches inside core agents.
  • Capability-based agent discovery and version pinning through an approved Agent Registry.
  • Durable Pub/Sub workflows and a Firestore-backed legal run state machine.
  • Transactional message leases, idempotency, bounded retry, terminal failure archiving, dead-letter handling, and wave-slot release.
  • Per-estate Firebase roles, independent approval, OIDC-authenticated service-to-service calls, and least-privilege service accounts.
  • Bounded Gemini 3.7 Flash reasoning with structured outputs and evidence references.
  • Deterministic validation and policy enforcement isolated from untrusted free text.
  • Persistent Memory Bank for confirmed cross-run remediation knowledge.
  • OpenTelemetry traces, Cloud Trace correlation, model/tool audit events, token usage, cost evidence, and immutable reports.
  • Read-only Gemini 3.5 Flash assistant with streaming Markdown answers and citations back to console evidence.
  • Explicit not_configured and stale states instead of fabricated health, cost, or scale metrics.

Fortified Enterprise Fleet alignment

Track capability How Migration Control Tower implements it Evidence
Agent Registry Agents are published as versioned cards, reviewed separately, approved, discovered by capability URN, and pinned to runs. The orchestrator resolves capabilities instead of importing agent implementations directly. Agent fleet architecture
Agent Runtime Pub/Sub drives long-running asynchronous stages. Firestore records write-ahead run state, message leases, attempts, operation IDs, results, and legal transitions, allowing work to survive redelivery and process restarts. Orchestrator state machine
Memory Bank Confirmed incidents are stored by defect signature and recalled across later runs. A memory entry is advisory: every reused remediation must still pass fresh deterministic reconciliation. Memory and recovery evidence
Agent Identity The public UI, orchestrator, Pub/Sub invoker, and private capability services use separate IAM service accounts. Private Cloud Run dispatch uses signed OIDC identity tokens and exact service audiences. Deployment architecture
Agent Gateway A typed capability envelope carries capability, schema version, run/estate scope, request ID, and trace ID. Registry approval, role checks, estate authorization, and deterministic policy checks gate execution before tools run. Governance documentation
Model Armor / guardrails Managed Model Armor was not available in this deployment, so the project labels its substitute honestly: untrusted content is contained in a typed envelope, scanned deterministically, excluded entirely from authority paths, and tested against a 12-payload injection corpus. Model output is schema-validated and cannot call operational write tools. Injection containment tests
Agent Observability OpenTelemetry context follows capability dispatch into Cloud Trace. Append-only agent execution events retain model/framework version, prompt/schema version, evidence, tools, status, latency, tokens, cost basis, fallback state, validation result, and a concise final rationale—never private chain-of-thought. Agent audit trail

The agent decision and generation trail exposes evidence, tools, model usage, validation, and distributed trace identifiers

How we built it

The system separates the control plane from the data plane.

The control plane is a fleet of seven specialized capability agents—Discovery, Lineage, Risk, Planner, Validation, Cutover, and Finance—coordinated by a private orchestrator. Registry cards describe each agent's capability, approved version, runtime, identity, model configuration, prompt version, and output schema. Pub/Sub events move the run forward, while Firestore is the durable system of record for runs, catalogs, plans, lineage, policy decisions, message processing, approvals, memory, agent audit events, and report metadata.

The data plane is a Cloud Run Job that streams measured source rows into BigQuery. It is deliberately model-free. Validation reads the current run's execution manifests and refuses to pass if any scheduled target lacks a COMPLETED job belonging to that run. This prevents stale target data from making a failed or empty migration appear successful.

Gemini 3.7 Flash with high thinking is used only for bounded, reasoning-heavy stages such as discovery enrichment, evidence-linked lineage candidates, plan rationale, and recovery explanation. Gemini 3.5 Flash powers the read-only assistant. Every model response must satisfy a Pydantic schema and reference authorized evidence. Required reasoning failures fail visibly; optional fallback is recorded rather than hidden.

Technologies used

  • AI and agents: Gemini 3.7 Flash, Gemini 3.5 Flash, Vertex AI, Google Agent Development Kit, structured Pydantic outputs.
  • Google Cloud: Cloud Run, Cloud Run Jobs, Pub/Sub, Firestore, BigQuery, Cloud Storage, Secret Manager, Cloud Trace, Cloud Monitoring, Cloud Logging, Artifact Registry, Cloud Build, IAM, and optional Cloud Billing export.
  • Backend: Python 3.11, FastAPI, typed /api/v1 contracts, OpenTelemetry, SQL Server/PostgreSQL adapters, and deterministic policy/reconciliation services.
  • Frontend: Oracle JET 20.1.3, Preact, TypeScript, Redwood theme, Firebase Authentication, responsive drawers, accessible tables, and contextual inspectors.
  • Delivery: Terraform, Docker, immutable image digests, staged Cloud Run revisions, health probes, canary promotion, and rollback metadata.
  • Quality: Pytest, Vitest, Testing Library, Playwright, axe accessibility checks, CSP/XSS tests, injection corpus tests, and live-gated infrastructure tests.

Other data sources used

  • WideWorldImporters, Microsoft's sample SQL Server database, for the flagship seven-table migration and relationship-rich lineage demonstration.
  • A separate PostgreSQL retail estate to prove that onboarding another database engine requires configuration, an adapter, and a pack—not edits to the core agent fleet.
  • An Oracle dialect corpus for assessment-only compatibility analysis.
  • DAG artifacts for pipeline discovery and lineage metadata.
  • Live operational evidence from Firestore, Pub/Sub, BigQuery, Cloud Run, Cloud Trace, Cloud Storage, and an optional Cloud Billing export.

Cloud Run data-plane job evidence showing real source and target row movement rather than control-plane object counts

Challenges we ran into

Preventing AI from becoming an authority

The first challenge was drawing a hard boundary around model reasoning. An agent-generated explanation can be valuable; an agent-generated claim that customer data reconciled is unacceptable. We built separate paths so free text and model output cannot reach authorization or validation outcomes.

Making asynchronous execution genuinely durable

An early Pub/Sub helper acknowledged messages before handlers completed. A handler failure could therefore lose work permanently. A second race existed between performing a side effect and marking a message complete. We replaced that with transactional claims, renewable leases, acknowledgement only after success, safe stale-lease recovery, terminal error classification, bounded retry, and a dead-letter archive.

Catching a dangerous validation defect

During the flagship rehearsal, a transient SQL failure prevented current-run data movement, but validation could still see target data left by a previous run. We corrected the gate so validation considers only current-run completed execution manifests and run-isolated evidence. A data-plane blocker now makes PASSED structurally impossible.

Keeping credentials and tenant scope contained

The browser never receives source credentials. Estate profiles contain Secret Manager references or approved environment-variable names, and rejected API inputs are sanitized so secrets are not echoed in validation errors. Roles are estate-scoped, service calls are identity-signed, and the operator who requests a cutover cannot approve the same request.

Avoiding demo-only metrics

It was tempting to fill an enterprise dashboard with attractive zeroes and green health cards. Instead, every metric carries freshness and provenance. Actual billing remains unavailable until Cloud Billing export is configured; scale panels say not_configured until a measured report exists.

Accomplishments that we're proud of

  • Completed a recorded SQL Server 2022 to BigQuery flagship migration across seven selected targets and five dependency-aware waves.
  • Deliberately injected 1% row loss into Sales.Orders, detected the mismatch, produced an evidence-linked diagnosis, ran a separate clean remediation job, and revalidated 73,595 source rows to 73,595 target rows before approval became available.
  • Preserved independent human approval: the operator could not approve the run they requested, and the approval was bound to the plan hash and reconciliation evidence.
  • Made lineage useful rather than decorative by deriving confirmed relationships from SQL Server foreign keys, SQL definitions, and pipeline evidence while keeping AI-only candidates explicitly proposed.
  • Built immutable assessment, complete-run, reconciliation, and approval/audit reports with authenticated PDF/JSON downloads and SHA-256 evidence hashes.
  • Added a cited, read-only assistant that can explain a run without gaining permission to change it.
  • Proved multi-estate portability with a PostgreSQL onboarding gate that fails if source-specific identifiers appear anywhere in the core agents.
  • Verified the submission release with 767 passing backend tests, 134 passing frontend tests, a clean Oracle JET production build, and a successful public website lint/build.

Independent human approval is bound to the exact plan and evidence rather than granted by the requesting agent

What we learned

  1. Autonomy needs boundaries, not vagueness. The most trustworthy agent is not the one allowed to do everything; it is the one that can complete valuable work independently inside explicit authority.
  2. Blocked is a valid production result. Composite keys, unavailable billing, missing evidence, stale telemetry, and unsupported execution packs are shown as blockers instead of guessed away.
  3. Idempotency must include the side-effect window. A “processed” flag after a handler is not enough. Claims, leases, created resource IDs, retry class, and completion must form one durable protocol.
  4. Memory is a hypothesis accelerator, not proof. A prior remediation can shorten investigation, but it must never bypass fresh validation.
  5. Auditability means showing the boundary. The UI distinguishes model-generated proposals from deterministic control decisions and exposes evidence, tools, versions, trace IDs, and fallback state without pretending to reveal private chain-of-thought.
  6. A second estate is an architectural test. Portability became believable only when PostgreSQL used the same agents without source-specific conditionals.
  7. Production dashboards should admit uncertainty. An explicit unavailable state is more operationally useful than an invented zero.

Try the live application

The following judging accounts have already been authorized and can use their own Google sign-in:

A temporary read-only account is also available for general evaluation:

The Viewer account can inspect estates, run timelines, lineage, reconciliation, agents, policies, system health, and retained evidence, but cannot start migrations or approve cutover. The temporary password will be rotated after judging.

What's next for Migration Control Tower

  • Add a composite-key capable extractor so currently blocked tables can migrate without weakening deterministic ordering and reconciliation.
  • Expand the Migration Pack catalog for Oracle, PostgreSQL, MySQL, SAP, and additional target platforms.
  • Add a Firestore-backed grants service when per-estate authorization outgrows Firebase custom-claim size limits.
  • Integrate managed Model Armor when it becomes available in the selected deployment configuration, while retaining the existing structural separation between untrusted content and authority.
  • Add change-data-capture and resumable incremental synchronization for low-downtime production cutovers.
  • Use measured Cloud Billing export data for actual per-run cost alongside the current usage-based estimate.
  • Expand load and chaos testing across regions, higher concurrency, and longer-running migrations.
  • Continue treating the control tower as a platform: new estates and capabilities should be published through configuration and the Agent Registry, not by modifying the orchestration core.

System Health exposes service readiness, telemetry freshness, model availability, storage, and queue evidence

Migration Control Tower was built for the All Things Agentic Hackathon to demonstrate that enterprise agent autonomy can be ambitious, useful, observable, and governed at the same time.

Built With

Share this project:

Updates

Submission history