Geçiş Hafta Sonu

🌐 19 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku Bu bölüm İngilizcede değişti ve henüz yeniden çevrilmedi. (54)

Data Architect kursunun 10. bölümü olan Taşıma ve Eşitleme bölümündeki 5 modülden 4.‘sü. Her modül kendi başına okunabilir. Previous: Automation During the Load · Next: Getting Data Out: Keeping Another System in Step ⟲

Bu modülün yanıtladığı soru: Geçişi nasıl yaparsınız ve taşımanın çalıştığını nasıl kanıtlarsınız?

Cuma gecesi. Kullanıcılar çıktı, taşıma ekibi çevrimiçi ve biri diyor ki: “Bunu üç kez test ettik. Hadi başlayalım.” Tamam. Tam olarak ne yapmak üzereyiz? Eski sistem ne zaman değişmeyi bırakıyor? Son çıkarım ne zaman? Otomasyonu kim kapatıyor, her yüklemeyi kim başlatıyor? Gece yarısı iki saat gerideysek ya da hesapların yüzde 3’ü başarısız olursa ne olacak? Devam edip etmeyeceğimize kim karar veriyor? Verinin doğru olduğunu nasıl kanıtlıyoruz ve kullanıcılar ne zaman geri dönebilir? Ve işler kötü giderse: nasıl çıkarız? Geçiş “taşımayı çalıştır” değildir. Bilinen bir durumdan diğerine kontrollü bir geçiştir.

Start With the Picture

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

Büyütmek için tıklayın

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

Üretim Sıkıcı Olmalı

Üretim geçişinin neredeyse hayal kırıklığı yaratacak kadar sakin geçmesini isterim. Süreci zaten çalıştırdık, süresini ölçtük, hataları gördük, atlamaları test ettik, sonuçları uzlaştırdık ve normal işleyişi geri getirmeyi prova ettik. Üretim, yeni veriyle aynı oyun kitabıdır. Taşımayı geçiş hafta sonunda icat ediyorsak zaten başımız dertte.

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

Çalıştırma Kılavuzu Yürütülebilir Mimaridir

“Cumartesi sabahı: veriyi taşı” değil. Daha çok şunun gibi:

Adım	Eylem	Sahip	Beklenen süre	Kanıt / çıkış ölçütü
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. ⟲

G−7, G−1, G Günü

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. ⟲
• G−1: tazeleme yüklemesi. G−7’den beri değişenleri getirin ve başlangıç çizgisini koruyun: kullanıcılar hâlâ kaynağı değiştiriyor mu, entegrasyonlar yazıyor mu, zamanlanmış işler çalışıyor mu? Kaynağı dondurun, salt okunur yapın ya da çıkarımdan sonraki değişikliklerin tam olarak nasıl yakalanacağını tanımlayın.
• G Günü: artımlı yükleme. G−1’den beri değişenleri yükleyin (bazen pencerenin başında bir artımlı, sonunda son bir tane), uzlaştırın, go veya no-go kararı verin, paylaşımı açın, normal işleyişi geri getirin.

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

Büyütmek için tıklayın

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

Büyütmek için tıklayın

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

Büyütmek için tıklayın

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

Büyütmek için tıklayın

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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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. ⟲

Sonra G Günü yürütmedir. Çalıştırma kılavuzunu izleyin, gerçek süreleri, iş kimliklerini, sayıları, hataları ve kararları kaydedin. 17. adım başarısız olursa, biri zaman kazandıracağını düşündüğü için 24. adıma atlamayın: bağımlılığı anlayın, kurtarma prosedürünü kullanın, durumu güncelleyin. Ekip her zaman nerede olduğumuzu, neyin tamamlandığını, neyin başarısız olduğunu, sırada ne olduğunu ve hâlâ pencerenin içinde olup olmadığımızı söyleyebilmelidir.

Kontrole İhtiyacınız Olduğunda Kullanıcıları Dışarıda Tutun

Kimse kesinti sevmez. Ama temelini değiştirirken sistemin kullanılabilir olduğunu varsaymak daha kötü olabilir ve “sıfır kesinti istiyoruz” sessizce “verinin hangi sürümünün esas olduğu hakkında hiçbir fikrimiz yok”a dönüşmemelidir. Bazen en temiz strateji kullanıcıları dışarıda tutmak, geçişi yapmak, sonucu kanıtlamak ve onları geri getirmektir. Nasıl?

