遷移首先是一個品質專案

🌐 另有 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)

圖片由 AI 生成

由 AI 翻譯，尚未經過社群審閱。 閱讀英文版 本節的英文原文已有變更，尚未重新翻譯。 (81)

第 1 個模組，共 5 個，屬於 Data Architect 課程第 10 章遷移與同步。每個模組都可以單獨閱讀。 上一篇：上一章整合與資料流動 · 下一篇：大數據量載入

**本模組回答的問題：**在開始把資料載入到 Salesforce 之前，應該對資料做些什麼？

遷移專案會騙人。資料在這邊，你需要它到那邊，於是有人開始談 Data Loader、Bulk API、CSV 檔案、批次大小和載入順序。這些都很重要。但不是我的起點。我的第一個問題是：**我們到底要移動什麼？**如果源系統裡有重複的客戶、無效的地址、過時的值、斷開的關係，以及十五年沒人需要的資料，Salesforce 會很樂意成為它們全部的新家。載入得更快修復不了這些。遷移首先是一個品質專案。

Start With the Picture

Here’s Steve Trucking’s landscape from Checkpoint 1, the weekend RouteDesk retires. RouteDesk is the desktop dispatch tool the coordinators used inside each distribution center (DC) to turn manifests into routes. It holds eight years of delivery history, about 5 million deliveries, and the quality varies by DC. At Checkpoint 1 we decided it retires, and we left one question open: what, if anything, comes into the org? That’s a migration decision, and this is the chapter for it. ⟲

點擊放大

One new arrow. It runs once, and then it disappears. ⟲

A migration is an arrow on the landscape like any other. Everything chapter 9 asked of an arrow applies: what moves, how much, by which key, who proves it arrived. The difference is that this arrow has an end. When it’s done, RouteDesk is switched off and the arrow comes off the drawing. That makes it easy to rush, because “we only do it once.” But the data it carries stays in Salesforce for years. ⟲

把壞資料移得更快不算成功

遺留系統有 500,000 條客戶記錄，我們遷移了 500,000 條客戶記錄。我們成功了嗎？也許吧。如果其中 40,000 條是重複的，75,000 條十年沒有活動，幾千條的州程式碼無效，有些沒有可用的識別符號，有些子記錄指向已經不存在的父記錄，還有些欄位的含義隨記錄建立的時間而不同呢？報告依然可以寫著來源 500,000 條，目標 500,000 條，載入率 100%，而專案依然可能是失敗的。完整性很重要，但光有完整性並不能證明品質。

所以在設計載入之前，我要先理解源資料。有哪些資料，它們意味著什麼？有多舊，多可信，哪些欄位真的在用，哪些值有效，存在哪些關係，哪些識別符號可以信任？什麼應該在遷移中保留下來，什麼不應該？這就是前面幾章派上用場的時候：第 4 章教了我們企業全景，第 5 章說品質必須被設計，第 6 章講身分和權威。遷移把這一切應用到一批已有的資料上。它不只是移動行。它是在決定過去的哪些部分值得成為未來架構的一部分。

遷移、歸檔還是丟棄，並且知道為什麼

一份遷移清單至少需要三種答案：**遷移、歸檔，或按策略丟棄。**五年前的交易明細可能出於合規需要保留，卻不必放在活動資料模型裡；過時的臨時資料可能既沒有保留要求，也沒有價值；歷史可能屬於一個可搜尋的歸檔。第 7 章的生命週期原則是「設計出口」，而遷移正是應用它的絕佳時機。不要因為記錄存在就把每一條都帶過來。

So zoom in on RouteDesk and take it apart, one class of data at a time. ⟲

點擊放大

Every class of data gets a decision, a place and a reason. ⟲

