1. Users and owners
- Active and inactive users mapped first
- Owner mapping for leavers agreed with the business
- Queues and public groups
- Roles that drive record sharing
Integrations / Salesforce Integration
Salesforce Integration and Data Migration
The nightly sync burns the org's API allowance by noon, the migrated opportunities all show last Tuesday as their created date, and every load sets off a storm of flows and emails. Agnotic Technologies connects Salesforce to your ERP, billing, warehouse and in-house systems and moves data into it without those side effects.
API chosen per flowOAuth 2.0 JWT bearerExternal ID upsertsRehearsed in a sandbox
Trusted by global innovators
What does Salesforce integration and data migration involve?
Salesforce integration and data migration means choosing the right Salesforce API for each data flow, giving the connection its own least-privilege integration user, and loading records in dependency order with history intact. Agnotic Technologies builds these integrations to ERP, billing and data platforms, and runs migrations and org merges for clients.
This page is about Salesforce's own mechanics. Whether to configure, extend or replace a CRM, and the general migration and API budget approach we use across platforms, are on our SaaS CRM implementation page.
Decision table
Which Salesforce API fits each integration?
Most integration problems in Salesforce come from one API being used for every job. We choose per flow, by volume, direction and how fresh the data must be.
| Integration need | API we would start with | Limits model to plan for | Failure to design for |
|---|---|---|---|
| Nightly sync of thousands of records | Bulk API 2.0 ingest and query jobs | Counts toward the org's 24-hour API allocation; jobs run asynchronously | Partial job failure: rows that failed must be read back and retried, not the whole file |
| Small writes from an app or form | REST API, Composite for related records in one call | Each call counts toward the 24-hour allocation | Retries that create duplicates when the first call actually succeeded |
| Near real-time feed of Salesforce changes | Change Data Capture, read through the Pub/Sub API | Event delivery allocations; events retained for three days | A subscriber offline for longer than the retention window, which needs a full reconcile |
| Event raised by an external system | Platform Events published to Salesforce | Separate publish and delivery allocations | Events consumed out of order or twice by flows and triggers |
| Show external data without copying it | Salesforce Connect with external objects | Every page view queries the external system | Slow or unavailable source systems making Salesforce pages slow |
| One-off migration or org merge | Bulk API 2.0 upserts keyed on External IDs | Large jobs over several hours share the same allocation as live integrations | Lock contention when child records of one parent load in parallel |
Allocations differ by edition and licence count, so we read the org's own limits before sizing any job.
Integration user
How should an integration user authenticate?
A server-to-server integration should never borrow a person's login. This is the setup we build for each connection.
Dedicated integration user
One user per integration, so every record change in the audit trail shows which system made it.
Connected app with the JWT bearer flow
The server signs a JWT with its private key and Salesforce returns an access token, with no password or interactive login involved.
Least-privilege permission sets
Access only to the objects and fields the integration reads or writes, granted through permission sets rather than a copied admin profile.
Session and IP policies
Token lifetime and allowed network ranges set for the integration, separate from user policies.
Certificate rotation
The signing certificate's expiry is tracked, and a new one is loaded before the old one lapses.
Load order
In what order should records be loaded into Salesforce?
Parents go in before children, and every record carries the ID it had in the old system as an External ID, so relationships resolve without lookups by name.
2. Accounts
- Parent accounts before child accounts
- Record types and picklist values mapped
- Legacy ID stored as an External ID
- Duplicate rules reviewed before load
3. Contacts and leads
- Linked to accounts through the External ID
- Consent and contact preferences carried over
- Converted leads loaded with their history
- Email bounces and opt-outs kept
4. Opportunities and cases
- Stages and close dates from the source
- Line items after their products and price books
- Owners from step 1
- Sorted by parent to reduce record locking
5. Activities and files
- Tasks and events linked by External ID
- Emails and notes loaded last, as they are the largest
- Files and attachments with size checks
- Spot checks against the source system
Keeping history
How do you keep history and stop automation firing during a load?
A load that resets dates or sends emails to customers is worse than no migration. These are the problems we plan for before the first file.
Challenge
Created dates and created-by show the migration date and the migration user
Agnotic approach
Audit field setting on record creation is enabled for the load user, so original created dates and owners are written on insert.
Challenge
Flows, triggers and validation rules fire on every migrated record
Agnotic approach
A bypass switch, held in a custom permission or setting assigned only to the load user, which each flow, trigger and rule checks.
Challenge
Workflow emails go to customers during a load
Agnotic approach
Email deliverability is restricted in the sandbox rehearsal and the bypass covers email alerts in production.
Challenge
Record lock errors when many children of one account load at once
Agnotic approach
Rows sorted by parent ID so the same parent is not updated by parallel batches.
Challenge
Picklist values in the source that do not exist in Salesforce
Agnotic approach
A mapping table agreed with the business, and rows with unmapped values held back rather than forced.
Org merges
What happens when two Salesforce orgs merge after an acquisition?
Org merges are migrations where both sides are already live. The steps we follow:
Choose the surviving org
Based on which org holds the integrations, custom code and licences that are hardest to move.
Compare metadata
Objects, fields, record types, picklists and automation listed side by side, with a decision for every difference.
Map users and owners
People in both orgs matched once, so ownership and sharing survive the merge.
Keep an ID cross-reference
Every source record ID stored against its new ID, for reports, integrations and links in old emails.
Freeze, delta load and retire
A short change freeze, a final delta load, then the retired org kept read-only until users confirm nothing is missing.
What do we connect to Salesforce?
Each integration is scoped on its own, with the system of record for every field agreed first.
ERP and order systems
Accounts, products, prices and order status, with the ERP as the source of truth for financial fields.
Billing and subscriptions
Contracts and invoices from billing, renewals and upsells back from Salesforce.
Data warehouses
Bulk query jobs or change events feeding analytics, without reports competing with live integrations for API calls.
In-house applications
Your own apps reading and writing Salesforce through the REST API with their own integration users.
Legacy CRMs and spreadsheets
One-off migrations with mapping, deduplication and reconciliation reports.
Middleware and event buses
Change events and platform events passed to the integration layer your company already runs.
Who it is for
Who uses our Salesforce integration services?
Teams whose Salesforce org has to agree with the rest of the business.
Revenue operations teams
Opportunities, quotes and orders that match what finance invoices.
Companies after an acquisition
Two orgs, two sets of customers and one deadline to merge them.
Startups moving off spreadsheets
A first clean load into Salesforce with relationships and history kept.
Product companies
In-app data written to Salesforce so sales and support see real usage.
Data and analytics teams
Salesforce data in the warehouse on a schedule that suits reporting.
Protocols and formats
Which standards do Salesforce integrations use?
OAuth 2.0RFC 7523REST / JSONCSVgRPCApache Avro
Facts and sources
What does Salesforce document about these APIs?
Short facts from Salesforce's own documentation, each linked to the guide it comes from.
Salesforce describes any data operation that includes more than 2,000 records as a good candidate for Bulk API 2.0, and points jobs with fewer than 2,000 records to bulkified synchronous calls in REST, such as Composite, or SOAP.
Source: Salesforce, Bulk API 2.0 and Bulk API Developer GuideSalesforce enforces API request limits against the total of all API calls made to an org in a 24-hour period, not per user. REST API, SOAP API, Bulk API and Bulk API 2.0 calls all count toward that allocation.
Source: Salesforce Developer Limits and Allocations Quick ReferenceChange Data Capture publishes change events for the creation, update, deletion and undeletion of Salesforce records. Events are retained for three days, so a CometD or Pub/Sub API subscriber that was offline can replay what it missed.
Source: Salesforce, Change Data Capture Developer GuideAn upsert matches each incoming row on an External ID field or the Salesforce record ID. Existing records with a match are updated, and rows without a match are inserted as new records.
Source: Salesforce, Data Loader Guide
Rehearsal
How is a Salesforce migration rehearsed before cutover?
Nothing is loaded into production until a full run has passed in a sandbox.
1.
Trial load in a sandbox
A representative slice loaded first to test mappings, bypass switches and load order.
Sandbox
2.
Full rehearsal and reconciliation
Every object loaded, record counts and key totals compared with the source, and the run timed for the cutover plan.
Reconcile
3.
Cutover and delta
Production load in the agreed window, a delta for changes made since, then sign-off against the same reconciliation report.
Go-live
Frequently Asked Questions
Use Bulk API 2.0 for large volumes, such as nightly syncs and migrations, and REST for small, immediate writes from an application. Salesforce's own guidance draws the line at about 2,000 records per operation.
Yes. With audit field setting enabled for the load user, created dates and created-by values from the old system are written when records are inserted. Owners are mapped to users loaded first, including people who have left.
We add a bypass check to flows, triggers and validation rules that only the load user can activate, and rehearse the whole load in a sandbox with email restricted before production.
Yes. We agree which system owns each field, then sync accounts, products, prices and order status through the API that fits the volume, using its own integration user.
The number of objects and systems involved, data quality at the source, custom automation that needs bypass checks, files and attachments, and whether two live orgs are being merged. We size these on the scoping call.
This page makes no partner claim. Agnotic Technologies is a software development services company that builds integrations and migrations for clients on the Salesforce orgs they already license.
AI tools help engineers draft field mappings and test scripts from metadata, and every mapping is reviewed with your team. Customer records stay in your org and sandboxes; they are never pasted into AI tools.