Le week-end de bascule
Aussi en 19 langues
English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 4 sur 5 du chapitre Migration et synchronisation, chapitre 10 du cours Data Architect. Chaque module est autonome. Previous: Automation During the Load · Next: Getting Data Out: Keeping Another System in Step ⟲
La question à laquelle répond ce module : comment basculer, et prouver que la migration a fonctionné ?
C’est vendredi soir. Les utilisateurs sont partis, l’équipe de migration est en ligne, et quelqu’un dit : « On l’a testé trois fois. Allons-y. » D’accord. Qu’allons-nous faire exactement ? Quand l’ancien système cesse-t-il de changer ? Quand a lieu l’extraction finale ? Qui désactive l’automatisation, qui lance chaque chargement ? Et si nous avons deux heures de retard à minuit, ou si 3 % des comptes échouent ? Qui décide si nous continuons ? Comment prouvons-nous que les données sont justes, et quand les utilisateurs peuvent-ils revenir ? Et si cela tourne mal : comment en sortons-nous ? La bascule, ce n’est pas « lancer la migration ». C’est une transition maîtrisée d’un état connu à un autre.
Start With the Picture
Section intitulée « 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. ⟲
La production doit être ennuyeuse
Section intitulée « La production doit être ennuyeuse »Je veux que la bascule en production soit presque décevante. Nous avons déjà exécuté le processus, nous l’avons chronométré, nous avons vu les échecs, testé les contournements, rapproché les résultats et nous sommes entraînés à rétablir le fonctionnement normal. La production, c’est le même scénario avec de nouvelles données. Si nous inventons la migration le week-end de bascule, nous sommes déjà en difficulté.
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. ⟲
Le runbook est de l’architecture exécutable
Section intitulée « Le runbook est de l’architecture exécutable »Pas « samedi matin : migrer les données ». Quelque chose de plus proche de :
| Étape | Action | Responsable | Durée prévue | Preuve / critère de sortie |
|---|---|---|---|---|
| 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. ⟲
J−7, J−1, J0
Section intitulée « J−7, J−1, J0 »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. ⟲
- J−1 : le chargement de rafraîchissement. Reprenez ce qui a changé depuis le J−7, et protégez la ligne de départ : les utilisateurs modifient-ils encore la source, des intégrations écrivent-elles, des traitements planifiés tournent-ils ? Gelez la source, mettez-la en lecture seule, ou définissez exactement comment les changements postérieurs à l’extraction seront capturés.
- J0 : l’incrémental. Chargez ce qui a changé depuis le J−1 (parfois un incrémental au début de la fenêtre et un dernier à la fin), rapprochez, décidez du go ou du no-go, ouvrez le partage, rétablissez le fonctionnement normal.
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 (s'ouvre dans un nouvel onglet), 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 (s'ouvre dans un nouvel onglet), 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 (s'ouvre dans un nouvel onglet), 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. ⟲
Le J0, c’est alors de l’exécution. Suivez le runbook, notez les temps réels, les ID de traitement, les décomptes, les erreurs et les décisions. Si l’étape 17 échoue, ne sautez pas à l’étape 24 parce que quelqu’un pense gagner du temps : comprenez la dépendance, utilisez la procédure de reprise, mettez à jour l’état. L’équipe doit toujours pouvoir dire où nous en sommes, ce qui est terminé, ce qui a échoué, ce qui vient ensuite, et si nous sommes encore dans la fenêtre.
Bloquez l’accès des utilisateurs quand vous avez besoin de maîtriser
Section intitulée « Bloquez l’accès des utilisateurs quand vous avez besoin de maîtriser »Personne n’aime l’indisponibilité. Mais faire comme si le système était disponible pendant que nous changeons ses fondations peut être pire, et « nous voulons zéro indisponibilité » ne doit pas devenir discrètement « nous n’avons aucune idée de la version des données qui fait autorité ». Parfois, la stratégie la plus propre, c’est de bloquer l’accès des utilisateurs, de faire la bascule, de prouver le résultat et de les faire revenir. Comment ?
- Les méthodes fortes : geler les utilisateurs, changer leurs heures de connexion, ou restreindre les plages d’adresses IP. Ne les désactivez pas : cela casse la propriété et tout ce qui s’y rattache.
- La méthode douce : un login flow qui laisse les gens se connecter et les dépose dans une salle d’attente : « le système est en maintenance ; revenez plus tard ». Plus aimable que des erreurs qui font croire aux utilisateurs que leur compte est cassé. Ne mettez jamais ce login flow sur les administrateurs système ; s’il casse, plus personne n’entre.
- Gardez toujours une porte de service : un groupe d’administrateurs système (et vos utilisateurs de test de fumée) qui peuvent encore entrer.
- Les sessions persistent. Bloquer l’accès des utilisateurs ne met pas fin aux sessions déjà ouvertes, alors prévoyez comment faire sortir ceux qui travaillent encore : un avis, une échéance, ou, avec un développement spécifique, un moyen de les déconnecter.
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 (s'ouvre dans un nouvel onglet), 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. ⟲
N’improvisez pas cela la semaine d’avant. Décidez de ce que vivront les utilisateurs, et dites-le-leur.
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. ⟲
Le go/no-go, et l’horloge du retour arrière
Section intitulée « Le go/no-go, et l’horloge du retour arrière »À 2 h du matin, après douze heures, ce n’est pas le moment d’inventer les critères de go/no-go. Définissez-les avant la bascule : objets critiques rapprochés, taux d’échec sous un seuil approuvé, aucun défaut de données critique non résolu, relations obligatoires validées, intégrations critiques vérifiées, automatisation rétablie et testée, performance acceptable, validation métier faite, assez de temps restant pour les étapes en aval. Sinon, « go » devient « on est allés trop loin pour s’arrêter ». Ce n’est pas de l’architecture. C’est le biais des coûts irrécupérables.
“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. ⟲
Le retour arrière, ce n’est pas non plus simplement supprimer ce que vous avez chargé. L’automatisation a peut-être créé des enfants, les intégrations ont peut-être envoyé des enregistrements ailleurs, les utilisateurs ont peut-être modifié des enregistrements migrés, des fichiers ont peut-être été joints, des événements publiés, des enregistrements existants mis à jour. Ces effets distribués sont la raison pour laquelle les contrôles d’automatisation et d’intégration du module 3 relèvent de l’architecture de la bascule.
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. ⟲
Quatre façons dont je prouve les données
Section intitulée « Quatre façons dont je prouve les données »Après le chargement, je ne demande pas « l’API a-t-elle dit succès ? ». Je veux quatre types de preuve, et je les utilise tous les quatre : décomptes, totaux, vérifications par sondage et rapports agrégés.
Les décomptes. Combien d’enregistrements devraient exister, et combien existent ? Comptes source sélectionnés : 500 000. Doublons consolidés : 20 000. Exclus selon une politique approuvée : 5 000. Attendus : 475 000. Cible : 475 000. Bien, mais les décomptes seuls ne sont pas une preuve ; vous pouvez avoir le bon nombre d’enregistrements et les mauvaises données.
Les totaux. Là où les chiffres comptent, comparez des totaux de contrôle : montant des factures, valeur des commandes, solde ouvert, quantité. Les deux systèmes ont 100 000 factures, mais l’ancien totalise 412 800 000 $ et Salesforce 398 100 000 $. Stop. Les totaux révèlent ce que les décomptes manquent.
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. ⟲
Les rapports agrégés. Comparez la forme : comptes par État, commandes par année, requêtes client par statut, clients par segment, chiffre d’affaires par mois. Si la source dit 82 000 clients en Arizona et Salesforce 8 200, nous avons un indice : un code d’État qui n’a pas été mappé, une année exclue, un statut mal traduit, un fichier sauté. Le nombre de lignes peut avoir l’air juste alors que la distribution raconte l’histoire.
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. ⟲
Deux règles les accompagnent. D’abord, fixez les chiffres attendus avant le chargement (module 1) : décompte source, exclusions approuvées, doublons consolidés, enregistrements en quarantaine, cible attendue. Puis comparez et expliquez l’écart. Un chiffre attendu inventé après avoir vu le résultat, ce n’est pas du rapprochement ; c’est de la rationalisation. Ensuite, zéro erreur peut quand même être faux. Mappez Billing State vers Shipping State et chaque ligne se charge sans aucune erreur d’API : exécution technique parfaite, architecture fausse. C’est pour cela que le rapprochement métier compte, pas seulement les journaux techniques.
Les responsables métier valident aussi
Section intitulée « Les responsables métier valident aussi »L’équipe technique peut prouver les décomptes, les clés, les relations et le succès du chargement. Les utilisateurs métier reconnaissent ce que nous ne verrons pas : « ce ne sont pas nos clients actifs », « ce statut n’est plus utilisé depuis 2022 », « ces comptes sont rattachés à la mauvaise région », « ce client devrait avoir trois contrats actifs ». La validation métier est donc une étape explicite de la mise en production, avec des personnes nommées, des rapports nommés, des enregistrements nommés et une approbation nommée, pas « jetez un œil quand vous aurez le temps ».
Authority Moves on Day 0
Section intitulée « 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. ⟲
Retour à la normale, puis hypercare
Section intitulée « Retour à la normale, puis hypercare »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. ⟲
Puis nous sommes en production, mais pas terminés. Pendant une période de stabilisation (appelez-la hypercare), surveillez les erreurs de migration, les échecs d’intégration, l’automatisation inattendue, les nouveaux doublons, les relations manquantes, les problèmes de performance, les problèmes de données signalés par les utilisateurs et les dérives du rapprochement. Le risque de migration ne disparaît pas au moment où les utilisateurs se connectent.
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. ⟲
Et gardez les preuves : l’extraction finale, la version de la transformation, les fichiers de chargement, les résultats des traitements, les fichiers d’erreurs, les rapports de rapprochement, les approbations, le runbook avec les temps réels, la décision de go/no-go et les exceptions. Trois semaines plus tard, quelqu’un demandera si un enregistrement était faux avant la migration ou à cause d’elle. Vous devez pouvoir répondre. Faire confiance, mais vérifier ne s’arrête pas quand le chargement est terminé.
L’IA peut aider à surveiller la bascule. Le go/no-go ne lui appartient pas.
Section intitulée « L’IA peut aider à surveiller la bascule. Le go/no-go ne lui appartient pas. »L’IA est utile sous la pression d’une bascule : résumer les échecs, classer les erreurs, comparer des rapports, repérer des anomalies, suivre le runbook, faire ressortir les écarts par rapport à la répétition. Mais le go/no-go combine des preuves techniques, l’impact métier, le temps restant, la position par rapport au retour arrière et la tolérance au risque. L’IA peut faire ressortir les preuves. Ce sont les personnes responsables qui prennent la décision.
Au-delà de l’examen : ce que l’IA change. L’IA peut accélérer la surveillance de la bascule et le rapprochement, en particulier en trouvant des schémas dans de gros volumes d’erreurs et de données de validation. Gardez une responsabilité humaine explicite sur le go/no-go, le retour arrière et l’acceptation d’un risque de migration non résolu.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- 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. ⟲
- Comment l’accès des utilisateurs est bloqué puis rouvert, avec une porte de service et des utilisateurs de test de fumée, et comment l’automatisation, les intégrations et les agents sont maîtrisés pendant ce temps.
- Les critères de go/no-go, la procédure de retour arrière et le point au-delà duquel le retour arrière cesse d’être la reprise sûre, ainsi que les données et les flux inconnus qu’il faut trouver d’abord.
- Comment la migration est prouvée par des décomptes, des totaux, des vérifications par sondage et des rapports agrégés, par rapport à des valeurs attendues fixées avant le chargement.
- Quelle validation métier, quelles preuves et quelle stabilisation après la mise en production sont exigées avant que la migration soit terminée.
La bascule, c’est une preuve
Section intitulée « La bascule, c’est une preuve »Les scripts ont tourné : pas assez. L’API a renvoyé un succès : pas assez. Les nombres de lignes concordaient : toujours pas assez. Je veux des décomptes, des totaux, des vérifications par sondage et des rapports agrégés, une validation métier, le système revenu à la normale, savoir si nous sommes encore dans la fenêtre de retour arrière, et la preuve de ce qui s’est exactement passé. La bascule en production doit être ennuyeuse, parce que nous avons fait le gros du travail de réflexion avant le vendredi soir. Faire confiance, mais vérifier. Ensuite, laissez revenir les utilisateurs.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Others who cut over the same way: Salesforce Help, B2C Commerce Realm Split FAQ (s'ouvre dans un nouvel onglet); Microsoft Learn, Data migration planning for go-live (s'ouvre dans un nouvel onglet); AWS, Components of AWS DMS (s'ouvre dans un nouvel onglet); all checked 2026-11-01. ⟲
- Salesforce Help: Freeze or Unfreeze User Accounts (s'ouvre dans un nouvel onglet) and Custom Login Flows (s'ouvre dans un nouvel onglet) (login flows are assigned by profile), checked 2026-11-01. ⟲
- Dans ce cours : Données maîtres et identité et Intégration et mouvement des données.