切換週末

🌐 另有 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 翻譯，尚未經過社群審閱。 閱讀英文版 本節的英文原文已有變更，尚未重新翻譯。 (54)

第 4 個模組，共 5 個，屬於 Data Architect 課程第 10 章遷移與同步。每個模組都可以單獨閱讀。 Previous: Automation During the Load · Next: Getting Data Out: Keeping Another System in Step ⟲

**本模組回答的問題：**如何完成切換，並證明遷移成功了？

週五晚上。使用者都下線了，遷移團隊線上，有人說：「我們已經測試了三次。開始吧。」好。我們到底要做什麼？舊系統什麼時候停止變化？最後一次提取是什麼時候？誰來停用自動化，誰來啟動每一次載入？如果到午夜我們落後了兩個小時，或者 3% 的客戶失敗了，怎麼辦？誰來決定是否繼續？我們如何證明資料是對的，使用者什麼時候可以回來？如果情況很糟：**我們怎麼退出？**切換不是「執行遷移」。它是從一個已知狀態到另一個已知狀態的受控過渡。

Start With the Picture

Here’s our landscape one more time. This is the weekend that amber arrow runs, and then disappears. ⟲

點擊放大

The weekend this arrow runs. On Monday morning, it’s gone. ⟲

But more changes that weekend than one arrow. The partners’ manifests stop landing in RouteDesk and start arriving through the integration layer. RouteDesk’s own outbound feeds, Keystone’s nightly status file and Redrock’s webhook, have to come from Salesforce instead. Coordinators route Monday’s deliveries in Field Service, not RouteDesk. And on Monday morning, 330 trucks leave the distribution centers on routes from the new system. Everything in this module is about getting to that Monday safely, and knowing what we’d do if we couldn’t. ⟲

生產切換應該是無聊的

我希望生產切換幾乎讓人感到失望。我們已經跑過這個流程，計過時，見過失敗，測試過繞過機制，對過賬，也練習過恢復正常執行。生產只是用新資料再走一遍同樣的劇本。如果我們在切換週末才在發明遷移，那我們已經有麻煩了。

That takes a dress rehearsal, not “we loaded accounts in the sandbox.” Beginning to end: a final-style extract, transformations, quality checks, the load sequence, automation and integration controls, reconciliation, deferred processing, the return to normal mode, all timed, at production or representative scale, in a Full sandbox. Record how long each step took, what failed, what needed manual help, what confused people, where we waited, what surprised us. Then improve the runbook. The first rehearsal teaches you how the migration works; the next one should prove you learned. And because module 2 brought the keys back, a rehearsal doesn’t have to start from nothing every time: fix one transformation, reload just the rows it touched, and run the reconciliation again. For RouteDesk, that means the whole weekend in a Full sandbox: the extract, the preparation data store, the waves of module 1, the bypass of module 3, the switch of the partners’ feeds, and the reconciliation, with a stopwatch running. ⟲

執行手冊是可執行的架構

不是「週六上午：遷移資料」。而是更接近這樣：

步驟	操作	負責人	預計耗時	證據 / 退出標準
1	Confirm RouteDesk is read-only after Saturday’s last truck	Operations lead	10 min	Written confirmation; time of the last change recorded
2	Final RouteDesk extract into the preparation data store	Data team	45 min	Counts and control totals captured
3	Confirm the bypass on the migration user	Salesforce team	10 min	A test record saves with no status events sent
4	Incremental load: Saturday’s changes, upsert by the partner key	Migration team	30 min	Results and new IDs back in the preparation data store
5	Reconcile against the expected numbers	Data team and operations	30 min	Counts, totals and aggregate reports approved
6	Switch the partners’ manifests and status feeds to the integration layer	Integration team	30 min	One test manifest upserted and one status sent, per partner
…	…	…	…	…
14	Remove the bypass from the migration user	Salesforce team	10 min	Permission set unassigned, and checked

Now we know what happens, who does it, how long we expect, and what proves each step is complete. That’s much stronger than a checklist that says “Load Work Orders.” Notice step 14. Module 3’s bypass is a permission to skip business rules, so taking it away is a runbook step with an owner, not something we hope someone remembers. ⟲

第 −7 天、第 −1 天、第 0 天

I call go-live Day 0: usually a Sunday or another off-hours day. Steve Trucking delivers six days a week, so Day 0 is the Sunday with no trucks on the road. Day +1 is after it; Day −1 and Day −7 are before it. And on any large load, I ask: do I have to wait until Day 0 to load all the data? If the load takes hours and the source keeps changing, I’m going to need an incremental anyway. So: ⟲

