Migration Assistant agent vaults को cold start चाहिए
Migration Assistant agent vaults के लिए security cutover ज़रूरी है: transferred data, fresh approvals, audit integrity और credential bindings को पहले test करें।
जब autonomous agents APIs और SSH hosts तक पहुँच सकते हों, तब Mac transfer महज़ एक harmless relocation नहीं होता। इससे नई machine, नई hardware security boundary, नए running processes और वह नया क्षण बनता है जब किसी को तय करना होता है कि किस authority पर अब भी भरोसा किया जा सकता है। अगर desktop परिचित दिखने के कारण agents को फिर external access मिल जाता है, तो migration ने सबसे महत्वपूर्ण हिस्सा छोड़ दिया है।
Migration Assistant दूसरे Mac, PC या backup से documents, apps, user accounts और settings transfer कर सकता है। इससे दोबारा काम शुरू करना आसान होता है। इसका मतलब यह नहीं कि source machine की हर security property भी बची रहनी चाहिए। Apple साफ़ तौर पर बताता है कि Secure Enclave keys और ThisDeviceOnly के रूप में चिह्नित keychain items दूसरे device पर migrate नहीं होते।
सुरक्षित operating rule सीधा है: जाँच और rebuild में मदद करने वाली चीज़ें transfer करें, फिर किसी agent को credential इस्तेमाल करने या remote session खोलने से पहले fresh proof माँगें। Transfer के बाद vault का न खुलना संभव है कि वही काम कर रहा हो जिसके लिए आपने उसे बनाया था।
Transferred Mac एक नया endpoint है
नए Mac पर वही user name, वही home-directory path, वही applications और वही project checkout हो सकते हैं। इनमें से कोई भी बात उसे वही security endpoint नहीं बनाती। Processor, Secure Enclave, biometric enrollment, disk-encryption context, installed system state, network attachment और local process history सभी बदल चुके हैं।
Teams अक्सर गलत तुलना करते हैं। वे पूछते हैं कि destination machine पर वही files हैं या नहीं। सवाल यह होना चाहिए कि destination बिना ऐसी authority copy किए, जिसे local रहना था, क्या उसी authority का possession साबित कर सकती है। Device-bound protection इस्तेमाल करने वाले vault में ये दोनों लक्ष्य एक-दूसरे के विपरीत हैं।
Apple की Security documentation यह सीमा स्पष्ट करती है। Secure Enclave private key enclave के भीतर बनती है, पहले से मौजूद private key import नहीं कर सकती और केवल उसी enclave द्वारा इस्तेमाल की जा सकती है जिसने उसे बनाया है। Apple यह भी कहता है कि kSecAttrAccessibleWhenUnlockedThisDeviceOnly इस्तेमाल करने वाला keychain item नए device पर migrate नहीं होता।
जल्दी में laptop बदलते समय यह व्यवहार असुविधाजनक लग सकता है। लेकिन इससे copied application container, backup या migration transfer external access के लिए portable bearer token नहीं बन पाता। Failure को bypass करने के लिए secrets को notes file, environment variable, shell history या generic password-manager entry में export न करें। इससे जानबूझकर बनाई गई hardware boundary की जगह ऐसी file आ जाएगी जो पुराने laptop से कहीं अधिक दूर तक फैल सकती है।
Migration Assistant शुरू करने से पहले cutover की अपेक्षाएँ तय कर लें:
- Tests पास होने तक पुराना Mac मौजूदा access का authoritative source रहेगा।
- नया Mac agent execution को blocked रखेगा या production credentials से disconnected रहेगा।
- Transferred file जाँचने के लिए evidence है, action की permission नहीं।
- हर approval और हर credential binding के लिए expected outcome पहले से स्पष्ट होगा।
यह controlled re-enrollment है, भले ही अधिकांश app data सफलतापूर्वक copy हो जाए। इसे transfer कहने से security work नहीं बदलता।
चार तरह की state अलग-अलग तरीकों से fail होती है
Application data, approvals, audit records और credential bindings अक्सर पास-पास store होते हैं। फिर भी इन्हें एक ही चीज़ न मानें। हर एक अलग सवाल का जवाब देता है और migration में हर एक का परिणाम अलग हो सकता है।
Application data सामान्य local state है: preferences, endpoint definitions, labels, non-secret metadata और संभवतः encrypted vault blobs। यह पूरी तरह transfer हो सकता है। इसकी मौजूदगी केवल यह बताती है कि copy operation ने उसे ढूँढ लिया।
Approvals किसी particular agent process के बारे में time-bound decisions हैं। वे पूछते हैं: «क्या यह process इस run के दौरान काम कर सकता है?» Transfer के बाद local database में दिखने वाला approval नए Mac के process को authorize नहीं करना चाहिए। Process की parent chain, executable location, environment और संभवतः signing state नई है।
Audit records इस बात का evidence हैं कि क्या हुआ। अगर transfer संबंधित encrypted files को सुरक्षित रखता है, तो वे survive कर सकते हैं और करने चाहिए। केवल journal view में readable रहना पर्याप्त नहीं, उनकी ordering और integrity properties भी बनी रहनी चाहिए।
Credential bindings यह बताती हैं कि destination hardware किसी secret के आसपास मौजूद cryptographic protection का इस्तेमाल कर सकता है या नहीं। Encrypted blob copy हो सकता है, जबकि उसे local रूप से unwrap करने की क्षमता न आए। यही वह अंतर है जो सावधानी से काम करने वाले engineers को भी भ्रमित करता है: ciphertext उपलब्ध होना credential उपलब्ध होने के बराबर नहीं है।
Transfer से पहले इन चार states को migration worksheet में लिखें। «Vault migrated» जैसी अस्पष्ट स्थिति दर्ज न करें। हर state का अलग परिणाम लिखें:
| State | Success कैसा दिखता है | Failure कैसा दिखता है | Cutover decision |
|---|---|---|---|
| App data | अपेक्षित settings और non-secret metadata मौजूद हैं | Configuration गायब है या अनपेक्षित रूप से बदल गई है | Access test से पहले settings restore या rebuild करें |
| Approvals | नया agent process फिर से पूछता है | पुराने record के कारण वह काम कर सकता है | किसी external call से पहले रोककर जाँच करें |
| Audit records | Historical entries मौजूद हैं और integrity verification सफल है | Entries गायब हैं, क्रम बदला है या verification fail होती है | दोनों copies सुरक्षित रखें और source न मिटाएँ |
| Credential bindings | Destination अपना local unlock माँगता है और फिर design के अनुसार काम करता है | Intended local gate के बिना secrets चुपचाप usable हो जाते हैं | समझ आने तक इसे security defect मानें |
सबसे असहज स्थिति partial success है। App launch होता है, settings दिखती हैं, पुरानी audit history मौजूद है और vault unlock नहीं होता। यह failed migration नहीं है। इस migration ने evidence और configuration बचाए हैं, लेकिन device-bound authority transfer करने से इनकार किया है। इस परिणाम को स्वीकार करें और credentials को फिर से enroll करें।
Copy करने से पहले agent access freeze करें
Migration Assistant से शुरुआत न करें। पहले यह सुनिश्चित करें कि जब तक आपको यह स्पष्ट न हो कि authority किस Mac के पास है, कोई agent request जारी न कर सके।
सबसे पहले source Mac पर active agent runs रोकें। अगर agent terminal multiplexer, editor extension, background task या CI-जैसे local launcher से managed है, तो हर entry point रोकें। उन्हें शुरू करने वाले terminal sessions बंद करें। Window बंद होना इस बात का प्रमाण नहीं कि child process exit हो चुका है।
दूसरे, source state को app के बाहर record करें। Date और time, source Mac का serial या internal asset identity, user account, active agent processes और उन remote systems के नाम लिखें जिनसे agents संपर्क कर सकते थे। इस record में secrets न डालें। आपको ऐसी timeline चाहिए जो बाद के evidence को समझाए, duplicate vault नहीं।
तीसरे, पहले controlled test तक destination को महत्वपूर्ण networks से disconnected रखें। Initial setup sequence से production VPN profile हटाना, firewall rule deny करना या local checks पूरे होने तक नए Mac को network से दूर रखना इसके तरीके हो सकते हैं। External API तक पहुँच न रखने वाला laptop गलती से यह साबित नहीं कर सकता कि पुराना authorization स्वीकार हो गया।
चौथे, तय करें कि fresh approvals स्वीकार करने का अधिकार किसके पास होगा। Teams अक्सर इसकी अहमियत कम आँकती हैं। Migration के दौरान कोई दूसरा व्यक्ति नई machine set up कर सकता है, backups restore कर सकता है या damaged laptop ठीक कर सकता है। Approval card पर click करने वाले व्यक्ति को पता होना चाहिए कि वह किस agent binary को approve कर रहा है और उसे वह capability क्यों चाहिए।
ऐसा छोटा handoff record इस्तेमाल करें:
Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator
दिखाई गई date केवल example format है, कोई magic identifier नहीं। महत्वपूर्ण यह है कि बाद में source audit tail, destination के first approval और first successful action को एक ही cutover record से जोड़ा जा सके।
App files move हो सकती हैं, trust नहीं
Application state को दो चरणों में inspect करें: पहले completeness, फिर authority। दोनों को न मिलाएँ। Completeness बताती है कि क्या restore करना है। Authority बताती है कि क्या reject या rebuild करना है।
Transfer के बाद application तब launch करें जब destination production services तक पहुँच न बना सके। इसकी visible configuration जाँचें: endpoint names, labels, non-secret routing details और expected local journal view। इनकी तुलना source Mac से करें, जब तक source मौजूद है। Endpoint missing हो तो उसे सोच-समझकर rebuild करें। कोई ऐसा endpoint दिखे जिसे कोई पहचानता नहीं, तो उसे हटाएँ और पता लगाएँ कि वह कहाँ से आया।
फिर ऐसी state खोजें जो automatic action करा सकती है। उदाहरण के लिए auto-started agent integrations, connector शुरू करने वाली shell profile entries, editor tasks, launch agents, saved command templates और ऐसी application preferences जो पुराने sessions फिर खोल दें। Migration convenience settings को बचा सकती है जो text editor के लिए harmless हैं, लेकिन production APIs call करने वाले agent के लिए खतरनाक।
Apple के अनुसार Migration Assistant apps, accounts, documents और settings transfer करता है। यही व्यापक category इस review की वजह है, न कि यह मान लेना कि केवल personal files move हुई हैं।
Directory मौजूद होने को pass condition न मानें। Security design जानबूझकर encrypted vault file transfer कर सकती है, लेकिन उसे खोलने वाली सामग्री पीछे छोड़ सकती है। App local security state copy न करने का निर्णय ले, तो खाली दिखने वाला vault भी सही हो सकता है। उपयोगी सवाल केवल यह है कि परिणाम आपके अपेक्षित design से मेल खाता है या नहीं।
Sallyport में vault app के भीतर encrypted होता है और vault gate absolute होता है। Supported hardware path वाले Macs पर gate Secure Enclave और Touch ID इस्तेमाल करता है, और locked का मतलब है कि हर action deny होगा। इसलिए copied vault payload इस बात का evidence नहीं है कि destination source Mac की authority इस्तेमाल कर सकता है।
हर observed result को exact language में document करें। «Encrypted state present; destination gate remains locked» लिखें, «migration failed» नहीं। «Agent launcher disabled before first run» लिखें, «probably stopped» नहीं। ये विवरण बाद के operator को unfinished test को successful cutover समझने से रोकते हैं।
पुराने approvals को नए process को authorize नहीं करना चाहिए
Session approval और credential access अलग controls हैं। नए Mac को दोनों tests सही क्रम में पास करने होंगे। Vault gate तय करता है कि कोई action संभव है या नहीं। Session authorization तय करता है कि यह particular agent run calls कर सकता है या नहीं। Per-call requirement तय करती है कि किसी credential के हर इस्तेमाल पर human decision चाहिए या नहीं।
इन controls को मिलाना आसान है, क्योंकि user को केवल इतना दिखता है कि कोई action सफल हुआ या विफल। Migration के दौरान इस अस्पष्टता को स्वीकार न करें। इसे जानबूझकर test करें।
Destination vault को intended locked या unlocked state में रखने के बाद ही नया agent process शुरू करें। उससे ऐसी harmless action माँगें जिसमें production systems को बदल न सकने वाली credential इस्तेमाल हो। Expected session result fresh approval request है। Approval interface में दिख रही process identity और code-signing authority जाँचें, फिर केवल उसी run को approve करें जिसे आपने वास्तव में शुरू किया है।
अगर destination पर agent process बिना नए authorization event के action कर देता है, तो रुकें। यह सोचकर खुश न हों कि transfer ने समय बचा लिया। Authority देने वाला रास्ता खोजें। हो सकता है कोई पुराना process बचा हो, restored session database हो, कोई integration अपेक्षित shim के बाहर launch हो रही हो या approval model process lifetime से पर्याप्त रूप से बँधा न हो।
Sallyport में session authorization default रूप से on होती है और नए agent process की पहली call को approval card के रूप में दिखाती है। Card की शुरुआत process की code-signing authority से होती है। एक approval केवल उस run तक रहती है, उसके exit होने तक। इसलिए नए destination process से fresh decision माँगना सही है।
Per-call credentials को अलग से test करें। एक harmless test credential को हर use पर approval माँगने के लिए mark करें। उसी approved agent run से दो calls करें। उस credential के हर इस्तेमाल पर decision दिखना चाहिए, जबकि process चलते रहने के कारण session decision दोबारा नहीं आना चाहिए। इससे पता चलता है कि आपने session layer test की है या per-call layer, केवल एक popup देखकर अनुमान नहीं लगाना पड़ता।
एक उपयोगी test table छोटी होती है:
| Test | Expected observation | Stop condition |
|---|---|---|
| New agent run की पहली call | Fresh session approval दिखाई दे | पुराने approval के तहत call आगे बढ़े |
| उसी run की दूसरी call | दूसरा session approval न आए | Policy reason के बिना दूसरा session prompt आए |
| Approval-per-use credential का पहला इस्तेमाल | Credential-specific decision दिखाई दे | Credential चुपचाप इस्तेमाल हो |
| उसी credential का दूसरा इस्तेमाल | दूसरा credential-specific decision दिखाई दे | पहला decision लागू रहे |
| Agent exit और restart | Fresh session approval फिर दिखाई दे | पिछले run के पास अब भी authority हो |
इसे production deploy से test न करें, क्योंकि आप केवल popup test नहीं कर रहे। आप यह जाँच रहे हैं कि नया endpoint process lifetime और credential policy को सही ढंग से पहचानता है या नहीं।
Audit history को visual spot check नहीं, verification चाहिए
कल की entries वाला journal view उपयोगी है, लेकिन इससे transferred record के पूरा रहने का प्रमाण नहीं मिलता। Migration में कोई file छूट सकती है, पुराना snapshot copy हो सकता है, update बीच में रुक सकता है या आप cached index देख रहे हो सकते हैं। Audit evidence को integrity test चाहिए।
पहली destination action से पहले source Mac को सुरक्षित रखें। अंतिम source timestamp capture करें और cutover के आसपास अपेक्षित sessions और calls की संख्या लिखें। फिर destination की historical view से तुलना करें। आपको continuity देखनी है, screen placement या display order का बिल्कुल समान होना नहीं।
Sallyport अपने Sessions और Activity journals को एक write-blind, encrypted, hash-chained audit log से project करता है। इसका verifier ciphertext पर vault key के बिना offline chain check कर सकता है। इससे migration testing में concrete pass या fail point मिलता है, operator को पुरानी actions की सूची देखकर अनुमान नहीं लगाना पड़ता।
संभव हो तो move से पहले source पर verifier चलाएँ, फिर किसी agent action की अनुमति देने से पहले destination पर दोबारा चलाएँ। Standard output और exit code capture करें, किसी खास message format पर निर्भर न रहें:
sp audit verify > audit-verify.txt 2>&1
status=$?
printf 'sp audit verify exit=%s\n' "$status"
audit-verify.txt को migration record के साथ रखें, ऐसे chat thread में नहीं जो बाद में गायब हो जाए। Zero exit code तभी उपयोगी है जब आप यह भी लिखें कि वह किस endpoint से और कब मिला। Verifier error बताए या nonzero status लौटाए तो migration path रोक दें। Source को intact रखें, diagnostic output copy करें और transfer की जाँच करें। ऐसी fresh journal शुरू न करें जो discontinuity छिपा दे।
एक और अंतर याद रखें: transferred audit history बताती है कि पुराने endpoint ने क्या record किया; destination activity बताती है कि cutover के बाद नया endpoint क्या करता है। इन्हें मन में न मिलाएँ। First destination call आसानी से मिलनी चाहिए, fresh session authorization से जुड़ी होनी चाहिए और last source call के स्पष्ट रूप से बाद की होनी चाहिए।
Credentials निकालने के बजाय उन्हें फिर enroll करें
लोकप्रिय shortcut है कि पुराने Mac से API token या SSH private key export करें, उसे नए Mac में paste करें और बाद में साफ़ करने का वादा करें। यह इसलिए popular है क्योंकि जल्दी काम करता है। लेकिन जब पुराने design ने credential को agent से दूर रखा हो और local use को protected vault से बाँधा हो, तब यह गलत है।
Re-enrollment सवाल को «मैं यह secret copy कैसे करूँ?» से बदलकर «इस endpoint को नई authority कौन जारी करे?» कर देता है। यही बेहतर सवाल है। इसके लिए नया API token बनाना, नई SSH public key register करना या system owner से नई credential लेना पड़ सकता है। इससे पुराने Mac के लिए clean revocation point भी बनता है।
HTTP access के लिए जहाँ remote service अनुमति दे, disposable, read-only test credential बनाएँ। उसे किसी एक harmless resource तक सीमित रखें। Newly approved agent से वह resource माँगें। Returned result और local audit entry की समीक्षा करें। फिर service की सामान्य प्रक्रिया के अनुसार test credential revoke करें या उसे expire होने दें।
SSH के लिए dedicated test account या restricted test host इस्तेमाल करें। पहला command केवल observation वाला हो, जैसे remote account identity और current working directory print करना। Success का पहला proof repository push, package publish, database command या deployment trigger न बनाएँ। इन actions से debugging कठिन होती है, क्योंकि आप उसी system को बदल देते हैं जिसे सुरक्षित करने की कोशिश कर रहे हैं।
Per-call approval माँगने वाली credential इस चरण में विशेष रूप से उपयोगी है। इससे human देख सकता है कि external use ठीक कब शुरू हुआ। Destination authorization, audit और harmless action tests पास कर ले, तब production credentials को उनके सामान्य ownership path से re-enroll करें। Remote system यह distinction support करते ही old credential revoke करें या उसके पुराने endpoint authorization को हटाएँ।
SSH key file को उस SSH identity के साथ न मिलाएँ जो नए Mac पर होनी चाहिए। Copied private key authenticate कर सकती है, लेकिन इससे केवल यह साबित होता है कि server ने वही cryptographic material स्वीकार किया। इससे यह पता नहीं चलता कि transfer ने आपका local security model बचाया या नहीं। नया endpoint, नई identity registration, नया audit trail।
पहला live action जानबूझकर उबाऊ होना चाहिए
पहला production-adjacent action ऐसा हो जो बिना cleanup work पैदा किए बता दे कि पूरी chain काम कर रही है। Read-only operation चुनें, जिसे inert test object तक सीमित किया जा सके और remote logs तथा local activity journal दोनों में आसानी से खोजा जा सके।
अच्छे विकल्प हैं test API object का metadata पढ़ना, dedicated empty SSH directory list करना या service की current authenticated identity पूछना। खराब विकल्प हैं cloud resources बनाना, shared credentials rotate करना, artifacts publish करना, repository settings बदलना और real paths पर shell expansion वाले commands चलाना।
Action एक बार चलाएँ। जिन घटनाओं का क्रम हुआ, उसे इस तरह confirm करें:
- Request से पहले destination vault intended state में था।
- नए agent process को fresh session authorization मिला।
- Per-call credential की setting ऐसी थी तो उसने approval माँगा।
- Remote system ने expected harmless action record की।
- Destination activity record उस action से मेल खाता है जिसे आपने authorize किया।
कोई observation missing हो तो कारण समझे बिना action दोबारा न चलाएँ। Opaque test दोहराने से लगभग समान records का ढेर बनता है, explanation नहीं। एक साफ़ success पाँच जल्दबाज़ retries से अधिक जानकारी देती है।
यह action पास हो जाए तो external access को एक समय में एक credential के लिए enable करें। एक दोपहर में हर saved endpoint enable न करें, केवल इसलिए कि destination machine अब usable लग रही है। Production token, infrastructure SSH identity और personal service token का risk समान नहीं होता और इनके approvers भी अलग हो सकते हैं। सबसे कम authority वाले से शुरुआत करें।
Evidence पूरा होने तक पुराना Mac रखें
Destination सफलतापूर्वक launch हो जाए तो source Mac erase या trade-in न करें। Agents disabled रखकर उसे तब तक उपलब्ध रखें जब तक transfer record पूरा न हो और आप दोनों तरफ के evidence को समझा न सकें।
Closure record में source की last verified audit state, destination की first verified audit state, fresh approval tests का परिणाम, re-enroll की गई credentials, revoke की गई credentials और production access authorize करने वाले व्यक्ति का नाम होना चाहिए। यह केवल paperwork नहीं है। इसी से बाद में पता चलेगा कि कोई action पुराने machine से आया, नए machine से या किसी अनियोजित overlap से।
इसके बाद active source sessions revoke करें। जहाँ remote access allowlists हों, वहाँ source को हटाएँ। Replacement काम करने लगे तो source-specific tokens और SSH registrations revoke करें। अंत में verify करें कि पुराना endpoint online होने पर केवल वापस आ जाने से access हासिल न कर सके।
सबसे महत्वपूर्ण test यह नहीं कि Migration Assistant ने कितना transfer किया। यह है कि destination को external authority फिर से अर्जित करनी पड़ी या नहीं। अगर उत्तर हाँ है, तो नया Mac एक defensible boundary के साथ शुरू होता है। अगर उत्तर नहीं है, तो agents को disconnected रखें जब तक आप ठीक-ठीक न बता सकें कि transfer में क्या पार हुआ और क्यों।
सामान्य प्रश्न
क्या Mac migration के दौरान AI agents को disable कर देना चाहिए?
Transferred installation को नया endpoint मानें, भले ही app, account name और files बिल्कुल एक जैसे दिखें। Vault unlock behavior, fresh session approval, audit-chain verification और किसी harmless external action की जाँच करने तक agent access बहाल न करें।
क्या local agent vault नए Mac पर transfer होगा?
कुछ application files transfer हो सकती हैं, लेकिन local vault ऐसे hardware-bound material पर निर्भर हो सकता है जो files के साथ move नहीं होता। Apple के अनुसार Secure Enclave keys और ThisDeviceOnly के रूप में चिह्नित keychain items दूसरे device पर migrate नहीं होते।
क्या agent approvals Migration Assistant के बाद भी रहते हैं?
नहीं। Copied approval record केवल यह दिखाता है कि कोई file move हुई है। इससे यह साबित नहीं होता कि नई machine को पुराने agent process पर भरोसा करना चाहिए। Transfer के बाद नए process को launch करके नया approval ज़रूर लें।
Mac transfer के बाद agent audit logs के साथ क्या होना चाहिए?
पुराने journal को historical evidence के रूप में रखें और उस पर भरोसा करने से पहले उसे verify करें। फिर नए Mac पर नई activity को अलग endpoint history के रूप में record करें और cutover time को app के बाहर document करें।
कैसे जाँचूँ कि migrated vault सुरक्षित है?
Vault को इस आधार पर न आँकें कि कोई directory मौजूद है या app खुलता है। देखें कि नई machine के local gate को पूरा किए बिना vault locked रहता है या नहीं, और उसके बाद approved actions अपेक्षित ढंग से काम करते हैं या नहीं।
Migrated agent को फिर से approval की आवश्यकता क्यों होनी चाहिए?
Mac transfer को पुराने approval को चुपचाप current authority में बदलने की अनुमति नहीं देनी चाहिए। नए process से visible authorization request आनी चाहिए, और approver को उसे स्वीकार करने से पहले signing authority देखनी चाहिए।
Migration के बाद पहला सुरक्षित external action क्या होना चाहिए?
ऐसी credential इस्तेमाल करें जो किसी harmless test resource को read कर सके या disposable endpoint को call कर सके। शुरुआत production deployment, deletion, billing या shared host को बदल सकने वाले SSH command से न करें।
अगर migrated audit chain verify न हो तो क्या करूँ?
Audit verifier failure बताए तो cutover रोक दें और transferred files को जाँच के लिए बिना बदले सुरक्षित रखें। Source Mac के records delete न करें और ऐसा replacement history न बनाएँ जो gap छिपा दे।
क्या Migration Assistant का सफल run credentials के सुरक्षित होने का प्रमाण है?
नहीं। Migration Assistant documents, apps, accounts और settings copy करने के लिए बनाया गया है, लेकिन security bindings जानबूझकर device-specific हो सकती हैं। Successful transfer installation का परिणाम है, security state के carry forward होने का प्रमाण नहीं।
Agent migration के बाद पुराने Mac को कब revoke कर सकता हूँ?
नई machine के cutover checks पास करने तक source Mac के agents को offline रखें, फिर उसके active sessions revoke करें। Records की तुलना करने और transfer से समस्या सामने आने पर evidence recover करने के लिए उसे पर्याप्त समय तक सुरक्षित रखें।