The deliveries not yet made have to come in: manifests arrive one to two days ahead, so on cutover weekend RouteDesk holds about two days of work, roughly 6,400 deliveries, and the crews need them on Monday morning. The recent history comes in because of claims. A damage claim is a Case in Salesforce, and the agent working it needs the delivery behind it. So deliveries still inside the claim window come in too. Steve Trucking accepts claims for 60 days after a delivery, so that’s about 190,000 more Work Orders. Had the business said 30 days, it would be half that. The window is the business’s number, not ours. ⟲

The other 4.8 million deliveries go to Snowflake, where Checkpoint 1 already sends status history, kept by the partner key so a claim on an old delivery can still find it, and so leadership’s five-year reports still work. They don’t belong in the operational core: that would make Salesforce RouteDesk’s retirement home, and chapter 7 showed what Work Orders at volume cost. And the route plans and the coordinators’ drafts? Eight years of yesterday’s plans have no value once the deliveries are done. But I don’t decide that alone. ⟲

The opposite mistake is “we don’t need the old stuff.” Who decided? Legal, finance, operations, service, compliance? The data architect shouldn’t invent retention policy during a migration; we translate the business and regulatory requirement into architecture. Before excluding data, establish whether it must be kept, for how long, where, who needs access, and whether its relationships and source identifiers must survive. Eight years of Recipients’ names, addresses and phone numbers is exactly that kind of question: archiving them isn’t the same as keeping them forever. The goal isn’t to migrate less. It’s to know why every class of data is moving, or isn’t. ⟲

Test knowledge. Migrate what the new system needs to operate, not everything the old one held. Expect a scenario with years of legacy history: the answer is usually to migrate active and recent records and archive the rest outside Salesforce where it stays reachable, with the retention decision made by the business, not by the migration team. ⟲

Where the Preparation Happens

Before the steps, the place. All of this preparation happens outside Salesforce, in a working database of its own: Postgres, SQL Server, Oracle, MySQL, even SQLite for a small job, whatever the team knows. Not in Salesforce, and not in a spreadsheet that gets emailed around. I call it the preparation data store, or the preparation store for short. It sits in between: the source feeds it, and it feeds Salesforce. ⟲

點擊放大

The preparation data store sits in between. Every step in this module happens inside it. ⟲

The extract lands there raw. The standardizing, cleaning, enriching, deduping and validating all run there, as code. The quarantine is a table, the counts are queries, and the whole thing can be run again from the top. Some tools connect a database like this straight to Salesforce, copying data down and sending changes back; others export files for a data loader. There are many ways to load data. The principle doesn’t change: prepare it outside, then load the result. ⟲

And it holds more than the source. Pull down the relevant parts of the target org too. Why? Because dedupe has to compare against what’s already in Salesforce, and when the survivor of a merge is a record that’s already there, the new children need its key to link to it. You can’t decide the merge without both sides in front of you. For RouteDesk, the preparation store holds the RouteDesk extract and a copy of what Salesforce already has: the Retail Partner Accounts, the Products and Service Territories, the claim Cases with their delivery references, and the Work Orders the new integration has already created, because the partners don’t stop sending manifests for our cutover weekend. ⟲

Then you practice. Run the preparation, load a sandbox, reconcile, find the rule that was wrong, fix it, run it all again. By the time we reach production, the preparation has run many times, and it’s boring. That’s the goal. ⟲

我的順序：標準化、清理、補充、去重、驗證

When I’m preparing data for migration, I work in this order, and the order matters. All five steps happen in the preparation data store. ⟲

Standardize. Get equivalent values into one form. One source has CA, California and Calif.; another has US, USA and United States. A company comes in as Steve Plumbing, Steve's Plumbing and Steve's Plumbing LLC. Phone numbers arrive as 5555550142, (555) 555-0142 and +1 555 555 0142. Before we compare records or apply matching rules, we need to know which differences are formatting and which are meaningful. ⟲

