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
-
Pull the first source's tables.
List every table in <LEGACY_SALES>.
-
Pull the second source's tables.
List every table in <CONFORMED_SALES>.
-
Match across both lists.
Match the two lists by name and structure; flag exact matches, close-but-not-identical matches, and anything with no counterpart.
-
List what exists on only one side.
Give me the tables that exist on only one side, split by which source, since those are the migration calls someone has to make.
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
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. This produces a comparison; nothing in either source gets modified, moved, or flagged.
Follow-up prompts
Keep going once the first answer lands.
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.
Tips & troubleshooting
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.