A repeatable program of AI-Assistant prompts that reverse-engineers a source Salesforce org so its functionality can be recreated in a different (target) org. This covers any org-to-org migration — a consolidation (folding orgs into one instance), an acquisition, a divestiture / carve-out, or a re-platform / greenfield rebuild. Whatever the reason, the job is the same: learn what the source org actually built and why before rebuilding it. This program produces that blueprint — an inventory of everything in the source org, what each piece does, what it depends on, and a rebuild-vs-retire recommendation per item.

Discovery & rebuild-planning only — Swantide doesn't move data or auto-merge two orgs. Point Swantide at the source org; it documents that org so a human (or Swantide's AI Admin, later) can reconstruct it in the target org.

Swantide reads org metadata through an agentic engine that retrieves components iteratively. For a migration it's a fast way to understand and document the source org and draft the rebuild spec — then it can actually help build the pieces in the target. The honest limits to design around:

Net: this is a guided reverse-engineering + rebuild-planning program. Swantide turns an opaque source org into a documented, prioritized rebuild backlog — and where a domain is a genuine blind spot, the prompt says so and Domain 10 bridges the record-data gap.

⚠️ One caveat worth knowing: treat exact counts as approximate. Swantide is very good at surfacing what's there and what matters, but for a precise component census — or any number that gates a migration decision — confirm it directly against the org (a Salesforce report, Setup → Storage Usage, or a quick SOQL/Tooling query; Domain 10 shows the pattern). A missed integration or dependency is what breaks a cutover, so reconcile the lists that matter before you commit to a plan.

Two-tier rhythm: each domain has a Tier-1 scan (returns a prioritized rebuild list) → then you pick the items you're migrating and run the Tier-2 drill-down template on each, one per chat, to get the detailed rebuild spec. That's the "inventory everything, then fully document each piece we're keeping" flow.

Run this first. It sizes the source org and tells you where the complexity — and therefore the migration effort — is concentrated, so later domains can be narrowed to the heavy hitters.

I'm doing migration discovery on this Salesforce org — we're going to rebuild what it does in a different Salesforce org (our target). Discovery only — don't change anything. Start with a high-level inventory so I can scope the migration.

Break the org down by: custom objects, total custom fields, Apex classes, Apex triggers, Flows, Workflow Rules, Process Builder processes, validation rules, Lightning apps, page layouts, record types, profiles, permission sets, and installed managed packages. Give approximate counts for each.

Then tell me where the org is heaviest — which 5–10 objects carry the most custom fields, automation, and code — because that's where the migration work concentrates. Finish with a one-paragraph read on the overall size and complexity of what we're migrating.

The most important migration question isn't "what components exist" — it's "what does this org do for the business?" You're preserving capabilities, not files. This domain reverse-engineers the business processes so nothing critical is lost in translation.

Tier-1 scan — capability map:

Still doing migration discovery on this org — discovery only. I want to understand what this org actually DOES for the business, not just what components exist, so we don't lose a capability when we rebuild it in our org.

Working from the objects, automation, and record types, reconstruct the main business processes this org supports — e.g. lead-to-opportunity, quoting, case management, onboarding, renewals, whatever's really here. For each process, tell me: the objects involved, what automation drives it, and what it appears to accomplish end to end.

Give me the ~8–12 most significant processes, ranked by how central they look to the business. Don't certify it's the complete list; I'll dig into each. Table: process, objects involved, key automation, what it does, migrate/merge/retire (your first guess).

Tier-2 drill-down (one process at a time):

Focus on the "[PROCESS]" process in this org. Walk it end to end: which object a record starts on, every automation/validation/Apex step that fires as it progresses, the fields that carry its state, who touches it (which profiles/record types), and what the finished outcome is. Write it up as a process spec I could hand to someone rebuilding this exact capability in a different Salesforce org from scratch. Discovery only.

This is the foundation of the rebuild — everything else depends on the schema existing in the target first. The goal is a recreatable schema definition plus the relationship map.

Tier-1 scan:

Migration discovery, discovery only. I need to recreate this org's data model in our org, so document the schema. Work through the custom objects (start with the heaviest 5–8 from the inventory — tell me which ones you covered).

For each object give me: its API name and label, its record types, its key custom fields with their type (and for lookups/master-detail, WHAT they relate to), any external ID or unique fields, and its relationship to standard objects. Call out master-detail vs lookup relationships specifically, since those dictate the order we have to create things in.