• Day −7: the initial load. Load the bulk of the data a week early, kept invisible by sharing, so users and reports don’t see it. Smoke-test users (a system administrator) validate it in place. Ask the business what would be hurt by loading early; if the answer is “it would break my reports,” load it hidden. It’s much simpler to open up the sharing on Day 0 than to spend five hours loading a million records and all their children inside the window. ⟲
• **第 −1 天：重新整理載入。**把自第 −7 天以來變化的內容帶過來，並守住起跑線：使用者還在修改源系統嗎，整合還在寫入嗎，計劃作業還在執行嗎？凍結源系統，把它設為只讀，或者明確規定提取之後的變化將如何被捕獲。
• **第 0 天：增量載入。**載入自第 −1 天以來變化的內容（有時在視窗開始時做一次增量，結束時再做最後一次），對賬，決定 go 或 no-go，開啟共用，恢復正常執行。

For RouteDesk, Day −7 is the Sunday before: the 190,000 delivered Work Orders go in, hidden by sharing, and smoke-test users check them all week. History barely changes, so most of the load is done before the weekend starts. Day −1 is Saturday night, once the last truck is back: RouteDesk goes read-only, and the refresh brings the week’s changes. Day 0 is Sunday: a small incremental, then the gates. ⟲

點擊放大

Day −7: most of the data, a week early, where nobody can see it yet. ⟲

點擊放大

Day −1: the week’s changes, and the source stops moving. ⟲

點擊放大

Day 0: a small incremental, then the gates. ⟲

點擊放大

Day +1: the first truck leaves, and the rollback clock runs out. ⟲

This isn’t an unusual way to cut over; it’s the common one, under other names. Salesforce’s own guidance for moving a B2C Commerce site says to migrate as much data as you can “as close as possible prior to the actual cut-over. Ideally, only the delta from the previous day should be required to copy during the cut-over to minimize the down time” (B2C Commerce Realm Split FAQ （在新標籤頁中開啟）, Salesforce Help). Microsoft’s guidance for its own platform is a full migration “about a month before go-live, followed by weekly delta loads,” with the final delta “after freezing both source and target systems” (Data migration planning for go-live （在新標籤頁中開啟）, Microsoft Learn). And AWS’s database migration service builds the same idea in: a full load while it captures changes, then “shut down your applications, let the remaining changes flow through to the target” (Components of AWS DMS （在新標籤頁中開啟）, AWS; all three checked 2026-10-27). The timing changes with the volume: a month or a week ahead, weekly or daily deltas. The Salesforce twist is the one I add: load early hidden by sharing, so the data is in place and checked, and nobody sees it until Day 0. ⟲

Test knowledge. For a large migration with a short cutover window, load most of the data days early, hidden from users by sharing, then load only what changed (a refresh before the window, an incremental inside it). Freeze or capture changes in the source from the extract onward, and validate with test users before opening access. ⟲

For the cutover, the point is the gates around those loads. By Day −7 I don’t want to be designing the migration anymore: mappings, transformations, the load sequence, automation decisions, migration identities, reconciliation reports, the runbook, rollback criteria and known exceptions are stable, because the real loads have started. Things can still change, but every late change reduces rehearsal. At some point you stop improving the migration and start protecting the cutover. And know when the source stopped moving, or know exactly how you’ll capture what changed after your extract. ⟲

That second half is the watermark: the point through which each extract was current, so the next load knows what changed since. For RouteDesk, the watermark is the moment of each extract: everything RouteDesk changed after Sunday’s Day −7 extract is in Saturday’s refresh. That only works if RouteDesk records when a delivery last changed, so check that it does, and that every DC’s screens update it. If it doesn’t, compare snapshots: extract again and find the differences by key. Slower, but it’s a watermark you can trust. Without one, delta processing is guesswork. ⟲

然後第 0 天就是執行。遵循執行手冊，記錄實際時間、作業 ID、數量、錯誤和決定。如果第 17 步失敗了，不要因為有人覺得能省時間就跳到第 24 步：理解依賴關係，使用恢復程式，更新狀態。團隊應該始終能夠說出我們在哪裡，什麼已經完成，什麼失敗了，下一步是什麼，以及我們是否還在視窗期內。

需要掌控時，把使用者鎖在外面

沒人喜歡停機。但假裝系統可用，而我們正在更換它的地基，可能更糟，「我們要零停機」絕不能悄悄變成「我們完全不知道哪個版本的資料是權威的」。有時最乾淨的策略是把使用者鎖在外面，完成切換，證明結果，再把他們請回來。怎麼做？

