전환 주말

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

Data Architect 과정 10장인 마이그레이션과 동기화의 모듈 4/5. 각 모듈은 독립적으로 읽을 수 있습니다. 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. ⟲

D−7, D−1, D-데이

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. ⟲
• D−1: 갱신 적재. D−7 이후 바뀐 것을 가져오고, 출발선을 지키십시오. 사용자가 아직 원본을 바꾸고 있나요, 통합이 쓰고 있나요, 예약 작업이 돌고 있나요? 원본을 동결하거나, 읽기 전용으로 만들거나, 추출 이후의 변경을 어떻게 잡을지 정확히 정하십시오.
• D-데이: 증분. D−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. ⟲

그러면 D-데이는 실행입니다. 런북을 따르고, 실제 시간, 작업 ID, 건수, 오류, 결정을 기록하십시오. 17단계가 실패하면, 누군가 시간을 아낀다고 생각한다고 24단계로 건너뛰지 마십시오. 의존성을 이해하고, 복구 절차를 쓰고, 상태를 갱신하십시오. 팀은 언제나 지금 어디에 있는지, 무엇이 끝났고, 무엇이 실패했고, 다음은 무엇이고, 아직 창 안에 있는지 말할 수 있어야 합니다.

통제가 필요할 때는 사용자를 막으십시오

아무도 다운타임을 좋아하지 않습니다. 하지만 기반을 바꾸는 동안 시스템을 쓸 수 있는 척하는 것이 더 나쁠 수 있고, “다운타임 제로를 원해요”가 조용히 “어느 버전의 데이터가 권한 원천인지 전혀 모르겠어요”가 되어서는 안 됩니다. 때로는 가장 깔끔한 전략이 사용자를 막고, 전환을 하고, 결과를 증명하고, 다시 들이는 것입니다. 어떻게요?

• 강한 방법: 사용자를 동결하거나, 로그인 시간을 바꾸거나, IP 범위를 제한합니다. 비활성화하지는 마십시오. 소유권과 거기 붙은 모든 것이 깨집니다.
• 부드러운 방법: 사람들이 로그인하면 대기실로 보내는 로그인 Flow입니다. “시스템 점검 중입니다. 나중에 다시 오십시오.” 사용자가 자기 계정이 고장 났다고 생각하게 만드는 오류보다 친절합니다. 그 로그인 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시는 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가 성공이라고 했나요?”라고 묻지 않습니다. 네 종류의 증명을 원하고, 넷 다 씁니다. 건수, 합계, 샘플 점검, 집계 보고서.

건수. 레코드가 몇 개 있어야 하고, 몇 개 있나요? 선택된 원본 계정 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. ⟲

여기에 규칙 두 가지가 따릅니다. 첫째, 적재 전에 예상 숫자를 정하십시오(모듈 1). 원본 건수, 승인된 제외, 통합된 중복, 격리된 레코드, 예상 대상. 그다음 비교하고 차이를 설명하십시오. 결과를 본 뒤에 지어낸 예상 숫자는 대사가 아니라 합리화입니다. 둘째, 오류 0건도 틀릴 수 있습니다. Billing State를 Shipping State로 매핑해도 모든 행은 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. ⟲

그러면 운영이 시작되었지만 끝난 것은 아닙니다. 안정화 기간(하이퍼케어라고 부르십시오) 동안 마이그레이션 오류, 통합 실패, 예상 못한 자동화, 새 중복, 빠진 관계, 성능 문제, 사용자가 보고한 데이터 문제, 대사 편차를 지켜보십시오. 사용자가 로그인하는 순간 마이그레이션 위험이 사라지지는 않습니다.

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. ⟲
• 이 과정에서: 마스터 데이터와 정체성, 통합과 데이터 이동.