Names are the classic trap. I had a system with first and last name in one field, and the Salesforce contact needs them apart. “Daniel Reyes” splits easily. Then you get “Mr. Daniel Reyes,” “Daniel Reyes PhD,” “Daniel Reyes III,” and names with two family names, such as Roberto González Suárez, where González isn’t a middle name: split that wrong and you’re in trouble. Build the patterns (two words, three words, a title, a suffix), run the splits, and have the customer validate the results. ⟲

**清理。**處理錯誤的、不可用的或過時的東西：無效的程式碼、不可能的日期、拼寫錯誤、佔位值、存放著與其含義不符的資料的欄位。有意識地對映挑選清單的值：遺留的潛在客戶狀態 Cold，在目標中可能變成 Closed。當清單很長時（我見過 200 個值），就建一張轉換表，讓業務為每個源值填寫目標值。Salesforce 對挑選清單的驗證很嚴格，所以要在它們到達之前抓住這些問題，而不是等驗證規則來告訴你源資料裡有什麼。

RouteDesk’s “quality varies by DC” shows up right here. Each DC set up its own status codes over eight years, so the same outcome arrives in nine spellings. The transformation table maps every one of them to the Work Order’s status values in Salesforce: ⟲

DC	RouteDesk says	Work Order status
DC 1	DLV	Completed
DC 4	Delivered - OK	Completed
DC 7	DONE/INST	Completed (the install is on its line item)
DC 1	NH	Cannot Complete (nobody home)
DC 4	Refused	Cannot Complete
DC 7	CXL	Canceled

The left two columns come from profiling the extract; the right column comes from the business, not from us. Completed, Cannot Complete and Canceled are three of the standard Work Order status values (WorkOrder （在新標籤頁中開啟）, Object Reference, Winter ‘27, checked 2026-10-27). Notice the third row: one RouteDesk code carried two facts, the delivery and the install, and the target model keeps them apart. ⟲

Enrich. Sometimes missing information can be reliably added: a normalized address, a postal code from city and state, a county, a geolocation, a mapping from a legacy code to the new enterprise taxonomy, an enterprise identifier. Enrichment needs provenance. If we add or change information, I want to know where it came from and why I trust it. Some of RouteDesk’s older deliveries don’t name the Retail Partner at all, because each DC served one partner and everybody knew. The DC and the order number’s format tell us which partner it was. That’s enrichment from a rule we can show, not a guess. ⟲

**去重。**然後找出代表同一個現實事物的記錄。為什麼不從這裡開始？因為比對髒資料更難：Steve's Plumbing 和 STEVES PLUMBING LLC 在標準化之後要容易比較得多。先在待匯入的資料內部去重，再和 Salesforce 裡已有的資料比較。第 6 章的規則依然適用：**合併是破壞性的；關聯不是。**不要因為一個模糊比對的分數看起來很有說服力，就把記錄合併掉。

Validate. Finally, test the transformed data against the target: required information present, reference values valid, relationships resolvable, keys unique where they should be, values fitting the model, authority rules preserved. Only then do I want to talk seriously about loading. And don’t expect the import tool to catch everything. Salesforce’s own Trailhead project on the NPSP importer makes the point: it catches invalid picklist values and missing required fields, but if a spreadsheet turned a postal code like 02134 into the number 2134, the importer loads the four digits (Perform an Import Dry Run （在新標籤頁中開啟）, Trailhead, checked 2026-10-27). That’s one more reason the preparation lives in a database with typed columns, not in a spreadsheet. ⟲

點擊放大

Five steps, in order. A record that fails one goes somewhere visible, with its reason. ⟲

Test knowledge. Data quality is fixed before the load, not after. Know the preparation steps (standardize, clean, enrich, deduplicate, validate) and why the order matters: you can’t match records reliably until their values are in one form. Picklist values are mapped with a transformation table the business signs off, because Salesforce rejects values a restricted picklist doesn’t have. ⟲

在遷移之前清理