• Sert yollar: kullanıcıları dondurun, oturum açma saatlerini değiştirin ya da IP aralıklarını kısıtlayın. Onları devre dışı bırakmayın: bu sahipliği ve ona bağlı her şeyi bozar.
• Yumuşak yol: insanların oturum açmasına izin verip onları bir bekleme odasına bırakan bir oturum açma akışı (login flow): “sistem bakımda; lütfen daha sonra tekrar gelin.” Kullanıcılara hesaplarının bozuk olduğunu düşündüren hatalardan daha dostane. O oturum açma akışını asla sistem yöneticilerine koymayın; bozulursa kimse giremez.
• Her zaman bir arka kapı bırakın: hâlâ girebilen bir grup sistem yöneticisi (ve duman testi kullanıcılarınız).
• Oturumlar devam eder. Kullanıcıları dışarıda tutmak zaten açık olan oturumları sonlandırmaz, bu yüzden hâlâ çalışan insanları nasıl dışarı alacağınızı planlayın: bir duyuru, bir son tarih ya da özel geliştirmeyle onların oturumunu kapatmanın bir yolu.

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 (yeni sekmede açılır), 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. ⟲

Bunu bir hafta önceden uydurmayın. Kullanıcıların ne yaşayacağına karar verin ve onlara söyleyin.

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 ve Geri Alma Saati

Gece saat 2:00, on iki saat geçmişken go/no-go ölçütlerini icat etme zamanı değildir. Onları geçişten önce tanımlayın: kritik nesneler uzlaştırıldı, hata oranı onaylı eşiğin altında, çözülmemiş kritik veri kusuru yok, gerekli ilişkiler doğrulandı, kritik entegrasyonlar doğrulandı, otomasyon geri getirildi ve test edildi, performans kabul edilebilir, iş doğrulaması yapıldı, aşağı akış adımları için yeterli zaman kaldı. Aksi hâlde “go”, “bu kadar yol geldik”e dönüşür. Bu mimari değil. Batık maliyet yanılgısıdır.

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

Geri alma, yüklediğinizi silmekten de ibaret değildir. Otomasyon alt kayıtlar oluşturmuş, entegrasyonlar kayıtları başka yerlere göndermiş, kullanıcılar taşınan kayıtları değiştirmiş, dosyalar eklenmiş, olaylar yayımlanmış, var olan kayıtlar güncellenmiş olabilir. Dağıtık etkiler, modül 3’ün otomasyon ve entegrasyon kontrollerinin neden geçiş mimarisi olduğunu açıklar.

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

Veriyi Kanıtlamanın Dört Yolum

Yüklemeden sonra “API başarılı dedi mi?” diye sormam. Dört tür kanıt isterim ve dördünü de kullanırım: sayılar, toplamlar, nokta kontroller ve toplu raporlar.

Sayılar. Kaç kayıt olmalı ve kaç tane var? Seçilen kaynak hesaplar: 500.000. Birleştirilen yinelenmeler: 20.000. Onaylı politikayla hariç tutulan: 5.000. Beklenen: 475.000. Hedef: 475.000. İyi, ama sayılar tek başına kanıt değildir; doğru sayıda kayda ve yanlış veriye sahip olabilirsiniz.

Toplamlar. Rakamların önemli olduğu yerde kontrol toplamlarını karşılaştırın: fatura tutarı, sipariş değeri, açık bakiye, miktar. İki sistemde de 100.000 fatura var, ama eski sistemin toplamı 412.800.000 dolar, Salesforce’unki 398.100.000 dolar. Durun. Toplamlar, sayıların kaçırdığını ortaya çıkarır.

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

Toplu raporlar. Biçimi karşılaştırın: eyalete göre hesaplar, yıla göre siparişler, duruma göre vakalar, segmente göre müşteriler, aya göre gelir. Kaynak Arizona’da 82.000 müşteri, Salesforce 8.200 diyorsa bir ipucumuz var: eşlenmemiş bir eyalet kodu, hariç tutulmuş bir yıl, yanlış çevrilmiş bir durum, atlanmış bir dosya. Satır sayısı iyi görünürken dağılım hikâyeyi anlatabilir.

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

Büyütmek için tıklayın

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

Bunlarla birlikte iki kural gelir. Birincisi, beklenen rakamları yüklemeden önce belirleyin (modül 1): kaynak sayısı, onaylı hariç tutmalar, birleştirilen yinelenmeler, karantinadaki kayıtlar, beklenen hedef. Sonra karşılaştırın ve farkı açıklayın. Sonucu gördükten sonra uydurulan beklenen bir rakam uzlaştırma değil, gerekçelendirmedir. İkincisi, sıfır hata yine de yanlış olabilir. Billing State’i Shipping State’e eşleyin; her satır hiçbir API hatası olmadan yüklenir: kusursuz teknik yürütme, yanlış mimari. Bu yüzden yalnızca teknik günlükler değil, iş uzlaştırması önemlidir.

İş Sahipleri de Doğrular

