One prompt turns an unfamiliar source org into a documented rebuild plan you can work from. This article gives you the baseline, the lines you can add to shape it, and the full version at the end.
Point Swantide at the source org, the one you are migrating away from. That is the unknown you are documenting.
Before you start
Two things shape how you run this.
Swantide reads configuration, not records. It maps the schema you need to migrate, the objects, fields, relationships and automation. It does not read the rows inside them. For volumes, fill rates and data quality it writes you the SOQL and you run it, which is covered at the end.
It reads one org at a time. To compare the source against a target org you either connect the target in a second Swantide instance, or paste the target's schema into the conversation. There is no two-org diff button.
Also worth knowing before you scope the work: installed managed packages such as CPQ, OmniStudio or nCino show as installed, but their internals are not readable. Those are a re-license and re-install decision in the target, not a rebuild.
The baseline
Produce a migration plan for rebuilding this org in a new Salesforce org, and write it up as a document.
That gives you a document covering what is here, what it does and what order to rebuild it in.
Everything below is a line you add to it.
Set the lens
This is the one line that changes the character of the output most, so add it early.
For each component, say what it does, what it depends on, and whether to rebuild it, merge it into something existing, or retire it. This is a migration, so I am preserving business capability rather than grading quality.
Without it you get a technical debt review. With it you get a rebuild backlog.
Sequence it the way you will actually build.
Sequence the rebuild in dependency order: data model first, then the security model, then automation and code, then UI, then reporting.
Choose what comes first.
Rank by migration priority: what has to move before anything else can.
Rank by risk: what is most likely to break the cutover.
Narrow what it covers
The source org is usually large, so scope is what buys depth.
One domain at a time when you want the detail:
Cover only the data model: objects, fields, relationships and record types.
The domains worth running separately on a real engagement are the data model, automation, Apex and custom code, integrations and external dependencies, the security model, UI, reporting, and managed packages.
Or one part of the business:
Cover only what supports ‹the quote-to-cash process›.
Or a few named objects, which is what to do if a list comes back looking shorter than you expected:
Do this again for ‹Account and Opportunity› only.
Run the inventory first so you know which objects are the heavy hitters worth narrowing to.
Reconstruct the business process
Migrations fail on the process nobody documented, not the fields. This is the highest-value single addition for an org whose original builders have left.
Reconstruct the business processes this org supports, end to end, from its metadata. For each one, name the objects, fields, automations and validation rules involved at each stage, and say what a user is actually doing at that point. Flag any step whose intent you cannot determine from the configuration alone.
Change who it is for
Write it for the people who will do the rebuild.
Write it for the client's stakeholders who are approving the budget. Lead with what the migration protects and what it costs to get wrong.
Ask for more behind each item
Name the components.
Name the components behind every item, and say what each one depends on.
Get the queries alongside the numbers. A missed integration is what breaks a cutover, so having the SOQL next to each count is what lets you reconcile the list before you commit.
Flag any number worth confirming with a direct query before I commit to a plan, and give me the query.
Separate what the metadata can answer from what it cannot. Useful on its own, because the second list is your discovery backlog.
Where something depends on record data, user assignments or licence counts, put it in its own list with the SOQL that answers it.
Flag the guesswork. The most valuable thing an unfamiliar org can tell you is where it stops being self-explanatory.
Flag any step whose intent you cannot determine from the configuration alone.
Compare against the target org
When the target already exists, paste its schema in and ask for the crosswalk. This is the call that turns an inventory into a plan.
Here is the schema of the target org: ‹paste the target's objects and fields›.
For each component in the source org, say whether it already exists in the target, partially exists under a different name or shape, or needs building. Call out where the two collide: the same field name meaning different things, picklist values that do not match, and data types that will not convert cleanly. Give me the field-level mapping as a table: source field, target field, action, and what I need to reconcile.
You can get the target's schema out of Swantide by connecting that org and exporting the metadata as a CSV, or from a Salesforce report on your object definitions.
Shape the output
Make it an HTML file so it's presentable to a client.
End with a rebuild runbook in three phases, sequenced so each is additive and reversible, with the rollback position for each.
Do not use em dashes or en dashes anywhere in the document. Use a comma, a colon or a full stop instead.
The full version
Everything above, assembled, plus the wording that keeps the counts precise. Replace the bracketed values with your own.
Produce a migration plan for rebuilding ‹source org name› in a new Salesforce org, as an HTML file, written for the people who will do the rebuild.
Cover, in this order:
1. Executive Overview: what this org does, how big the rebuild is, and the three things most likely to go wrong.
2. Business processes: reconstruct them end to end from the metadata. For each, name the objects, fields, automations and validation rules involved at each stage, and say what a user is doing at that point.
3. Data model: objects, fields, relationships and record types, stated as custom versus total.
4. Automation: flows, workflow rules, Process Builders and Apex triggers, grouped by the object they fire on and by the package that owns them.
5. Apex and custom code: classes, triggers and their dependencies, separating native code from managed packages.
6. Integrations and external dependencies: named callouts, external objects, connected apps, and anything that reaches outside the org.
7. Security model: profiles, permission sets, permission set groups and sharing, and what has to be rebuilt versus re-derived.
8. UI and reporting: apps, layouts, record types, and the reporting that depends on the fields above.
9. Managed packages: what is installed, and which are a re-license decision in the target rather than a rebuild.
10. Rebuild runbook: three phases in dependency order, data model first, then security, then automation and code, then UI, then reporting. Each phase additive and reversible, with the rollback position for each.
For every component, say what it does, what it depends on, and whether to rebuild it, merge it into something existing, or retire it. This is a migration, so I am preserving business capability rather than grading quality.
Rules for the whole document:
- Rank by migration priority. Give me the highest-value items rather than a complete census, and do not certify that the list is complete.
- Report any count as either custom or total, and say which. Never blend them.
- Use one number per fact throughout. If two sections mention the same count, they must agree.
- Do not state that something is absent unless you have looked for it. Where you report none of something, give the query that establishes it.
- Flag any number that should be confirmed with a direct query before I commit to a plan, and give me the query.
- Stay inside what the metadata shows. Where something depends on record data, user assignments or licence counts, put it in a 'needs a human to confirm' list with the SOQL that answers it.
- Flag any step whose intent you cannot determine from the configuration alone.
- Do not use em dashes or en dashes anywhere in the document.
Two calls that stay separate
These are genuinely different questions, so run them on their own rather than folding them into the plan.
Sizing and profiling the data. Swantide reads configuration, so record questions come back as a query you run:
Write me the SOQL to size and profile the data behind ‹the Opportunity object›: row counts, how many records use each record type, fill rates on the fields that matter for the migration, and anything that will need cleaning before it moves. Tell me what to look for in the results.
Run it, paste the results back into the same conversation, and ask for the interpretation. That keeps the analysis with the plan.
The external ID and dedup strategy, once you have those numbers:
Based on those results, recommend the external ID and deduplication strategy for loading ‹Opportunity› into the target, and tell me the load order across the objects so the relationships resolve.
If you build your own prompt
The full version above ends with a short block of house rules. They are what keep the numbers consistent across a long document, so if you are assembling your own prompt rather than using that one, paste this on the end:
Report any count as either custom or total, and say which. Use one number per fact throughout, so any two sections mentioning the same count agree. Where you report none of something, give the query that establishes it. Rank by migration priority rather than claiming the list is complete. Where something depends on record data, user assignments or licence counts, put it in a 'needs a human to confirm' list with the SOQL that answers it. Flag any number worth confirming before I commit to a plan, and give me the query. Flag any step whose intent you cannot determine from the configuration alone.
After it runs
Drill into anything that matters.
Tell me more about ‹the integrations section›. Which components exactly, and what breaks if we do not rebuild them?
Add what is missing.
Add a section on ‹the reporting that depends on the fields being renamed›.
Say add to keep what is on screen and grow it. Say turn this into and it rewrites, replacing what was there.
Then build it. Once the spec exists, AI Admin generates and deploys the metadata into the target org, so the plan this produces is the thing it consumes.