誘惑是「先把所有東西都放進 Salesforce，之後再清理」。我不喜歡把這當作預設做法。一旦壞資料進了生產環境，它就參與到生產中：使用者看到它，自動化、報表、整合和代理程式都看到它，重複記錄開始聚集相關記錄，清理就變得更難。在可行的地方，在資料進入目標之前就改進它。並不是每一個歷史上的瑕疵都必須修復；那是一個成本收益的決定。但「我們以後再清理」不是遷移策略。它是帶著上線日期的技術債。

And not every record deserves the same effort. An active customer with open orders, open cases, current contracts and billing relationships is different from one who bought something once nine years ago. Both may need to be kept. For the critical, active data I may require stricter validation, more enrichment, closer duplicate review and detailed reconciliation; for low-value history, preserving traceability may matter more than making every record perfect. Architecture is partly deciding where quality effort creates value. For RouteDesk, the 6,400 deliveries the crews will drive to on Monday get the strictest checks. The 4.8 million going to the archive need their keys and their dates right; nobody will fix eight years of typos in delivery notes. ⟲

保留源身分，並按鍵載入

最容易犯的錯誤之一，就是失去了把 Salesforce 記錄追溯回來源的能力。如果遺留客戶 CUST-847291 變成了客戶 001…，我依然想知道它來自 CUST-847291，用於對賬、排查問題、重新載入、稽核、比對子記錄、回滾分析，以及上線後冒出來的各種問題。新的 Salesforce ID 在 Salesforce 內部很重要；它並不會抹去源身分。這就是第 9 章的外部 ID 原則。遷移和整合在身分上交匯。

At Steve Trucking they meet in one field. Every Work Order already carries the partner’s key, Partner_Delivery_Key__c, an External ID marked unique, holding values like REDROCK-8472914-1 (chapter 9, module 2). RouteDesk kept the partner’s order number on each delivery, so the migration builds the same key and upserts on it, exactly as the integration does. That matters on cutover weekend: if Redrock resends a manifest for Tuesday after we’ve loaded Tuesday from RouteDesk, the integration finds the migrated Work Order and updates it instead of creating a second one. RouteDesk’s own delivery number comes along too, in a plain field, so anyone can trace a Work Order back to the record it came from. ⟲

So don’t rebuild relationships by name (“find the Account whose Name is Acme Distribution”). If the legacy contact carries Legacy_Account_ID = CUST-847291 and the Salesforce Account carries that identifier as an External ID, the relationship is rebuilt deterministically. The Bulk API does this in the load file itself: a column header such as WorkOrder.Partner_Delivery_Key__c says “find my parent by this indexed field,” and Salesforce looks up the parent’s ID for you (Relationship Fields in a Header Row （在新標籤頁中開啟）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-27). Keys turn “I think this child belongs here” into “I know which parent this came from,” and that matters more as the Number of Zeros grows. ⟲

Relationships also create sequence. If contacts reference accounts, the accounts must exist first; if line items reference orders and products, those come first. So migration isn’t one giant load. It’s reference data, parents, children, junctions, then dependent history, in an order the target data model dictates. That’s one more reason the data architect belongs in migration planning: the model tells us how the migration has to be assembled. Here’s RouteDesk’s open work, on Checkpoint 1’s model. ⟲

點擊放大

Wave 1: what the Work Orders will point to has to exist first. Most of it already does. ⟲

點擊放大

Wave 2: the Work Orders, upserted by the partner key. ⟲

點擊放大

Wave 3: the children, each finding its Work Order by the same key. ⟲

點擊放大

Wave 4: the claim Cases already in Salesforce get their link to the delivery. The model sets the order. ⟲

Test knowledge. Keep each legacy record’s key in an External ID field, load parents before children, and let each child find its parent by that key: an upsert on the External ID, and a relationship column in the load file (Parent.External_Id__c) instead of looking up Salesforce IDs. Reloads then update instead of duplicating, and every record traces back to its source. ⟲

被合併的記錄需要一個子記錄策略

