切换周末

🌐 另有 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. ⟲
• 本课程中：主数据与身份和集成与数据流动。