Table per object: field API name, type, related-to (if lookup/MD), external ID?, required?, notes. End with a dependency order: which objects must be created before which.

Tier-2 drill-down (one object at a time):

Give me the complete field-level schema for the [OBJECT] object so I can recreate it exactly in another org. Every custom field: API name, label, data type + length/precision, whether required/unique/external-ID, default value, formula body (if a formula field), picklist values (if a picklist), and the related object + relationship type for any lookup/master-detail. Also list its record types and which fields differ by record type. Flag anything that can't be recreated with a straight field definition (formula dependencies, roll-up summaries that need the child object first, etc.). Discovery only.

Automation is where the business logic lives. For migration you need to know what each automation does well enough to rebuild it — and Salesforce has retired Workflow Rules and Process Builder, so anything on those should be rebuilt as Flow in the new org.

Tier-1 scan:

Migration discovery, discovery only. Inventory this org's automation so we can rebuild it in our org. List the Flows, Workflow Rules, Process Builder processes, and Apex triggers, grouped by the object they run on. For each: what it does in one line, what triggers it, and — since we'll rebuild in a modern org — whether it's already a Flow or needs to be rebuilt as Flow (Workflow Rules and Process Builder are retired).

Rank by how central the automation is to the business and cap at the ~25 most significant. State the total count if you can, but don't certify the list is complete; I'll confirm totals separately. Table: object, automation name, type, what it does, trigger, rebuild-as-Flow?, migration effort.