這是人們低估的問題。分析發現遺留客戶 A、B 和 C 是同一個客戶，所以目標裡只有一個客戶。好。但是 A 有 12 個案例，B 有 4 個訂單，C 有 3 個連絡人。如果在概念上合併了父記錄，卻沒有重新設計子記錄的對映，你就解決了父記錄，卻弄斷了關係。每一個去重決定都需要一個子記錄策略。

RouteDesk has its own version. When a partner revised a manifest on the day, a coordinator sometimes keyed the delivery in again instead of editing it. Now RouteDesk has two deliveries with the same partner order number: one with the old window and two stops, one with the new window and the crew’s notes. Salesforce will have one Work Order, because the partner key is unique. Which window wins, and what happens to the stops and notes on the other one? ⟲

首先是欄位：當兩條記錄比對時，哪些值勝出？空白對一個值很簡單。衝突就不簡單了：Steven 還是 Stephen，Salesforce 裡的電子郵件還是載入資料裡的那個？選定一個存留記錄，逐個欄位做決定，然後儘早把樣本案例擺到業務面前，讓這些選擇上留下他們的指紋。

Then the children. I see three options: add the children to the survivor, don’t load the merged record’s children, or load the merged record as inactive, linked to the survivor, with its children kept on it. ⟲

點擊放大

Three ways, none free. Notice the third one at RouteDesk: the inactive duplicate can’t reuse the partner key, because the survivor already holds it, so it needs a key of its own. ⟲

Whichever you choose, it happens in the preparation store, before anything loads. That’s where the survivor is picked, sometimes a record that’s already in Salesforce, pulled down with its key. That’s where each child gets the key of the parent it will point to. And that’s where the merged record either keeps its children, hands them over or is left out. Salesforce receives the result of the merge, not the job of doing it. ⟲

我怎麼選？取決於資料有多關鍵，以及我們是否需要追溯到載入了什麼。還要把風險和合並本身的收益放在一起權衡。在零售客戶名單裡把兩個不同的人的購買歷史連在一起，只是一個小麻煩；在一位患者的記錄上顯示另一位患者的用藥，則是嚴重的洩露。錯誤比對的代價越高，合併就要越保守。無論你怎麼決定，每個子記錄還能追溯到它最初的來源嗎？遷移去重不是「對客戶執行重複比對」。整個關係圖都很重要。

我曾經站在另一邊。一家我從大學時代就在那裡買東西的零售商在遷移它的客戶資料，我們一看，Steve Simpson 在大約六個電子郵件地址和街道地址下出現：我大學時的地址、我租過的房子、之後的幾個地方。我們應該合併它們嗎？外面還有別的 Steve Simpson。業務決定，把我的舊歷史連在一起，不值得冒把我和錯誤的 Steve Simpson 合併的風險。這就是每一次合併都必須回答的問題：把資料合在一起的收益是什麼，選錯人的風險又是什麼？

Test knowledge. Deduplicate before the load, within the incoming data and against what’s already in Salesforce, with matching rules and a survivor chosen field by field. Expect the follow-up question: what happens to the merged record’s child records? Re-parent them to the survivor, leave them out (and archive them), or keep them on an inactive linked record. Each has a cost. ⟲

可重複的轉換，保留原始來源

遺留狀態 A 變成 Active，I 變成 Inactive，S 變成 Suspended。這個對映存放在哪裡？不在某個人的記憶裡，不在一個被以不同方式複製到三個檔案裡的 Excel 公式裡，也不是週五晚上的一個手動步驟。如果明天重新載入，我們應該得到相同的結果，所以對映、標準化和清理規則、轉換、去重決定和鍵的生成，都必須是可重現的。遷移過程就是程式碼，即使其中有些部分並不是真的用程式語言寫的。

