切り替えの週末

🌐 ほかに 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回テストしました。始めましょう」。いいでしょう。私たちはまさに何をしようとしているのでしょう？　古いシステムはいつ変わらなくなるのか？　最終の抽出はいつか？　誰が自動化を止め、誰が各ロードを始めるのか？　深夜0時に2時間遅れていたら、あるいは取引先の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. ⟲

Day −7、Day −1、Day 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. ⟲
• **Day −1：更新のロード。**Day −7以降に変わったものを移し、スタートラインを守ります。ユーザーはまだソースを変えているか、統合は書き込んでいるか、スケジュールされたジョブは動いているか？　ソースを凍結するか、読み取り専用にするか、抽出のあとの変更をどう捕まえるかを正確に決めておきます。
• **Day 0：差分。**Day −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. ⟲

そしてDay 0は実行です。ランブックに従い、実際の時刻、ジョブID、件数、エラー、判断を記録します。ステップ17が失敗したら、時間の節約になると誰かが思ったからといってステップ24に飛ばないこと。依存関係を理解し、復旧の手順を使い、状態を更新します。チームはいつでも、今どこにいるか、何が終わり、何が失敗し、次は何か、まだ時間帯の中にいるかを言えるべきです。

管理が必要なときはユーザーを締め出す

停止時間が好きな人はいません。でも、土台を変えている最中にシステムが使えるふりをするほうが悪いこともあり、「停止時間ゼロにしたい」が、いつのまにか「どの版のデータに権威があるのか見当もつかない」にすり替わってはいけません。最もすっきりした戦略が、ユーザーを締め出し、切り替えを行い、結果を証明して、ユーザーを戻すことである場合もあります。どうやって？

• **強いやり方：**ユーザーを凍結する、ログイン時間帯を変える、IP範囲を制限する。**無効化はしないこと：**所有と、それに結びついたものすべてが壊れます。
• やわらかいやり方：ログインはさせて、待合室に案内するログインフロー。「システムはメンテナンス中です。あとでもう一度お越しください」。自分のアカウントが壊れたとユーザーに思わせるエラーより親切です。そのログインフローを決してシステム管理者にかけないこと。壊れたら誰も入れなくなります。
• **必ず裏口を残す：**入れるシステム管理者（とスモークテスト用のユーザー）を何人か。
• **セッションは残る。**ユーザーを締め出しても、すでに開いているセッションは終わりません。作業を続けている人をどう退出させるかを計画しましょう。お知らせ、期限、あるいは独自の作り込みでログアウトさせる方法。

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、そしてロールバックの時計

12時間経った午前2時は、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. ⟲

データを証明する4つの方法

ロードのあと、私は「APIは成功と言ったか？」とは尋ねません。4種類の証明が欲しく、その4つすべてを使います。件数、合計、抜き取り確認、集計レポート。

**件数。**何件のレコードが存在すべきで、何件存在するか？　選んだソースの取引先：50万件。統合した重複：2万件。承認したポリシーで除外：5,000件。予定：47万5,000件。ターゲット：47万5,000件。結構です。でも件数だけでは証明になりません。レコードの件数は正しくて、データが間違っていることもあり得ます。

**合計。**数字が重要なところでは、管理合計を比べます。請求額、注文の金額、未払いの残高、数量。両方のシステムに10万件の請求書があっても、レガシーの合計は4億1,280万ドルでSalesforceは3億9,810万ドル。止まってください。合計は、件数が見逃すものを暴きます。

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. ⟲

**集計レポート。**形を比べましょう。州ごとの取引先、年ごとの注文、状況ごとのケース、区分ごとの顧客、月ごとの売上。ソースではアリゾナの顧客が8万2,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. ⟲

これには2つのルールが伴います。1つ目、予定の数字をロードの前に決めておく（モジュール1）。ソースの件数、承認した除外、統合した重複、隔離したレコード、予定のターゲット。そのうえで比べ、差を説明します。結果を見てから作った予定の数字は照合ではなく、こじつけです。2つ目、**エラー0件でも間違っていることがある。**Billing StateをShipping Stateにマッピングすれば、すべての行がAPIのエラーなしでロードされます。技術的には完璧な実行で、アーキテクチャとしては間違いです。だから技術的なログだけでなく、ビジネスの照合が重要なのです。

ビジネスの責任者も検証する

技術チームは、件数、キー、リレーション、ロードの成功を証明できます。ビジネスのユーザーは、私たちにはわからないものに気づきます。「これはうちの現役の顧客じゃない」「その状況は2022年から使っていない」「これらの取引先は違う地域のものだ」「この顧客には現行の契約が3件あるはずだ」。だからビジネスの検証は、本番稼働の明示的なステップです。名前のある人、名前のあるレポート、名前のあるレコード、名前のある承認とともに。「時間があるときに見ておいて」ではありません。

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. ⟲

そして本番稼働しても、終わりではありません。安定化の期間（ハイパーケアと呼びましょう）には、移行のエラー、統合の失敗、予期しない自動化、新しい重複、欠けたリレーション、性能の問題、ユーザーが報告するデータの問題、照合のずれを見張ります。移行のリスクは、ユーザーがログインした瞬間に消えるわけではありません。

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の判断、そして例外。3週間後、あるレコードが移行の前から間違っていたのか、移行のせいなのかを誰かが尋ねます。答えられるべきです。信頼しつつ検証するは、ロードが終わっても終わりません。

AIは切り替えの見張りを助けられる。go/no-goはAIのものではない

切り替えのプレッシャーの下で、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. ⟲
• このコースの中では：マスターデータとIDと統合とデータの移動。