• **強硬的方式：**凍結使用者，修改他們的登入時間，或者限制 IP 範圍。**不要停用他們：**那會破壞所有權以及掛在它上面的一切。
• 溫和的方式：一個登入流程（login flow），讓人們可以登入，然後把他們帶到一個等候室：「系統正在維護；請稍後再來。」這比那些讓使用者以為自己帳戶壞了的錯誤要友好。永遠不要把這個登入流程放在系統管理員身上；如果它壞了，就誰也進不去了。
• **永遠留一扇後門：**一組仍然可以進入的系統管理員（以及你的冒煙測試使用者）。
• **工作階段會持續存在。**把使用者鎖在外面，並不會結束已經開啟的工作階段，所以要計劃如何把還在工作的人請出去：一則通知、一個截止時間，或者通過定製開發，提供一種讓他們登出的辦法。

At Steve Trucking it’s Sunday, so the people to plan for are the care agents answering phones, the coordinators getting ready for Monday, and the 300 Retail Partner users who might log in to the portal to check a claim. Login flows are assigned by profile (Custom Login Flows （在新標籤頁中開啟）, Salesforce Help, checked 2026-10-27), so the partners’ profile can get the waiting room (“your deliveries are moving to a new system; back Monday at 6 a.m.”) while the smoke-test users and administrators come and go. ⟲

不要在前一週才臨時想這些。決定使用者將會經歷什麼，並告訴他們。

Test knowledge. To keep users out during a cutover, freeze their accounts, restrict login hours or IP ranges, or use a login flow (assigned by profile) as a waiting room. Don’t deactivate users: it breaks ownership and what’s attached to it. Keep administrators and test users able to log in. ⟲

Go/No-Go 與回滾時鐘

凌晨 2:00，已經幹了十二個小時，這不是發明 go/no-go 標準的時候。在切換之前就定義好它們：關鍵物件已對賬，失敗率低於批准的閾值，沒有未解決的關鍵資料缺陷，必需的關係已驗證，關鍵整合已核實，自動化已恢復並測試，效能可以接受，業務驗證已完成，剩下的時間足夠完成下游步驟。否則，「go」就變成了「我們都走到這一步了」。那不是架構。那是沉沒成本偏差。

“We have a rollback plan.” Good. Until when? We migrate, open Salesforce, and for six hours users create cases, update accounts, enter opportunities, change contact details, while integrations send data elsewhere. Can we restore Friday night? Not without losing legitimate work. Rollback gets harder the longer the new system runs, so define the rollback point: before it, we return to the previous state with the tested procedure; after it, recovery needs a different strategy. Rollback has a clock, and the runbook should show it. For Steve Trucking the clock is easy to read: until Monday’s first truck leaves on a Field Service route, we can still send the coordinators back to RouteDesk, which is why it stays read-only and untouched until then. After that, every delivery made, photo taken and status sent lives only in Salesforce, and going back would lose real work. From that moment, recovery means fixing forward. ⟲

回滾也不只是刪掉你載入的東西。自動化可能已經建立了子記錄，整合可能已經把記錄發到了別處，使用者可能已經修改了遷移過來的記錄，可能已經附上了檔案、釋出了事件、更新了已有的記錄。分散式的影響，正是模組 3 中的自動化和整合控制屬於切換架構的原因。

And what makes you roll back? In my experience it’s rarely the loader. It’s unknown data: you find out something key was missed, or a data feed was running that nobody accounted for. The best rollback plan is not needing it: know all of your key data, and every feed that touches it, before cutover. RouteDesk has two that are easy to forget, because they go out, not in: the nightly status file Keystone picks up, and the webhook that tells Redrock what happened. Retire RouteDesk without moving them, and on Monday night Keystone hears nothing. Nobody loaded the wrong data; a feed just stopped. ⟲

我證明資料的四種方式

載入之後，我不問「API 說成功了嗎？」我要四種證明，而且四種都用：數量、合計、抽查和彙總報表。

**數量。**應該有多少條記錄，實際有多少條？選中的源客戶：500,000。合併的重複：20,000。按批准的策略排除：5,000。預期：475,000。目標：475,000。很好，但光有數量還不算證明；你可能有正確數量的記錄，卻是錯誤的資料。

**合計。**在數字重要的地方，比較控制合計：發票金額、訂單價值、未結餘額、數量。兩個系統都有 100,000 張發票，但遺留系統合計 412,800,000 美元，Salesforce 合計 398,100,000 美元。停下來。合計能暴露數量漏掉的東西。