Tier-2 drill-down (one automation, or one object's automation, at a time):

Document the automation on the [OBJECT] object (or the specific [AUTOMATION] flow/process) in full detail so I can rebuild it in another org. For each automation: the exact trigger and entry criteria, every action it takes in order (field updates, record creates, emails, callouts), any formulas/decisions it evaluates, and the other components it depends on (fields, other flows, Apex it invokes). Note the order these fire relative to each other. Write it as a build spec, not a summary. Discovery only.

Apex has to be re-implemented in the target (code doesn't "merge"). You need enough to decide, per class, whether to port it as-is, rewrite it, or drop it (superseded by the target org's existing code). Swantide reviews logic well but isn't a linter and can't run tests.

Tier-1 scan:

Migration discovery, discovery only. Inventory the Apex in this org so we can decide what to port to our org. For each Apex class and trigger: what it does in one line, what invokes it (trigger / flow / LWC / scheduled / web service), its API version, and its dependencies (objects, other classes, external callouts). Flag anything that's tightly coupled to THIS org's specifics (hardcoded IDs, org-specific custom settings/metadata) since that won't port cleanly.

Rank by importance and surface the ~20 most significant; don't certify that's all of them. Table: class/trigger, what it does, invoked by, API version, dependencies, port/rewrite/drop (first guess), effort.

Tier-2 drill-down (one class at a time):

Show me the full body of the [ApexClass] class and document it for a port to another org: what it does, its public methods and what calls them, every object/field/setting it touches, external callouts and named credentials it uses, and its test class. Then list exactly what would have to change to run it in a different org (hardcoded IDs, org-specific references, dependencies that must exist first). Discovery only — don't rewrite it yet.

The highest-risk, most-missed part of any org migration. Automation and fields are visible; a named credential pointing at a billing system, a Connected App a partner authenticates through, or an inbound email service is easy to overlook — and each one breaks a live integration at cutover if it isn't rebuilt. Scan this early and thoroughly.

Tier-1 scan:

Migration discovery, discovery only. I need every way this org talks to the outside world, because these integrations have to be re-established in our org at cutover or things break.

Find and inventory: Named Credentials and External Credentials, Connected Apps (and OAuth/external client apps), Auth Providers, External Data Sources / External Services, Sites and Experience/Community sites, Email Services (inbound), Platform Events and Change Data Capture, outbound messages, and any Apex making HTTP callouts (list the endpoints). For each, tell me what external system it appears to connect to and what would have to be recreated/re-authorized in the new org.

Be thorough here rather than brief — a missed integration breaks cutover. State totals; don't certify completeness. Table: integration component, type, external system (best guess), inbound/outbound, what must be rebuilt in the target, criticality.

Tier-2 drill-down (one integration at a time):

Document the [NAMED CREDENTIAL / CONNECTED APP / INTEGRATION] in full: what external system it connects to, the auth method (OAuth, JWT, API key, etc.), which Apex/flows/components use it, the endpoints involved, and the exact steps to recreate and re-authorize it in a different org. Flag any secrets/certs that can't be read from metadata and will have to be re-obtained from the vendor. Discovery only.

The rebuild needs a working access model on day one. You're documenting profiles, permission sets, roles, and sharing so users have the right access in the target — and deciding what maps to the target org's existing roles vs. what's genuinely new.

Tier-1 scan:

Migration discovery, discovery only. Document this org's access model so we can reproduce appropriate access in our org. Inventory the Profiles and Permission Sets (and permission set groups), the role hierarchy, and the sharing model (org-wide defaults and sharing rules) for the key objects.

For each profile/permission set: who it's for (best guess from the name and grants), the notable object/field access and system permissions it grants, and how many users are on it if you can tell. Flag admin-level access (Modify All Data, etc.) since that maps to a small set of people. Note which look like they'd map to a role we probably already have vs. something new to the source business.

Rank by number of users / importance; don't certify completeness. Table: profile/perm set, who it's for, key access granted, admin-level?, maps-to-existing-or-new, notes.

Tier-2 drill-down (one profile / perm set at a time):

Document the [Profile / Permission Set] named [NAME] completely so I can recreate equivalent access in another org: every object with its CRUD level, notable field-level security, system permissions, assigned apps/tabs, and record-type visibility. Then tell me whether this is better recreated as a permission set (vs a profile) in the target, and what it would map to if the target already has a similar role. Discovery only.

The user-facing shell — Lightning apps, page layouts, record types, tabs. Rebuilding this is what makes the migrated capability usable, and it's where you decide "recreate their app" vs "fold their users into one of ours."

Tier-1 scan:

Migration discovery, discovery only. Document this org's user-facing UI configuration so we can decide how to present the migrated functionality in our org. Inventory the Lightning apps (what each is for, its nav items), and per key object the page layouts and record types (how many, and what distinguishes them). Flag app/layout/record-type sets that clearly belong to a specific team or business line — those are the units we'd either recreate or merge into an existing app of ours.

Rank by importance; don't certify completeness. Table: app/object, layouts, record types, who it's for, recreate-as-new-app / merge-into-existing (first guess), notes.

Tier-2 drill-down (one app or object at a time):

Document the [Lightning app "NAME" / the OBJECT's UI] fully for rebuild in another org: for an app — its nav items, utility bar, and which profiles have it; for an object — each page layout (sections, fields, related lists) and which record type/profile uses it, plus record-type picklist differences. Enough that someone could recreate the same user experience elsewhere. Discovery only.

Coverage caveat: Swantide only sees reports/dashboards in folders shared with the integration user. If this comes back thin, have the customer share the folders — don't assume the org has little reporting. Domain 10 has a query that sees all of them.

Tier-1 scan:

Migration discovery, discovery only. Inventory the reports and dashboards so we know what reporting to rebuild in our org. Group by folder/team. For each significant one: what it reports on (objects/fields) and who it's likely for. Flag reporting that depends on custom objects/fields we'll be migrating (so it can only be rebuilt after those exist), vs reporting on standard objects that's easy to recreate.

Note if folder-sharing is limiting what you can see. Rank by importance; don't certify completeness. Table: report/dashboard, folder, reports on, depends-on-migrated-schema?, rebuild priority.

Managed packages don't get "rebuilt" — they get re-licensed and re-installed in the target (or dropped if the target already has an equivalent). Swantide can see what's installed but not the package internals, so frame this as a procurement/licensing checklist.

Tier-1 scan:

Migration discovery, discovery only. List the installed managed packages / AppExchange apps in this org (name, publisher, version if visible, roughly how embedded it looks based on how many components reference it). For each, tell me the migration implication: this needs to be re-licensed and installed in our org, or we may already have an equivalent. Flag any that look deeply woven into the org's automation/data model (CPQ, OmniStudio/Vlocity, nCino, etc.) since those are the biggest migration decisions. Note that you can see that these are installed but not their internal metadata. Table: package, publisher, how embedded, migration action, notes.

Swantide reads metadata, not records — but it knows the exact object/field API names, so it's a strong query author for the data side of the migration. The loop: Swantide writes the SOQL → you run it in Developer Console / Workbench → you paste results back → Swantide interprets them into a data-migration plan. This is what lets you size and map the actual data without Swantide ever touching a record.

10-1 — record volumes (what are we actually moving):

For the migration data plan, I need record counts per object so I can size the data load and sequence it. Write me the SOQL (or tell me exactly where in Setup → Storage Usage to read it) to get record counts for every custom object plus the key standard objects (Account, Contact, Opportunity, Case, and any others central to this org). I'll run it and paste the counts back, and you turn it into a load plan — which objects are big enough to need Bulk API, and the order to load them given the relationships you documented earlier. Discovery only.

10-2 — external IDs & dedup keys (how records match across orgs):

When we merge this org's data into ours, records have to match up — accounts and contacts that exist in both orgs shouldn't double up. Based on the schema, tell me which fields are external IDs or unique, and which fields are the natural dedup/match keys per object (e.g. email on Contact, a customer number on Account). Where there's no external ID, recommend what we'd add before migrating. Then write me SOQL to check how unique/populated those candidate keys are so I can confirm they'll work as match keys — I'll run it and bring back the numbers. Discovery only.

Follow-up after you run it:

Here are the results: [paste]. Interpret them — for each proposed match key, is it unique and populated enough to dedup on, or do we need a different strategy? Flag objects where a clean merge will be hard. Discovery only.

10-3 — field fill-rate (which fields are even worth migrating):

For the [OBJECT] object, I don't want to migrate dead fields. You know its field API names — write me a single SOQL aggregate query that returns the non-null count of each custom field alongside the total record count, so I can compute a fill rate per field. Split into a few queries if there are too many fields. I'll run them and paste the numbers back for you to rank into "migrate", "confirm before migrating (barely used)", and "drop". Discovery only.

10-4 — ownership & references that must be remapped:

When we load this data into our org, record owners, roles, and any hardcoded user/record IDs won't line up. Write me SOQL to (a) list the active users who own records on the key objects (so we can map them to our users), and (b) find any fields storing Salesforce IDs that point within this org and will need remapping on load. I'll run it and you help me build the mapping plan. Discovery only.

This is the one domain that needs the target org's shape, not just the source one. Two ways to run it: connect the target org to a second Swantide instance and pull its schema the same way, or paste the target's object/field list into the prompt. Either way, this turns the source inventory into a mapping against what you already have — the difference between "rebuild everything" and "map most of it to what exists."

Tier-1 scan (paste target schema in):

Migration discovery. Here is the object/field schema from OUR org — the target we're migrating INTO: [paste the target org's objects and key fields, or the Domain 2 output from the target's own Swantide instance].

Compare it to the source org you're connected to and produce a mapping. For each major object and its key fields in the source org, tell me: does an equivalent already exist in the target org (map to it), does it partly exist (map with gaps to fill), or is it genuinely new (create it)? Flag naming collisions (same API name, different meaning) and semantic overlaps (different name, same purpose) — those are the dangerous ones. Table: source object/field, target equivalent, map / map-with-gaps / create-new, collision risk, notes.

Tier-2 drill-down (one object at a time):

For the source org's [OBJECT], do a field-by-field mapping to our target org's [TARGET OBJECT] [paste target fields]: which source fields map directly, which map with a type/format difference (note the transform needed), which have no home yet (create), and which target fields have no source (leave empty). This is the field-mapping spec the data migration will use. Discovery only.

Run this last, pasting in (or summarizing) the tables from the prior domains. This is the executive migration plan / rebuild runbook — sequenced in dependency order.

Here are the discovery findings from across this source org — inventory, business processes, data model, automation, Apex, integrations, security, UI, reporting, packages, data plan, and target-org mapping [paste or summarize the prior tables].

Produce a consolidated migration blueprint for rebuilding this org in the target:

1. A rebuild backlog: every significant item with a rebuild / merge-into-existing / re-license / retire recommendation and a rough effort. 2. Sequenced into phases in dependency order — data model & security first, then automation & code, then UI, then reporting, then data load, then integration re-authorization at cutover. 3. Called-out risks: integrations that break at cutover, managed packages needing procurement, data that's hard to dedup, and anything org-specific that won't port cleanly. 4. A one-paragraph executive summary of the scope and effort of migrating this org, suitable to put in front of a stakeholder.

Discovery and planning only — don't build anything yet.