---
title: "See exactly what a migration would leave behind - Atlan MCP Cookbook"
url: "https://atlan.com/mcp-cookbook/compare-two-sources-before-a-migration-decision/"
description: "Line up two connections, databases, or schemas and see what matches, what's missing, and what exists on only one side, before you commit to a migration."
---

> Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/

Recipe 30 in [The Atlan MCP Cookbook](https://atlan.com/mcp-cookbook/). Line up two connections, databases, or schemas and see exactly what matches, what's missing, and what only exists on one side, before you commit to a migration or consolidation plan.

Use case: Retire & migrate / Action: Look up / Persona: Data Engineer / Effort: Moderate / Runs in: any AI tool

Requires Atlan MCP connected to your AI tool: [set up Atlan MCP](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/remote-mcp-overview).

## 1. The task

**Scenario.** A migration plan says `LEGACY_SALES` is being replaced by `CONFORMED_SALES`, and someone needs to sign off that nothing gets lost in the switch. Eyeballing two schema browsers side by side in separate tabs misses the tables that only exist on one side, the ones that look the same but aren't, and the ones nobody's opened in two years. The decision needs an actual list, not a skim.

The ask:
- The full table list on each of the two sources
- Which tables match across both
- Exactly what exists on only one side, so nothing gets silently left behind

Hero prompt: "Compare every table in `LEGACY_SALES` against `CONFORMED_SALES`. Tell me which ones match, which exist only in `LEGACY_SALES`, and which exist only in `CONFORMED_SALES`."

Step by step:

1. Pull the first source's tables. Prompt: "List every table in [LEGACY_SALES]."
2. Pull the second source's tables. Prompt: "List every table in [CONFORMED_SALES]."
3. Match across both lists. Prompt: "Match the two lists by name and structure; flag exact matches, close-but-not-identical matches, and anything with no counterpart."
4. List what exists on only one side. Prompt: "Give me the tables that exist on only one side, split by which source, since those are the migration calls someone has to make."

## 2. What you'll give it

Required context:
- The two connections, databases, or schemas you're comparing, named exactly as they appear in Atlan

Optional context:
- Whether you want column-level comparison within matched tables, or just table-level presence
- A known list of intentional exceptions (tables that are supposed to be one-sided), so those don't show up as false alarms

## 3. What Atlan creates

Outputs:
- A matched list: tables present in both sources
- A one-sided list: tables that exist only in one source, split out by which one
- Optionally, a column-level diff for the tables that matched but might not be identical

**Summary.** You get an actual coverage report to sign a migration off on, not a gut check from skimming two browser tabs.

**Read-only.** Read-only. This produces a comparison; nothing in either source gets modified, moved, or flagged.

## 4. Follow-up prompts

- **Go column-level:** "Run this again at the column level for the tables that matched by name."
- **Check what's still in use:** "Flag any one-sided table that still has active downstream consumers."
- **Recheck before cutover:** "Re-run this the week before cutover."

## 5. Tips & troubleshooting

**Cook's note.** A name match isn't a content match. Two tables can be called the same thing and hold different data, or be called different things and hold the same data. Don't sign off on the name list alone.

- Match the client to the work.** Use a client that can hold a long output well, this comparison gets wide fast on anything beyond a handful of tables.
- Automate or chain it.** Run this as a recurring check throughout the migration window, not once at the start, so drift between the two sides shows up before cutover instead of during it.
- Ask what it changed.** Even though this is read-only, ask for the diff in a form you can attach to the migration ticket: a clean list of matched, missing, and one-sided tables, dated.

## Related recipes

- [Find the source you can actually trust](https://atlan.com/mcp-cookbook/find-the-trustworthy-replacement-source/): When the table you've always been pointed to stops reconciling, find the actual certified source instead of guessing at a second bad table.
- [Triage assets for migration](https://atlan.com/mcp-cookbook/triage-assets-for-migration/): Classify every asset by consumer count, ownership, and certification before migrating.
- [Safely deprecate unused assets](https://atlan.com/mcp-cookbook/safely-deprecate-unused-assets/): Verify no active consumers exist, notify owners, then mark assets as deprecated.

[Browse all recipes](https://atlan.com/mcp-cookbook/) / [Set up Atlan MCP](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/remote-mcp-overview)