ตัวอย่างสถานการณ์:ลองจินตนาการถึงบริษัทออกแบบสมมติชื่อ Cedar Studio ซึ่งมีพนักงาน 32 คน ใช้ ownCloud Classic 10 ที่มีไดเร็กทอรี LDAP พื้นที่จัดเก็บไฟล์ส่วนบุคคล การแชร์กลุ่ม ลิงก์สาธารณะ และการเชื่อมต่อพื้นที่จัดเก็บโปรเจกต์ภายนอก บริษัทต้องการย้ายไปใช้ ownCloud Infinite Scale (oCIS) โดยไม่ได้คาดหวังว่าการติดตั้งเซิร์ฟเวอร์ใหม่จะสามารถถ่ายโอนข้อมูลหรือสิทธิ์การเข้าถึงเดิมได้ ตัวอย่างนี้เป็นเพียงสมมติฐาน ไม่ใช่รายงานเกี่ยวกับการย้ายระบบที่เสร็จสมบูรณ์แล้ว
เส้นทางที่ ownCloud สนับสนุนและระบุไว้ในเอกสารคือการย้ายข้อมูลแบบมีคำแนะนำโดยใช้migrate-to-ocisแอปบนเซิร์ฟเวอร์ Classic และoccคำสั่งต่างๆ เป็นการถ่ายโอนแบบเป็นขั้นตอนไปยังเป้าหมาย oCIS ที่สะอาดและแยกต่างหาก ไม่ใช่การอัปเกรดฐานข้อมูล Classic หรือไดเร็กทอรีข้อมูลแบบในตัว คู่มือการย้ายข้อมูลระบุว่าแหล่งข้อมูลยังคงใช้งานได้ตลอดกระบวนการส่วนใหญ่ แต่ไม่ได้อธิบายถึงการซิงโครไนซ์อย่างต่อเนื่องหรือการถ่ายโอนข้อมูลส่วนต่างขั้นสุดท้ายโดยไม่มีการหยุดทำงาน วางแผนการเปลี่ยนผ่านอย่างเป็นระบบและยืนยันความเข้ากันได้ของเวอร์ชันแหล่งข้อมูลและขั้นตอนการหยุดเขียนขั้นสุดท้ายกับฝ่ายสนับสนุนของ ownCloud ก่อนใช้งานจริง
ขั้นตอนด้านล่างนี้เป็นไปตามคู่มือการย้ายข้อมูล ownCloud Server 11.0 อย่างเป็นทางการ และเอกสารการตรวจสอบสิทธิ์และการสำรองข้อมูล Infinite Scale 8.2 ที่เผยแพร่เมื่อวันที่ 6 ตุลาคม 2026 ไวยากรณ์คำสั่ง ตัวแปรสภาพแวดล้อม และข้อตกลงการสนับสนุนอาจมีการเปลี่ยนแปลง โปรดตรวจสอบกับเอกสารสำหรับเวอร์ชันที่คุณติดตั้งไว้
ขั้นตอนที่ 1: ตรวจสอบข้อมูลในระบบเวอร์ชันคลาสสิกและกำหนดความหมายของคำว่า "ย้ายข้อมูลแล้ว"
สำหรับ Cedar Studio งานแรกคือการจัดทำรายการผู้ใช้ กลุ่ม บัญชีที่เปิดใช้งานและปิดใช้งาน โฟลเดอร์ที่แชร์ ลิงก์ที่แชร์ การเชื่อมต่อภายนอก และผู้ใช้ภายในเครื่องที่ไม่ปรากฏใน LDAP บันทึกว่าทีมใดบ้างที่ขึ้นอยู่กับแต่ละรายการ เพื่อหลีกเลี่ยงการเข้าใจผิดว่าการถ่ายโอนไฟล์ส่วนบุคคลสำเร็จแล้วเป็นหลักฐานว่าเวิร์กโฟลว์เก่าทั้งหมดได้ถูกย้ายไปแล้ว
ตามคู่มือการย้ายข้อมูล การย้ายข้อมูลนี้สามารถถ่ายโอนผู้ใช้และกลุ่มที่เปิดใช้งานพร้อมสมาชิกภาพ ไฟล์ในไดเร็กทอรีโฮมของผู้ใช้แต่ละราย และการแชร์ของผู้ใช้ กลุ่ม และลิงก์ ไฟล์จะถูกจัดเก็บไว้ในพื้นที่ส่วนตัวของผู้ใช้แต่ละรายใน oCIS ผู้ใช้ที่ถูกปิดใช้งานและไฟล์ของพวกเขาจะถูกข้ามไป กระบวนการนี้จะไม่ย้ายรหัสผ่านหรือการเมานต์ภายนอก ข้อมูลที่อยู่ในไดรฟ์ภายนอกและการแชร์ที่ได้รับจะถูกยกเว้นจากการถ่ายโอนไฟล์ส่วนตัวและต้องจัดการแยกต่างหาก ตรวจสอบตำแหน่งเหล่านั้นและกำหนดเจ้าของสำหรับการย้ายข้อมูลด้วยตนเอง
| สินค้าคลาสสิก | พฤติกรรมการย้ายข้อมูลที่บันทึกไว้ | แผนสำหรับสตูดิโอซีดาร์ |
| ผู้ใช้และกลุ่มที่เปิดใช้งาน | โอนย้ายหรือแมปข้อมูล ขึ้นอยู่กับระบบยืนยันตัวตนเบื้องหลัง | ตรวจสอบว่าบัญชีและการเป็นสมาชิกทั้งหมดที่คาดหวังปรากฏอยู่ใน oCIS แล้ว |
| ไฟล์ในไดเร็กทอรีโฮมของผู้ใช้ | โอนย้ายไปยังพื้นที่ส่วนตัวของผู้ใช้แต่ละคน | เปรียบเทียบโฟลเดอร์และไฟล์ตัวอย่างหลังจากถ่ายโอนเสร็จแล้ว |
| การแชร์ผู้ใช้ กลุ่ม และลิงก์ | ข้อมูลการแชร์จะถูกย้าย โดยอาจมีการเปลี่ยนแปลงหากมีผู้ใช้ กลุ่ม หรือนโยบายรหัสผ่านการเชื่อมโยงไม่ครบถ้วน | ทดสอบการเข้าถึงอีกครั้งโดยใช้บัญชีเจ้าของและบัญชีผู้รับ |
| รหัสผ่านและบัญชีที่ถูกปิดใช้งาน | รหัสผ่านจะไม่ถูกส่งต่อ และผู้ใช้ที่ถูกปิดใช้งานจะถูกข้ามไป | เตรียมขั้นตอนการเปิดใช้งานบัญชี และตรวจสอบว่าบัญชีที่ถูกปิดใช้งานใดบ้างที่ควรเปิดใช้งานก่อนทำการย้ายข้อมูล |
| การติดตั้งภายนอกและข้อมูลการแบ่งปันที่ได้รับ | ข้อมูลการเชื่อมต่อภายนอกจะไม่รวมอยู่ในการถ่ายโอนไฟล์ | สร้างจุดเชื่อมต่อใหม่หรือคัดลอกข้อมูลต้นฉบับแยกต่างหาก จากนั้นทดสอบการเข้าถึง |
นอกจากนี้ ให้บันทึกว่ามีการใช้งานลิงก์สาธารณะที่ไม่ต้องใช้รหัสผ่านหรือไม่ โดยค่าเริ่มต้น oCIS กำหนดให้ต้องใช้รหัสผ่านสำหรับลิงก์สาธารณะ ลิงก์แบบคลาสสิกดังกล่าวอาจไม่สามารถย้ายได้เว้นแต่จะมีการเปลี่ยนแปลงนโยบายเป้าหมาย อย่าลดทอนนโยบายนั้นเพียงเพื่อรักษา URL เก่าไว้ ตัดสินใจว่าเจ้าของลิงก์ควรสร้างลิงก์ที่ป้องกันด้วยรหัสผ่านใหม่แทนหรือไม่ รหัสผ่านบนลิงก์ที่ป้องกันด้วยรหัสผ่านที่ย้ายมาจะไม่ตรงกับรหัสผ่านเดิม ดังนั้นผู้ใช้ควรตั้งรหัสผ่านใหม่หลังจากเปลี่ยนระบบเสร็จสิ้น
ขั้นตอนที่ 2: เตรียมฐานข้อมูล oCIS ที่สะอาดและการเชื่อมต่อสำหรับการย้ายข้อมูล
สร้างและทดสอบอินสแตนซ์ oCIS แยกต่างหากก่อนที่จะถ่ายโอนข้อมูลการผลิต คู่มือการย้ายข้อมูลกำหนดให้ทั้งสองระบบต้องทำงานและสามารถเข้าถึงกันได้ นอกจากนี้ยังเตือนว่าระบบปลายทางควรเป็นระบบใหม่และสะอาด: ผู้ใช้หรือข้อมูลที่มีอยู่เดิมอาจขัดแย้งกับเนื้อหาที่นำเข้า สำรองข้อมูลอินสแตนซ์ Classic ปัจจุบันและเตรียมแผนการย้อนกลับเพื่อให้ระบบยังคงใช้งานได้จนกว่าผู้ใช้จะยอมรับบริการใหม่
การย้ายข้อมูลนี้จำเป็นต้องใช้แอปที่ ownCloud จัดหาให้และติดตั้งบนเซิร์ฟเวอร์ Classic แอปนี้จะจัดให้เป็นส่วนหนึ่งของขั้นตอนการย้ายข้อมูลแบบมีคำแนะนำ เอกสารระบุให้ผู้ดูแลระบบติดต่อฝ่ายสนับสนุนของ ownCloud เพื่อขอรับแอปดังกล่าว แอปนี้มีไฟล์ไบนารี rclone ของตัวเอง ห้ามใช้แพ็กเกจจาก Marketplace ที่ไม่เกี่ยวข้องหรือโปรแกรมคัดลอกไฟล์อื่นมาแทนที่กระบวนการที่ระบุไว้ในเอกสารของแอปนี้
ในฝั่ง oCIS ให้เปิดใช้งานauth-appการตั้งค่าการตรวจสอบสิทธิ์บริการและแอปพลิเคชัน คู่มือการย้ายข้อมูลยังกำหนดให้ต้องเปิดใช้งานการปลอมแปลงตัวตนและสร้างโทเค็นแอปสำหรับผู้ดูแลระบบ oCIS เอกสาร auth-app ของ Infinite Scale 8.2 ระบุไว้อย่างชัดเจนว่าการปลอมแปลงตัวตนมีไว้สำหรับการย้ายข้อมูลเท่านั้น และไม่ควรเปิดใช้งานไว้ในการใช้งานจริง ให้ถือว่าเป็นการตั้งค่าการย้ายข้อมูลชั่วคราว: ปกป้องโทเค็น จำกัดผู้ที่สามารถเข้าถึงได้ และปิดการปลอมแปลงตัวตนเฉพาะการย้ายข้อมูลหลังจากเสร็จสิ้นการทำงาน ในการใช้งานแบบกระจาย ให้ใช้การตั้งค่ากับบริการที่ถูกต้องตามที่เอกสารระบุไว้
สำหรับ Cedar Studio ในสมมติฐานนั้น ควรทดสอบเป้าหมาย oCIS ด้วยบริการ LDAP เดียวกันกับที่เซิร์ฟเวอร์ Classic ใช้ เก็บข้อมูลรับรองไว้ในกลไกความลับของการปรับใช้ แทนที่จะคัดลอกรหัสผ่านการเชื่อมต่อลงในประวัติคำสั่งเชลล์หรือรันบุ๊กที่ใช้ร่วมกันคู่มือการย้ายข้อมูลอย่างเป็นทางการของ ownCloudระบุข้อกำหนดของเป้าหมายและชี้ให้เห็นถึงการสนับสนุนของ ownCloud สำหรับแอปการย้ายข้อมูลคู่มือแอปการตรวจสอบสิทธิ์ oCIS 8.2อธิบายเกี่ยวกับโทเค็นแอปและการปลอมแปลงตัวตน
ขั้นตอนที่ 3: ทำให้การจับคู่ข้อมูลประจำตัวมีความสอดคล้องกัน จากนั้นทำการตรวจสอบความพร้อมใช้งาน
oCIS ต้องสามารถระบุผู้ใช้และกลุ่มได้ก่อนที่จะย้ายไฟล์และโฟลเดอร์ที่แชร์ Cedar Studio ใช้ LDAP อยู่แล้ว ดังนั้นผู้ดูแลระบบจะต้องเชื่อมต่อ oCIS กับไดเร็กทอรีเดียวกัน ตรวจสอบว่าผู้ใช้สามารถล็อกอินได้ และตรวจสอบว่าตัวระบุตรงกับบัญชีที่ต้องการ คู่มือ ownCloud ระบุที่อยู่อีเมลที่ไม่ซ้ำกันและถูกต้องสำหรับผู้ใช้ Classic ทุกรายที่เปิดใช้งาน สำหรับผู้ใช้ Classic ที่ใช้ LDAP คู่มือยังระบุแอตทริบิวต์ชื่อผู้ใช้ ซึ่งโดยปกติจะเป็นuidหรือsamAccountNameและการตั้งค่าสคีมา LDAP ของ oCIS ที่เกี่ยวข้อง จับคู่แอตทริบิวต์กับไดเร็กทอรีจริง อย่าคัดลอกค่าตัวอย่างโดยไม่ตรวจสอบ
หาก Classic ใช้บัญชีผู้ใช้ภายในเครื่อง แต่ oCIS ใช้ไดเร็กทอรี LDAP ภายนอก ให้สร้างหรือย้ายผู้ใช้และกลุ่มที่ตรงกันไปยังไดเร็กทอรีนั้นก่อนการถ่ายโอนไฟล์ ชื่อผู้ใช้และกลุ่มต้องตรงกัน ระบบ IDM ภายในของ oCIS เป็นไดเร็กทอรีแบบฝังตัวที่มีข้อจำกัด เหมาะสำหรับระบบขนาดเล็กหรือการทดสอบ ownCloud แนะนำให้ใช้ LDAP หรือระบบจัดการข้อมูลประจำตัวภายนอกที่แท้จริงสำหรับการใช้งานจริง ขั้นตอนการย้ายข้อมูลอย่างเป็นทางการไม่รองรับการใช้งานผู้ใช้ Classic ที่ใช้ทั้งบัญชีภายในเครื่องและ LDAP ในสาขาการย้ายข้อมูลเดียวกัน ควรแก้ไขปัญหาด้านสถาปัตยกรรมนั้นโดยได้รับการสนับสนุนจากฝ่ายสนับสนุน แทนที่จะแก้ไขปัญหาเฉพาะหน้าในระหว่างดำเนินการ
เมื่อติดตั้งและเปิดใช้งานแอปการย้ายข้อมูลบน Classic แล้ว ให้ปรับเส้นทางและบัญชีบริการที่ระบุไว้ในเอกสารให้ตรงกับการติดตั้งของคุณ คู่มือนี้ใช้/var/www/owncloudและwww-dataเป็นตัวอย่าง:
sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify
คำสั่งตรวจสอบจะตรวจสอบว่าผู้ใช้ที่เปิดใช้งานมีที่อยู่อีเมลที่ถูกต้องและไม่ซ้ำกัน แก้ไขปัญหาที่รายงานก่อนดำเนินการต่อ แทนที่จะข้ามการตรวจสอบ หากผู้ใช้ที่ถูกปิดใช้งานจำเป็นต้องย้าย ให้ตรวจสอบบัญชี เปิดใช้งานใน Classic ก่อนการตรวจสอบ และรวมไว้ในแผนการย้ายข้อมูล Cedar Studio ควรตรวจสอบการลงชื่อเข้าใช้ LDAP ไปยัง oCIS กับผู้ใช้ตัวแทนหลายรายก่อนเริ่มการถ่ายโอนข้อมูลด้วย
ขั้นตอนที่ 4: ดำเนินการสร้างสาขาผู้ใช้และกลุ่มให้เสร็จสมบูรณ์ จากนั้นย้ายไฟล์และโฟลเดอร์ที่แชร์
ให้ทำตามขั้นตอนในคู่มืออย่างเป็นทางการที่ตรงกับการตั้งค่าข้อมูลประจำตัวของคุณ หากผู้ใช้แบบคลาสสิกเป็นผู้ใช้ภายในเครื่องและจะใช้ IDM ในตัวของ oCIS ลำดับขั้นตอนในคู่มือจะรวมถึงการย้ายผู้ใช้ การกำหนดบทบาทใน oCIS และการย้ายกลุ่ม โดยจะมีการกำหนดบทบาทหนึ่งบทบาทให้กับผู้ใช้ที่ย้ายมา บทบาทของแบบคลาสสิกจะไม่ถูกเก็บรักษาไว้แบบหนึ่งต่อหนึ่ง และสิทธิ์ผู้ดูแลระบบย่อยแบบคลาสสิกจะไม่มีบทบาทที่เทียบเท่าใน oCIS โปรดตรวจสอบสิทธิ์การเข้าถึงของผู้ดูแลระบบด้วยตนเอง หากทั้งสองระบบใช้ไดเร็กทอรี LDAP เดียวกัน โปรดตรวจสอบให้แน่ใจว่าผู้ใช้และกลุ่มพร้อมใช้งานสำหรับ oCIS แล้ว และทำตามขั้นตอนของ LDAP แทนการสร้างสำเนาซ้ำ
หลังจากผู้ใช้ กลุ่ม และบทบาทต่างๆ พร้อมแล้ว คำสั่งไฟล์และแชร์ที่ระบุไว้ในเอกสารจะใช้ชื่อผู้ใช้ผู้ดูแลระบบ oCIS เป็นอาร์กิวเมนต์สุดท้าย ส่วนรหัสผ่านผู้ดูแลระบบแบบคลาสสิกจะถูกขอแบบโต้ตอบ:
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin
ดำเนินการถ่ายโอนไฟล์ก่อนการถ่ายโอนไฟล์แชร์ ตามที่อธิบายไว้ในขั้นตอนการย้ายข้อมูล ผู้ใช้ที่ไม่เคยเข้าสู่ระบบและไม่มีไฟล์ หรือผู้ใช้ที่หายไปจาก oCIS จะถูกข้ามไปในขั้นตอนการถ่ายโอนไฟล์ ไฟล์แชร์ที่เกี่ยวข้องกับผู้ใช้หรือกลุ่มที่หายไปอาจถูกรายงานว่าเป็นข้อผิดพลาดในขณะที่การย้ายข้อมูลดำเนินต่อไป สำหรับ Cedar Studio นั่นหมายความว่าทีมต้องตรวจสอบผลลัพธ์ของคำสั่งและรายการไฟล์แชร์ การดำเนินการเสร็จสิ้นโดยไม่มีปัญหาขัดข้องร้ายแรงไม่ได้หมายความว่าไฟล์แชร์ทุกไฟล์ใช้งานได้
คู่มือการย้ายข้อมูลระบุว่า ขั้นตอนที่สำเร็จแล้วไม่สามารถทำซ้ำได้โดยไม่ลบข้อมูลเป้าหมายที่สร้างขึ้นก่อน--forceการรีเซ็ตการเริ่มต้นจะไม่ลบไฟล์ที่ย้ายไปแล้วออกจาก oCIS อย่าใช้แฟล็กการรีเซ็ตเป็นกลยุทธ์การลองใหม่เป็นประจำ หากขั้นตอนใดล้มเหลว ให้เก็บรักษาบันทึก ระบุสิ่งที่ถูกสร้างขึ้น และปรึกษาคู่มือการย้ายข้อมูลหรือฝ่ายสนับสนุนก่อนตัดสินใจว่าจะซ่อมแซมเป้าหมายหรือเริ่มต้นใหม่บนเป้าหมายที่สะอาด
ขั้นตอนที่ 5: เปลี่ยนระบบโดยมีช่วงเวลาตรวจสอบและกู้คืนอย่างรอบคอบ
เพื่อให้การเปลี่ยนผ่านเป็นไปอย่างปลอดภัย Cedar Studio จะกำหนดช่วงเวลาที่พนักงานหยุดแก้ไขไฟล์ใน Classic จากนั้นจึงทำการย้ายข้อมูลที่ได้รับอนุมัติ และค่อยแนะนำให้ลูกค้าและผู้ใช้ไปใช้ oCIS ก็ต่อเมื่อการตรวจสอบผ่านแล้วเท่านั้น การหยุดเขียนข้อมูลนี้เป็นมาตรการป้องกันความปลอดภัยในการปฏิบัติงาน ไม่ใช่การอ้างว่าแอปพลิเคชันการย้ายข้อมูลทำการซิงโครไนซ์แบบเรียลไทม์ คู่มือการย้ายข้อมูลที่เผยแพร่ไม่ได้ระบุถึงการซิงโครไนซ์อย่างต่อเนื่องหรือคำสั่งคัดลอกส่วนต่างขั้นสุดท้าย หากธุรกิจไม่สามารถยอมรับการหยุดเขียนข้อมูลได้ โปรดสอบถามฝ่ายสนับสนุน ownCloud เกี่ยวกับแผนการเปลี่ยนผ่านเฉพาะเวอร์ชันก่อนที่จะรับประกันการย้ายข้อมูลโดยไม่มีการหยุดทำงาน
ตรวจสอบความถูกต้องโดยใช้รายการตรวจสอบแทนการเข้าสู่ระบบของผู้ดูแลระบบเพียงครั้งเดียว:
- ตรวจสอบให้แน่ใจว่าผู้ใช้ กลุ่ม และการเป็นสมาชิกกลุ่มที่คาดหวังปรากฏใน oCIS และตรวจสอบการกำหนดบทบาท โดยเฉพาะอย่างยิ่งสำหรับอดีตผู้ดูแลระบบ
- ให้ผู้ใช้เปิดไฟล์ตัวอย่างที่ย้ายมาจากพื้นที่ส่วนตัวหลายแห่ง รวมถึงไฟล์ขนาดใหญ่และเอกสารที่แก้ไขล่าสุด
- ทดสอบการแชร์ไฟล์ภายในสำหรับผู้ใช้แต่ละคนและการแชร์ไฟล์แบบกลุ่ม โดยใช้ทั้งบัญชีเจ้าของและบัญชีผู้รับ
- เปิดลิงก์สาธารณะในเซสชันเบราว์เซอร์ส่วนตัว รีเซ็ตรหัสผ่านบนลิงก์ที่ได้รับการป้องกันที่ย้ายมา และสร้างลิงก์ใหม่ที่ไม่ผ่านการตรวจสอบนโยบาย
- สร้างการเชื่อมต่อภายนอกขึ้นใหม่ และย้ายหรือเชื่อมต่อข้อมูลที่เชื่อมต่อเหล่านั้นชี้ไปอีกครั้ง จากนั้นตรวจสอบว่าผู้ใช้มีสิทธิ์เข้าถึงตามที่ต้องการหรือไม่
- โปรดตรวจสอบโปรแกรมบนเดสก์ท็อปและมือถือ การลงชื่อเข้าใช้ การซิงค์ และช่องทางการสนับสนุนสำหรับการรีเซ็ตรหัสผ่าน ก่อนที่จะประกาศที่อยู่ใหม่
เก็บรักษา Classic ไว้ในสถานะอ่านอย่างเดียวที่ควบคุมได้ หรือสถานะแช่แข็งอื่นๆ จนกว่าเจ้าของธุรกิจจะลงนามอนุมัติและตรวจสอบบันทึกที่จำเป็นแล้ว ลบความสามารถในการปลอมแปลงตัวตนชั่วคราวและเพิกถอนโทเค็นแอปการย้ายข้อมูลเมื่อไม่จำเป็นอีกต่อไป จากนั้นทำการสำรองข้อมูล oCIS และทดสอบโดยใช้ขั้นตอนสำหรับโครงสร้างการจัดเก็บข้อมูลการพิจารณาการสำรองข้อมูล oCIS 8.2 อย่างเป็นทางการ ระบุว่าอินสแตนซ์จะต้องปิดระบบอย่างสมบูรณ์สำหรับขั้นตอนการสำรองข้อมูลที่บันทึกไว้ และอธิบายว่าเมตาเดต้าและไฟล์บล็อบอาจมีเส้นทางการจัดเก็บที่แยกจากกัน
การย้ายระบบที่ประสบความสำเร็จมีลักษณะอย่างไร
ในตัวอย่างของ Cedar Studio ความสำเร็จไม่ได้หมายความเพียงแค่เว็บอินเทอร์เฟซของ oCIS โหลดขึ้นมาเท่านั้น แต่หมายความว่าพนักงานสามารถยืนยันตัวตนด้วยแหล่งข้อมูลประจำตัวที่ต้องการ ค้นหาเนื้อหาในไดเร็กทอรีส่วนตัว เปิดไฟล์ของทีม และใช้แชร์ที่สร้างใหม่หรือย้ายมาด้วยสิทธิ์ที่คาดหวังไว้ การรีเซ็ตรหัสผ่าน การเชื่อมต่อภายนอก และการเปลี่ยนแปลงลิงก์สาธารณะได้รับการจัดการแล้ว ในขณะที่ Classic ยังคงใช้งานได้จนกว่าจะได้รับการยอมรับ หากการตรวจสอบใดๆ ล้มเหลว ให้หยุดการเปลี่ยนระบบชั่วคราว บันทึกผู้ใช้และวัตถุที่ได้รับผลกระทบ และแก้ไขปัญหาที่เกิดขึ้นก่อนที่จะถือว่า oCIS เป็นระบบบันทึกข้อมูลหลัก