Thống nhất lý do chuyển đổi
Giả sử bộ phận tài chính muốn giảm việc bảo trì, kinh doanh muốn truy cập thuận tiện giữa các địa điểm, còn CNTT muốn sắp xếp lại tài khoản cũ. Mọi người đều đồng ý đổi nền tảng, nhưng có thể đang hình dung những dự án khác nhau. Đây là tình huống giả định, không phải trường hợp khách hàng. Nếu chỉ bàn số hộp thư và ngày chuyển, khác biệt đó dễ bị bỏ qua.
Hãy mô tả kết quả bằng công việc có thể kiểm tra: nhân viên mới nhận đúng quyền, người tiếp quản tìm được trao đổi cần thiết, sự cố có người chịu trách nhiệm. Phân biệt yêu cầu bắt buộc, cải tiến làm sau và nội dung ngoài phạm vi. Tên nền tảng hay thông báo chuyển dữ liệu thành công chưa đủ để nghiệm thu.
Kiểm kê công việc phụ thuộc vào email
Đề nghị từng bộ phận xác định địa chỉ liên hệ công khai, hộp thư dùng chung, quyền gửi thay, lịch họp và thông báo tự động. Ghi mục đích, người phụ trách và ảnh hưởng khi gián đoạn. Một địa chỉ ít có người đăng nhập vẫn có thể nhận thông tin quan trọng từ khách hàng.
Tách riêng email, danh bạ, lịch, quyền và thiết lập gửi nhận trong danh sách. Microsoft nêu rõ di chuyển bằng IMAP xử lý thư, không chuyển danh bạ, lịch hay tác vụ. Vì vậy, chuyển xong hộp thư không đồng nghĩa mọi chức năng làm việc đều đã chuyển. Phương pháp cần được đối chiếu với nguồn, đích và phạm vi thực tế.
Chọn thử nghiệm đại diện cho cách làm việc
Nhóm thử nghiệm nên có người dùng thông thường, người quản lý hộp thư chung và nhân viên làm việc giữa các địa điểm. Thống nhất các việc cần thử: tìm trao đổi cũ, trả lời bên ngoài, dùng quyền được ủy quyền và nhận thông báo từ hệ thống. Người phụ trách phải xác nhận dữ liệu thử và phạm vi truy cập.
Chỉ chọn tài khoản nhỏ, ít phụ thuộc có thể tạo kết quả đẹp nhưng bỏ sót khó khăn chính. Chuyển các khác biệt phát hiện thành danh sách: việc phải xử lý trước, nhu cầu hướng dẫn và nội dung ngoài phạm vi. Không nên quy mọi phản ánh cho việc người dùng chưa quen giao diện.
Quy định ai có quyền tạm dừng
Lịch chuyển cần tính đến mùa cao điểm, giờ làm việc của từng nơi, thông báo cho người dùng và đầu mối tiếp nhận sự cố. Ai cho phép bắt đầu, tình huống nào cần dừng và việc trì hoãn ảnh hưởng đến đâu phải rõ trước khi thực hiện. Nếu cần đổi cấu hình tên miền hay nguồn gửi, phải có người đủ quyền tham gia.
Quay lại không chỉ là đổi một thiết lập. Sau khi chuyển có thể đã phát sinh thư và thao tác mới. Cần xác định cách xử lý phần chênh lệch đó, đồng thời kiểm tra môi trường cũ còn đáp ứng được phương án quay lại hay không. Không cam kết khôi phục ngay hoặc không gián đoạn khi chưa xác minh cách thực hiện.
Nghiệm thu dữ liệu và công việc
Ghi nhận phạm vi đã chuyển, mục lỗi và cách xử lý, rồi yêu cầu đại diện nghiệp vụ thực hiện công việc thường ngày. Đầu mối chung có tiếp tục trả lời khách hàng được không? Người dùng biết cách đăng nhập và nhờ hỗ trợ chưa? Mỗi vấn đề còn lại cần người phụ trách và ngày xem xét.
Việc ngừng môi trường cũ cũng cần điều kiện cụ thể. Kiểm tra đối soát dữ liệu, nghiệm thu nghiệp vụ và nhu cầu lưu giữ trước khi đóng truy cập. Hợp đồng hết hạn không tự chứng minh rằng mọi dữ liệu đã hết giá trị. Với phần không di chuyển, cần ghi rõ người xử lý và bước tiếp theo.
Kết thúc buổi họp bằng một bản phạm vi rõ ràng
Mời CNTT và các bộ phận mang đến mỗi bên một tình huống quan trọng. Tóm tắt mục tiêu, phạm vi dữ liệu, dịch vụ phụ thuộc, nhóm thử, điều kiện dừng và người nghiệm thu trên một trang. Làm rõ các câu hỏi còn thiếu trước khi chốt lịch hoặc công cụ.
Khi trao đổi với ACMI về dịch vụ di chuyển và phạm vi phù hợp của MigrateSuite, hãy chuẩn bị môi trường nguồn, đích, công việc then chốt và khoảng thời gian có thể chuyển. Các thông tin đó giúp lập kế hoạch có căn cứ hơn việc chỉ hỏi giá theo số hộp thư.