Spot checks. Look at real records, not just easy ones: a simple record and a complex one, a large customer and a small one, one with many children, one that was transformed, one involved in dedupe, one with unusual history. Trace each from source to target: fields, relationships, ownership, history, External IDs. Averages hide serious individual failures. ⟲

**彙總報表。**比較形狀：按州統計的客戶，按年統計的訂單，按狀態統計的案例，按細分統計的客戶，按月統計的收入。如果源系統說亞利桑那有 82,000 個客戶，而 Salesforce 說有 8,200 個，我們就有了線索：一個沒對映上的州程式碼，一個被排除的年份，一個翻譯錯的狀態，一個被跳過的檔案。行數可能看起來沒問題，而分佈卻說出了真相。

For RouteDesk, each proof has its check, and each catches something the others miss. ⟲

點擊放大

Each proof catches what the others miss. Use all four. ⟲

The aggregate report is the one I’d watch first. Remember module 1’s status codes: nine DCs, nine spellings. If DC 7’s deliveries by week come out 40 percent short against RouteDesk’s, the count for the whole load might still look close, but one DC’s DONE/INST didn’t map. ⟲

Test knowledge. Prove a migration with more than “no errors”: record counts against expected numbers set before the load, control totals on amounts that matter, spot checks of real records traced end to end, and aggregate reports that compare the shape of the data. Business owners validate it too. ⟲

還有兩條規則與之配套。第一，在載入之前定好預期的數字（模組 1）：源數量、批准的排除、合併的重複、被隔離的記錄、預期的目標。然後比較並解釋差異。一個看到結果之後才編出來的預期數字不叫對賬；那叫合理化。第二，**零錯誤也可能是錯的。**把賬單州對映到了收貨州，每一行都載入成功，沒有任何 API 錯誤：技術執行完美，架構卻是錯的。這就是為什麼業務對賬很重要，而不只是技術日誌。

業務負責人也要驗證

技術團隊可以證明數量、鍵、關係和載入成功。業務使用者能認出我們認不出的東西：「這些不是我們的活躍客戶」「那個狀態從 2022 年起就沒用過了」「這些客戶被分到了錯誤的區域」「這個客戶應該有三份有效的合同」。所以業務驗證是一個明確的上線步驟，有指定的人、指定的報表、指定的記錄和指定的批准，而不是「有空的時候看一眼」。

Authority Moves on Day 0

Why not move everything on Day 0? The Number of Zeros. If the full migration takes 18 hours and the business tolerates 4 hours of downtime, we have a problem, and moving data earlier solves it. History goes in before cutover while the legacy system stays authoritative; the window only has to handle what changed, what couldn’t be preloaded, final relationships, validation and reconciliation. Instead of moving eight years of history during the outage, we’re closing a gap. ⟲

But preloaded data needs protection. If production data lands on Day −7, can users see it, edit it, can automation react, can integrations publish it, can agents act on it? The answer should be: not yet. So we keep it hidden by sharing, owned and controlled, with automation and integrations held back (module 3). A preload isn’t “put the records in early.” It’s put them in early without accidentally making the new system authoritative early. ⟲

Before cutover, the legacy system is authoritative and Salesforce holds a staged, increasingly current copy. During cutover we close the gap. At the agreed moment, authority moves, and afterward Salesforce is authoritative. For Steve Trucking that moment is Day 0: from then on, a delivery’s truth lives in Salesforce, and RouteDesk is a read-only record of the past. That’s where chapters 6, 9 and 10 meet: identity, authority, movement and cutover aren’t separate problems; they’re views of the same data lifecycle. ⟲

So don’t let two systems both think they’re master. If the legacy system stays writable after cutover, a coordinator changes a delivery window in Salesforce, another changes it in the legacy system, and both systems think they own it. Last write wins? Salesforce wins? Human review? If that’s unanswered, we haven’t finished a migration; we’ve created two writable copies. Chapter 9’s rule: technical permission isn’t architectural authority. ⟲

Not every migration needs ongoing synchronization. If we’re replacing the legacy system completely, Day 0 comes, the final deltas load, reconciliation passes, users move, the old system goes read-only and is eventually archived or retired. Don’t build a permanent integration because “migrations usually have integrations.” If the old system is dead, stop feeding it. That’s RouteDesk: on Monday it’s read-only, then it’s retired, and nothing syncs with it. The synchronization Steve Trucking does need is a different arrow, Salesforce to Snowflake, designed in chapter 9 and covered in module 5. ⟲

點擊放大

The gap closes, authority moves, and the migration ends. The Snowflake feed goes on. ⟲