Teknik ekip sayıları, anahtarları, ilişkileri ve yükleme başarısını kanıtlayabilir. İş kullanıcıları bizim tanıyamayacağımızı tanır: “bunlar aktif müşterilerimiz değil”, “o durum 2022’den beri kullanılmıyor”, “bu hesaplar yanlış bölgeye ait”, “bu müşterinin üç aktif sözleşmesi olmalı”. Bu yüzden iş doğrulaması, adı belli kişiler, adı belli raporlar, adı belli kayıtlar ve adı belli bir onayla açık bir canlıya geçiş adımıdır; “vaktiniz olunca bir bakın” değil.

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

Büyütmek için tıklayın

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

Normale Dönüş, Sonra Yoğun Destek

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

Sonra canlıdayız ama bitmedi. Bir dengeleme dönemi boyunca (buna yoğun destek, hypercare diyelim) taşıma hatalarını, entegrasyon hatalarını, beklenmedik otomasyonu, yeni yinelenmeleri, eksik ilişkileri, performans sorunlarını, kullanıcıların bildirdiği veri sorunlarını ve uzlaştırma kaymasını izleyin. Taşıma riski kullanıcılar oturum açtığı anda ortadan kalkmaz.

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

Ve kanıtı saklayın: son çıkarım, dönüşüm sürümü, yükleme dosyaları, iş sonuçları, hata dosyaları, uzlaştırma raporları, onaylar, gerçek sürelerle çalıştırma kılavuzu, go/no-go kararı ve istisnalar. Üç hafta sonra biri bir kaydın taşımadan önce mi yoksa taşıma yüzünden mi yanlış olduğunu soracak. Yanıtlayabilmelisiniz. Güven ama doğrula, yükleme tamamlanınca bitmez.

Yapay Zekâ Geçişi İzlemeye Yardım Edebilir. Go/No-Go Ona Ait Değildir.

Yapay zekâ geçiş baskısı altında yararlıdır: hataları özetlemek, hataları sınıflandırmak, raporları karşılaştırmak, anormallikleri fark etmek, çalıştırma kılavuzunu izlemek, provadan sapmaları ortaya çıkarmak. Ama go/no-go teknik kanıtı, iş etkisini, kalan zamanı, geri alma konumunu ve risk toleransını birleştirir. Yapay zekâ kanıtı ortaya koyabilir. Kararı sorumlu insanlar verir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yapay zekâ geçiş izlemesini ve uzlaştırmasını, özellikle büyük hata ve doğrulama veri kümelerinde kalıplar bularak hızlandırabilir. Go/no-go’nun, geri almanın ve çözülmemiş taşıma riskini kabul etmenin açık insan sahipliğini koruyun.

Mimarın Burada Karar Verdikleri

• 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. ⟲
• Kullanıcıların bir arka kapı ve duman testi kullanıcılarıyla nasıl dışarıda tutulup geri alındığı ve bu sırada otomasyonun, entegrasyonların ve ajanların nasıl kontrol edildiği.
• Go/no-go ölçütleri, geri alma prosedürü ve geri almanın güvenli kurtarma olmaktan çıktığı nokta; ve önce bulunması gereken bilinmeyen veri ve veri akışları.
• Taşımanın yüklemeden önce belirlenen beklenen değerlere karşı sayılar, toplamlar, nokta kontroller ve toplu raporlarla nasıl kanıtlandığı.
• Taşıma tamamlanmadan önce hangi iş doğrulamasının, kanıtın ve canlıya geçiş sonrası dengelemenin gerektiği.

Geçiş Bir Kanıttır

Betikler çalıştı: yetmez. API başarı döndürdü: yetmez. Satır sayıları tuttu: hâlâ yetmez. Sayılar, toplamlar, nokta kontroller ve toplu raporlar, iş doğrulaması, normale dönmüş bir sistem, hâlâ geri alma penceresinde olup olmadığımızın bilgisi ve tam olarak ne olduğunun kanıtını isterim. Üretim geçişi sıkıcı olmalıdır, çünkü zor düşünmeyi cuma gecesinden önce yaptık. Güven ama doğrula. Sonra kullanıcıları içeri alın.

Daha Fazlası

• Others who cut over the same way: Salesforce Help, B2C Commerce Realm Split FAQ (yeni sekmede açılır); Microsoft Learn, Data migration planning for go-live (yeni sekmede açılır); AWS, Components of AWS DMS (yeni sekmede açılır); all checked 2026-11-01. ⟲
• Salesforce Help: Freeze or Unfreeze User Accounts (yeni sekmede açılır) and Custom Login Flows (yeni sekmede açılır) (login flows are assigned by profile), checked 2026-11-01. ⟲
• Bu kursta: Ana Veri ve Kimlik ve Entegrasyon ve Veri Hareketi.