遷移與同步
另有 19 種語言版本
English · 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)
Data Architect 課程第 10 章的學習指南。請先閱讀五個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
這一章涵蓋了考試的整個「資料遷移」部分（15%）：載入時的資料品質、載入大量資料，以及把資料取出來。Bulk API 的數字會變，所以要學會每個槓桿是用來做什麼的，並在據此做計劃之前檢視當前的限制。
邊學邊打勾。每一條都連結到講授它的地方。
MIG-1：載入時的高資料品質
- 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：載入大量資料
- 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：匯出資料
- 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 BYandLIMITdisable it. (Very Large Copies: PK Chunking) ⟲ - I keep a copy current with a watermark (
SystemModstamp), catch deletes withqueryAllinside 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) ⟲
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- 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. ⟲
| 術語 | 一句話解釋 |
|---|---|
| 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 |
| 執行手冊 | 帶有負責人、時間和證據的分步切換計劃 |
| 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 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
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.
- Salesforce Certified Platform Data Architect Exam Guide （在新標籤頁中開啟）, Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- 每個模組自己的「延伸探索」部分列出了其事實所依據的 Salesforce 文件，並註明了查閱日期。