The opposite happens too. A transition that lasts months, users active in both systems, business units moving at different times: synchronization may have to start before the migration is finished. Now the migration is still moving the historical baseline while synchronization keeps live records consistent, and that’s a much harder architecture. You need to know which process owns which changes, or the load and the sync overwrite each other. So define the boundary visibly: before this point we’re building the target state; after it we’re maintaining consistency. It might be a timestamp, a cutover event, a business-unit transition, an object-by-object switch, a watermark. If nobody can tell me whether a record belongs to the migration process or the synchronization process, we have overlapping ownership, and that’s where records get missed or processed twice. ⟲

恢復正常，然後進入強化支援期

Restore normal operation deliberately: automation, scheduled jobs, integrations, event consumers, agents, user access, in an order that matters. For Steve Trucking: take the bypass away from the migration user, switch the Change Data Capture subscriber back on from the cutover point (so Snowflake gets Monday’s changes, not the weekend’s load), run module 3’s one backfill, then let the coordinators in. Remember module 3’s catch-up storm: when an integration comes back, what does it think happened while it was off? When users come back, is every critical service actually ready? The return to normal is part of the cutover. ⟲

然後我們上線了，但還沒有結束。在一段穩定期內（可以叫它強化支援期，hypercare），要留意遷移錯誤、整合失敗、意外的自動化、新的重複、缺失的關係、效能問題、使用者報告的資料問題和對賬偏差。遷移的風險不會在使用者登入的那一刻消失。

Then clean up: temporary migration users and permissions, bypass settings, staging data, temporary scripts, migration-only configuration, files holding sensitive source data, temporary integrations, runbook access. Don’t leave migration scaffolding attached to production because “we might need it someday.” Temporary architecture needs an exit plan too. Don’t forget the preparation data store. After RouteDesk, it holds eight years of Recipients’ names, addresses and phone numbers in its raw tables. Keep what the retention policy says to keep, as evidence, then delete the rest, on a date someone owns. ⟲

還要保留證據：最終提取、轉換版本、載入檔案、作業結果、錯誤檔案、對賬報表、批准記錄、記有實際時間的執行手冊、go/no-go 決定和各項例外。三週後，會有人問某條記錄是在遷移之前就錯了，還是因為遷移才錯的。你應該能夠回答。信任，但要驗證，並不在載入完成時結束。

AI 可以幫忙盯著切換。Go/No-Go 不歸它管。

在切換的壓力下，AI 很有用：彙總失敗、給錯誤分類、比較報表、發現異常、追蹤執行手冊、指出與演練的偏差。但 go/no-go 綜合了技術證據、業務影響、剩餘時間、回滾位置和風險承受能力。AI 可以把證據擺出來。由負有責任的人來做決定。

**考試之外：AI 改變了什麼。**AI 可以讓切換的監控和對賬更快，尤其是在大量錯誤和驗證資料中發現模式。對於 go/no-go、回滾以及接受未解決的遷移風險，要保留明確的人類負責制。

架構師在這裡決定什麼

• The rehearsal depth, the Day −7 / Day −1 / Day 0 load plan and the rollback point (what loads early, hidden by sharing) and the runbook that makes production cutover repeatable. ⟲
• 如何把使用者鎖在外面、再把他們放回來，留有後門和冒煙測試使用者，以及在此期間如何控制自動化、整合和代理程式。
• go/no-go 標準、回滾程式，以及回滾不再是安全恢復手段的那個時間點，還有必須先找出來的未知資料和資料來源。
• 如何用數量、合計、抽查和彙總報表，對照載入之前設定的預期值來證明遷移。
• 在遷移完成之前，需要什麼樣的業務驗證、證據和上線後的穩定期。

切換就是證明

指令碼跑完了：不夠。API 返回成功：不夠。行數對上了：仍然不夠。我要數量、合計、抽查和彙總報表，要業務驗證，要系統恢復正常，要知道我們是否還在回滾視窗內，還要有確切記錄發生了什麼的證據。生產切換應該是無聊的，因為我們在週五晚上之前就把難的思考做完了。**信任，但要驗證。**然後再讓使用者回來。

延伸探索

• Others who cut over the same way: Salesforce Help, B2C Commerce Realm Split FAQ （在新標籤頁中開啟）; Microsoft Learn, Data migration planning for go-live （在新標籤頁中開啟）; AWS, Components of AWS DMS （在新標籤頁中開啟）; all checked 2026-11-01. ⟲
• Salesforce Help: Freeze or Unfreeze User Accounts （在新標籤頁中開啟） and Custom Login Flows （在新標籤頁中開啟） (login flows are assigned by profile), checked 2026-11-01. ⟲
• 本課程中：主資料與身分和整合與資料流動。