And don’t destroy the starting point. Keep the original extract in raw tables, exactly as it came out, and never change them. Each step writes its result to a new staged table: standardized, cleaned, deduplicated, load-ready. When something looks wrong, I want to know whether it was wrong in the source, changed by our transformation, changed by the load, or changed by Salesforce automation afterward, and with every table kept I can walk back through them and find out. Overwrite your only copy of the source while cleaning it and you lose the evidence. ⟲

I learned how much this pays off on a support migration. A company was moving its support desk from Zendesk into Salesforce, and Zendesk’s tickets were very similar to Salesforce Cases, but not exact. So I loaded every Zendesk export into a SQL database as raw tables, one per Zendesk structure: organizations, users, tickets, custom fields, comments, attachments. Then I built interim tables that got closer and closer to the Salesforce structure, with the field and picklist mappings kept as tables of their own. Then I loaded Salesforce from those tables and brought the Salesforce IDs back. In the end every row had three things: its original Zendesk key, the transformations that had been applied to it, which were never one way, and its Salesforce key. That’s what let me do partial loads and reloads whenever I needed to. ⟲

Here’s the same design for RouteDesk, one step at a time. ⟲

點擊放大

Extract: one raw table per RouteDesk structure, each row with its RouteDesk key. These tables never change. ⟲

點擊放大

Generate: new tables shaped for Salesforce, built from the raw ones with the mapping tables. The raw tables are still there. ⟲

點擊放大

Load: the Work Orders upserted by the partner key, then their children. ⟲

點擊放大

Keys back: each Salesforce ID is written to its row. Now every row knows where it came from, what was done to it and where it landed. ⟲

So no transformation is allowed to lose fidelity. If a step throws information away (truncates a note, drops a code it didn’t recognize, keeps one of two conflicting values without saying which), I can’t trace back through it, and I can’t repeat the run and get the same answer. Keep the raw tables, keep the staged tables, keep what each load sent and what came back. Then you can rerun the whole thing from the raw extract at any time, and you have the history of every load. This is migration’s version of lineage: preserve where the data came from and what you did to it. ⟲

Sometimes the Staging Is Inside Salesforce

The preparation store isn’t the only place to stage. In a few special cases, the last stop before the real objects is a plain custom object inside Salesforce: one flat row per source record, no automation, loaded fast. Then a batch process works through the rows and builds the real records. I’ve used it when Salesforce’s own logic had to create the records and was too slow to load through: a scheduling process that took a few seconds per appointment. Module 3 comes back to that case. ⟲

Salesforce uses the same pattern in its own products, and it’s worth learning from. The Nonprofit Success Pack loads a spreadsheet into its NPSP Data Import object first. A dry run checks for matches without creating anything. Then the importer creates the accounts, contacts and donations, and writes each new record’s ID back onto the row it came from (How the Import Process Works （在新標籤頁中開啟）, Salesforce Help, checked 2026-10-27). That’s a reference, not a rule: staging inside Salesforce is the special case, not the way to load everything. ⟲

For RouteDesk, a one-time move with heavy cleaning and merging, the preparation store outside Salesforce does the work, and the load sends the result. ⟲

壞記錄需要有個去處

在 500,000 條記錄中，497,800 條通過了驗證，2,200 條沒有。悄悄地丟掉它們？不行。把垃圾硬塞進必填欄位？不行。在每條歷史記錄都完美之前讓專案停下來？大概也不行。我要一條隔離和修復的路徑，記錄下哪條源記錄失敗了、為什麼、哪條規則拒絕了它、是否必須在切換之前修復、誰負責決定、能否推遲。這樣，異常就成了可見的架構工作，而不是隱藏的資料丟失。

Before you call a record bad, look at the rule that rejected it. Sometimes the record is fine and the rule is wrong. Salesforce’s Well-Architected framework puts it plainly: “data architecture decisions determine the populations that become visible—and invisible,” and a required email address “excludes populations that don’t have reliable internet access or personal email addresses” (Fairness （在新標籤頁中開啟）, checked 2026-10-27). RouteDesk has thousands of deliveries where the Recipient gave only a phone number. If the new Work Order requires an email, those aren’t bad records. They’re real people the rule would make invisible. Fix the rule, not the person. ⟲

