Study guide

🌐 Also in 19 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Study guide for chapter 10 of the Data Architect course. Read the five modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries the exam’s whole Data Migration section (15%): quality at load time, loading large volumes, and getting data out. The Bulk API numbers change, so learn what each lever is for and check the current limits before you plan around them.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

MIG-1: high data quality at load time

• I migrate what the new system needs to operate, not everything the old one held: migrate, archive or discard, with retention decided by the business. (Migrate, Archive or Discard, and Know Why)
• I prepare data in a preparation data store outside Salesforce, with the org’s current records pulled down to merge against. (Where the Preparation Happens)
• I know the order: standardize, clean, enrich, dedupe, validate, and why you can’t match records until their values are in one form; picklists mapped with a transformation table the business signs off. (My Order)
• I keep each legacy key in an External ID, load parents before children, and let each child find its parent by key (a relationship column such as Parent.External_Id__c), never by name. (Preserve the Source Identity, and Load by Keys)
• I deduplicate within the incoming data and against Salesforce, choose a survivor field by field, and decide what happens to the merged record’s children. (Merged Records Need a Child Strategy)
• I keep the raw source unchanged and every transformation repeatable, with no step that loses fidelity. (Repeatable Transformations, Raw Source Kept)
• I give bad records a quarantine with the reason, and check whether the rule is wrong rather than the record. (Bad Records Need Somewhere to Go)
• I prove a migration four ways: counts, totals, spot checks and aggregate reports, against expected numbers set before the load, and business owners validate too. (Four Ways I Prove the Data)

MIG-2: loading large volumes

• I know when the Bulk API is the answer: more than about 2,000 records, asynchronous, a job you submit and collect; fewer, bulkified synchronous calls (up to 200 records a call). (The Loading Dock Behind the Bank)
• I know Bulk API 2.0 from Bulk API (1.0): 2.0 splits batches for you and runs in parallel; 1.0 has you build batches of up to 10,000 and alone offers serial mode; both share 15,000 batches in 24 hours. (Two Loading Docks)
• I know insert is fastest, then update, then upsert, split an upsert where I can, load clean data (a failed batch falls back to single rows), and send only changed fields. (Insert, Update or Upsert)
• I sort the load by parent so parallel batches don’t fight over the same locks, and treat serial mode as the fallback. (Parallel Is Faster, Until It Isn’t)
• I set record ownership deliberately and watch for ownership skew (more than 10,000 records on one owner). (The Load User, and Who Owns the Records)
• I keep every job’s results (kept for seven days) and bring the new IDs back, so I can load in phases, retry only failures and reload safely. (Keep Every Result, and Bring the Keys Back)
• For each automation I decide: don’t need it, simulate it, defer it, or let it run, knowing that turning it off means owning its business logic. (Three Choices)
• I build a bypass into triggers and flows from the start, tested on and off and deployed ahead; deactivating flows by hand before a load is an anti-pattern. (Build the Bypass In From the Start)
• I know where a bypass lives: a custom permission ($Permission, FeatureManagement.checkPermission), a hierarchy custom setting (org, profile or user; $Setup, getInstance()), or custom metadata per automation. (What a Bypass Looks Like)
• I know large loads trigger sharing recalculation, that Support can enable deferred sharing calculations, and that deferred work runs within the async Apex limits. (Derived Data, Sharing, and the Staging Object)
• I plan the cutover: most data loaded days early hidden by sharing, then a refresh and an incremental, with the source frozen or its changes captured. (Day −7, Day −1, Day 0)
• I lock users out with freezing, login hours, IP ranges or a login flow, never by deactivating them, and keep a back door. (Lock Users Out When You Need Control)

MIG-3: exporting data

• I know the ways out: the Data Export Service (weekly or monthly by edition; files kept 48 hours; no formula or roll-up fields), Data Loader and reports, bulk query, and backup products. (The Ways Out)
• I know PK chunking: a large query split into ranges of record IDs, for tables over about 10 million records; a header on Bulk API 1.0, automatic on Bulk API 2.0 query; ORDER BY and LIMIT disable it. (Very Large Copies: PK Chunking)
• I keep a copy current with a watermark (SystemModstamp), catch deletes with queryAll inside the Recycle Bin’s 15 days, and use events when minutes matter. (Then Keep It Current)
• I know migration has a defined start and end; synchronization is ongoing, and the mirror is never the master. (A Copy Once, or a Copy Forever, Authority Moves on Day 0)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

• Migration is a quality project first. Moving bad data faster isn’t success.
• A migration is an integration with an end. Ask of it everything you’d ask of any arrow.
• Prepare outside, then load the result. Keep the raw source; no step may lose fidelity.
• Three sets of keys: the source’s, the transformations, and Salesforce’s, all kept.
• The model sets the load order, and every child finds its parent by a key, never by a name.
• Any time you turn an automation off, you’re taking full responsibility for that business logic not happening.
• The bypass is part of the original design, not something you build the week you need it.
• Production should be boring. Don’t make production the first time you run the migration.
• Rollback has a clock. Know the moment it runs out.
• Unknown data and forgotten feeds cause rollbacks, not the loader.
• Trust but verify: counts, totals, spot checks and aggregate reports.
• If the old system is dead, stop feeding it.
• Getting data out isn’t leaving Salesforce. The first copy gets the mirror there; synchronization keeps it there.

Words to Know

Term	In one line
Preparation data store	A database outside Salesforce where the data is prepared before the load
Transformation table	A table mapping each source value to its target value, signed off by the business
Quarantine	Where records that fail a step go, with the reason, an owner and a deadline
Survivor	The record that remains when duplicates are merged
External ID	Another system’s key on a Salesforce record, used for matching and upsert
Bulk API	The asynchronous API for large loads and extracts, in jobs
Upsert	Update the matching record if it exists, create it if not
Serial mode	Bulk API 1.0 processing one batch at a time, to avoid lock contention
Bypass	A switch an automation checks first, so it can be skipped safely (some say kill switch)
Custom permission	A permission granted by a permission set, checked by automation and rules
Hierarchy custom setting	A setting with org, profile and user values, the most specific winning
Deferred sharing calculation	Suspending sharing recalculation during large changes, then running it
Runbook	The step-by-step cutover plan with owners, times and evidence
Go/no-go	The decision, against criteria set in advance, to go live or not
Rollback point	The moment after which going back would lose real work
Reconciliation	Comparing what was expected with what arrived
PK chunking	Splitting a large query into ranges of record IDs
Watermark	The point through which a copy was current, so the next run knows what changed
Synchronization	An ongoing process keeping two systems consistent

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A company is retiring a legacy system with eight years of history and wants "everything" in Salesforce. Your first question?

What does the new system need to operate? Usually active and recent records migrate; older history goes to an archive or a warehouse where it stays reachable, with retention decided by the business. Reread Migrate, Archive or Discard, and Know Why.

2. Contacts must be linked to their Accounts during the load, and nobody has the Salesforce Account IDs yet. How?

Store each legacy account key in an External ID field on Account, load Accounts first, then load Contacts with a relationship column (Account.Legacy_Id__c) so each Contact finds its parent by key. Reread Preserve the Source Identity, and Load by Keys.

3. Three legacy customer records turn out to be one customer. What do you decide besides which record survives?

What happens to the merged records’ children: move them to the survivor, leave them out and archive them, or keep them on an inactive linked record. Each has a cost; weigh the risk of a wrong merge. Reread Merged Records Need a Child Strategy.

4. A parallel Bulk API load of 2 million child records keeps failing with "unable to lock row." What do you try first?

Sort the load file by parent so each batch touches as few parents as possible. If contention remains, serial mode on Bulk API 1.0 is the fallback, at the cost of speed. Reread Parallel Is Faster, Until It Isn’t.

5. A reload is needed after fixing a transformation. How do you avoid duplicates and reload only what changed?

Upsert on the External ID, and use the IDs you brought back from the first load to know which records already exist; send only the affected rows and changed fields. Reread Keep Every Result, and Bring the Keys Back.

6. The load plan says "deactivate these twelve flows on Friday night." What's wrong?

Deactivating flows by hand before a bulk load is an anti-pattern. Each automation should have a bypass built in from the start, tested on and off and already deployed, switched on for the migration user only. Reread Build the Bypass In From the Start.

7. A flow creates a welcome task for every new customer. Two million historical customers are about to load. Options?

Don’t need it (bypass it for migrated records), simulate it (set the result in the data), defer it (a batch afterward), or let it run deliberately. For eight-year-old customers, a welcome task isn’t needed. Reread Three Choices.

8. The full load takes 18 hours; the business allows 4 hours of downtime. How?

Load most of the data days early, hidden from users by sharing, then a refresh and a small incremental inside the window, with the source frozen or its changes captured. Reread Day −7, Day −1, Day 0.

9. The counts match exactly, 475,000 against 475,000. Done?

Not yet. Counts miss wrong data: check control totals, spot-check real records end to end, and compare aggregate reports by region, status or year. Reread Four Ways I Prove the Data.

10. You must extract 30 million records of an object, and the bulk query keeps timing out. What changes?

PK chunking: the query runs as ranges of record IDs. On Bulk API 2.0 query it’s automatic (unless ORDER BY or LIMIT turns it off); on Bulk API 1.0 you set the header. Reread Very Large Copies: PK Chunking.

11. A warehouse mirrors Salesforce nightly, and records deleted in Salesforce still show in its reports. Why?

A normal query doesn’t return deleted records. Use queryAll to find them, and run that check well inside the Recycle Bin’s 15 days. Reread Then Keep It Current.

12. "We have delta loads, so we're syncing." Are we?

Not necessarily. If the deltas run until cutover and then stop, that’s migration. If both systems stay active and must keep matching, that’s synchronization, with an owner for each value. Reread A Copy Once, or a Copy Forever.

Explore

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam.
• Each module’s own Explore section lists the Salesforce documentation behind its facts, with the date checked.