然後在載入之前證明轉換。我們從多少條源記錄開始，有意排除了多少條，合併了多少條重複，多少條已經就緒，多少條被隔離，多少個父子關係能夠解析，控制合計是多少？如果數字在載入之前對不上賬，載入得更快也無濟於事。模組 4 會用數量、合計、抽查和彙總報表來證明遷移，但證明從這裡開始。

AI 可以幫忙清理。它無權編造真相。

AI 在遷移中很有用：建議對映、找出可疑的值、把潛在的重複分組、發現異常、生成轉換程式碼、解釋被拒記錄中的模式。但如果一個補充流程判定「這家公司可能在亞利桑那」，「可能」是不夠的。如果它判定兩個客戶看起來足夠相似、可以合併，請記住第 6 章：一次錯誤的比對，可能比漏掉一次比對造成更大的損害。用 AI 來加快調查。不要讓它悄悄地製造權威的企業資料。

**考試之外：AI 改變了什麼。**在遷移過程中，AI 可以大大加快資料剖析、對映、異常檢測和候選比對。對於建立、合併或修改權威業務資料的決定，要保留確定性的規則、來源記錄和人工審查。

架構師在這裡決定什麼

• 根據業務價值和保留要求，哪些源資料被遷移、歸檔或排除。
• Where preparation happens (a preparation store outside Salesforce, a staging object inside it, or both), and which parts of the target org are pulled down to merge against. ⟲
• 資料在進入目標之前如何被標準化、清理、補充、去重和驗證。
• 哪些源識別符號和血緣被保留下來，讓每一條重要的目標記錄都可以被追溯和對賬。
• The load order the target data model dictates, and the keys each child uses to find its parent. ⟲
• 去重決定如何在整個關係圖中處理欄位和子記錄，並根據關鍵程度、可追溯性和錯誤合併的風險來權衡。
• 在任何生產載入開始之前，哪些轉換和異常處理規則必須是可重複的。

不要用載入的行數來衡量遷移

「我們載入了 500,000 條中的 500,000 條記錄」告訴我的是載入工具運作正常。我想知道的是：我們移動的是正確的資料嗎，改進了需要改進的東西嗎，保住了身分和關係嗎，安全地合併了重複嗎？我們能解釋排除了什麼、重現轉換、把一條 Salesforce 記錄追溯到它的來源、證明結果嗎？先做這些工作。然後我們再操心能載入得多快。

延伸探索

• Salesforce, General Guidelines for Data Loads （在新標籤頁中開啟） and Relationship Fields in a Header Row （在新標籤頁中開啟）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, WorkOrder （在新標籤頁中開啟）, Object Reference for the Salesforce Platform, Winter ‘27 (API version 68.0), checked 2026-11-01. ⟲
• Salesforce Help, How the Import Process Works （在新標籤頁中開啟） (the Nonprofit Success Pack’s staging object), checked 2026-11-01. ⟲
• Hands-on: the Trailhead trail Import Data With Nonprofit Success Pack (NPSP) （在新標籤頁中開啟） walks through the whole staging pattern in a practice org: a template, staging rows, a dry run, fixing the failed rows, then the import. It runs in a Trailhead Playground; Trailhead notes that as of December 2025, NPSP is no longer offered as a preconfigured package in production orgs. Checked 2026-10-27. ⟲
• Salesforce Architects, Well-Architected, Fairness （在新標籤頁中開啟）, checked 2026-11-01. ⟲
• In this course: Master Data and Identity (matching, survivorship, link vs merge), Data Quality and Governance, and Keys and Write Ownership (the partner key). ⟲
• Trailhead, Perform an Import Dry Run （在新標籤頁中開啟）, checked 2026-11-01. ⟲