Di chuyển Drupal là một trong những dự án nằm yên rất thoải mái trong kế hoạch của quý sau, cho tới khi một cái mốc thời gian khiến nó thành việc gấp. Ngay lúc này có hai cái mốc đang làm đúng chuyện đó, và chỉ một trong hai còn nằm ở phía trước.

Drupal 7 mất hỗ trợ chính thức vào ngày 5 tháng 1 năm 2025. Bất kỳ website nào còn chạy phiên bản đó đều đã sống hơn một năm mà không có lớp bảo vệ an ninh nào. Drupal 10 kết thúc vòng đời vào ngày 9 tháng 12 năm 2026, đúng tuần Drupal 12 ra mắt, và sau mốc đó nó không nhận thêm bản phát hành nào nữa, thuộc bất kỳ loại nào. Nếu bạn đang ở một trong hai phiên bản này, câu hỏi không còn là có nên chuyển hay không, mà là chọn lộ trình nào và tốn bao nhiêu.

Bạn đang đứng ở đâu: từ Drupal 10 lên Drupal 11 là một bản nâng cấp thật sự, vẫn cùng một website được cập nhật tại chỗ, thường mất hai đến sáu tuần. Từ Drupal 7 lên Drupal 11 hoàn toàn không phải nâng cấp; đó là xây lại kèm theo một đợt chuyển nội dung, và thường kéo dài ba đến sáu tháng. Nhầm lẫn hai việc này là sai lầm đắt đỏ nhất trong lĩnh vực này, bởi các website Drupal 7 được báo giá như một bản nâng cấp rồi đội lên gấp bốn lần.

Hai cuộc di chuyển rất khác nhau

Chữ di chuyển bao trùm hai công việc gần như không có gì chung ngoài cái tên.

Từ Drupal 10 lên 11 là nâng cấp. Kiến trúc vẫn nguyên như cũ. Các thực thể, trường dữ liệu, khung hiển thị và cấu hình đều đi theo. Phần lớn công việc là quản lý phụ thuộc: bảo đảm mọi mô đun cộng đồng đang dùng đều có bản phát hành tương thích Drupal 11, dọn sạch những lời gọi tới các giao diện lập trình đã bị đánh dấu loại bỏ trong mã tự viết, và chuyển sang một phiên bản PHP còn được hỗ trợ. Việc này thiên về tỉ mỉ hơn là khó, và một website được chăm sóc tử tế có thể xong trong khoảng hai tuần.

Từ Drupal 7 lên Drupal 11 là xây lại. Drupal 8 đã viết lại nền tảng trên các thành phần Symfony, thay luôn giao diện lập trình cho mô đun, lớp giao diện hiển thị và hệ thống cấu hình. Không có gì đi theo một cách tự động ngoài nội dung, mà nội dung cũng phải đi qua một quy trình chuyển dữ liệu dựng riêng chứ không phải một kịch bản nâng cấp. Các mô đun bạn từng dùng không còn tồn tại, giao diện phải viết lại bằng Twig, và mã tự viết phải được cài đặt lại trên một kiến trúc khác hẳn.

Trường hợp thứ hai chính là lý do các website Drupal 7 nán lại lâu đến vậy. Cách nói thật lòng là bạn không nâng cấp một website, bạn dựng một website mới và mang nội dung theo cùng.

Mỗi lộ trình di chuyển Drupal tốn bao nhiêu

Các con số dưới đây giả định mức phí của một công ty ở Anh và một website có độ phức tạp vừa phải. Phức tạp ở đây là số loại nội dung, số mô đun cộng đồng và số mô đun tự viết, không phải số trang.

Drupal 10 lên 11, website được chăm sóc tốt. Hai đến bốn tuần, khoảng 6.000 đến 15.000 bảng. Đây là trường hợp dễ chịu: mô đun đều mới, mã tự viết ít, và phần việc chính là kiểm thử.

Drupal 10 lên 11, website bị bỏ bê. Bốn đến tám tuần, khoảng 15.000 đến 35.000 bảng. Ở đây thứ chặn đường là những mô đun cộng đồng không có bản cho Drupal 11, mã tự viết dựa trên các giao diện lập trình đã bị gỡ, và một phiên bản PHP cũng phải nâng theo. Mỗi mô đun bị bỏ rơi trở thành một quyết định: tìm thứ thay thế, tự nhận việc bảo trì, hoặc viết lại hành vi của nó.

Drupal 7 lên Drupal 11. Ba đến sáu tháng, thường là 40.000 đến 120.000 bảng và cao hơn với các website lớn hoặc tùy biến nhiều. Khoảng này rộng vì thực chất đó là ngân sách xây lại. Bản thân việc chuyển nội dung thường là nửa nhỏ hơn; giao diện, các tính năng riêng và những tích hợp bên ngoài mới là nửa lớn.

Từ Drupal 7 sang một nền tảng khác. Đôi khi đây mới là câu trả lời đúng. Nếu lý do ban đầu chọn Drupal không còn đúng nữa, chẳng hạn website đã trở thành một trang giới thiệu kèm blog, thì chuyển sang thứ đơn giản hơn có thể rẻ hơn là chuyển trong nội bộ Drupal, và giảm cả chi phí vận hành về sau. Bài so sánh của chúng tôi giữa WordPress và phát triển theo yêu cầu chỉ ra ranh giới đó nằm ở đâu, còn hướng dẫn phát triển web với Drupal nói thẳng những lúc Drupal không phải câu trả lời.

Vì sao mô đun cộng đồng quyết định tiến độ của bạn

Gần như mọi ước lượng nâng cấp Drupal đều sống chết nhờ đợt rà soát mô đun cộng đồng, và đó là việc đáng làm đầu tiên.

Hãy liệt kê từng mô đun cộng đồng mà website đang dùng, rồi kiểm tra xem mỗi cái có bản phát hành ổn định tương thích với phiên bản đích hay không. Những gì bạn tìm thấy sẽ rơi vào bốn nhóm. Một số đã có bản tương thích và không đòi hỏi gì. Một số có bản ứng viên hoặc một bản vá trong hàng đợi vấn đề mà bạn có thể áp qua Composer. Một số đã bị bỏ rơi, và bạn phải tìm thứ thay thế, tự đứng ra duy trì, hoặc thay chức năng của nó bằng mã tự viết. Và một số đã được đưa vào lõi Drupal, đây là bất ngờ dễ chịu của cả bài tập này.

Đợt rà soát đó biến một dự án mơ hồ thành một dự án đếm được. Chừng nào chưa làm, mọi báo giá đều là phỏng đoán, và một nhà cung cấp đưa giá trọn gói mà chưa rà soát thì hoặc đã cộng biên rất dày, hoặc sắp gửi cho bạn một loạt yêu cầu phát sinh.

Cùng một logic ấy áp dụng cho mô đun tự viết, chỉ khác công cụ. Bộ công cụ phát hiện mã lỗi thời của Drupal sẽ quét mã tự viết và báo cáo những lời gọi tới các giao diện lập trình đã bị gỡ hoặc sắp bị gỡ, biến câu chúng tôi có một ít mã tự viết thành một danh sách cụ thể gồm tên tệp và số dòng.

Điều gì thật sự hay hỏng

Một số kiểu hỏng lặp lại ở gần như mọi cuộc di chuyển Drupal.

Cấu hình lệch nhau giữa các môi trường. Nếu các thay đổi được thực hiện thẳng trong giao diện quản trị của bản chạy thật thay vì xuất ra tệp cấu hình, thì môi trường thử nghiệm của bạn không phải bản sao trung thực và việc kiểm thử có giá trị thấp hơn bạn tưởng. Phát hiện điều này giữa chừng cuộc di chuyển là chuyện thường gặp, và luôn tốn thời gian.

Nội dung chưa bao giờ có cấu trúc như mọi người vẫn tin. Các website Drupal 7 thường tích tụ nội dung theo những cách không ai ghi lại: trường dữ liệu bị dùng sang việc khác, một bộ phân loại đóng vai trò trạng thái quy trình biên tập, mã HTML dán thẳng vào trường nội dung kèm cả kiểu định dạng nội tuyến. Một cuộc di chuyển làm tất cả lộ ra cùng lúc, và mỗi trường hợp cần quyết định từ người biết nội dung đó dùng để làm gì.

Xử lý tệp và thư viện đa phương tiện. Cách Drupal xử lý tệp đa phương tiện đã thay đổi đáng kể sau Drupal 7. Tệp, kiểu ảnh và nội dung nhúng hiếm khi ánh xạ một đối một, nên website có thư viện lớn nên tính riêng phần này vào ngân sách thay vì mặc định coi nó đi kèm miễn phí với việc chuyển nội dung.

Tính liên tục của đường dẫn và thứ hạng tìm kiếm. Đây là điểm làm tổn thương công việc kinh doanh chứ không chỉ tiến độ. Nếu các bí danh đường dẫn đổi mà không có chuyển hướng, bạn mất luôn thứ hạng mà website cũ đã gây dựng. Mỗi cuộc di chuyển đều cần một bản kiểm kê đầy đủ đường dẫn, một bảng chuyển hướng và một vòng kiểm tra sau khi lên sóng. Hướng dẫn của chúng tôi về cách chuyển website mà không mất lưu lượng mô tả quy trình đó chi tiết, và nó đúng với việc đổi nền tảng chẳng kém gì đổi tên miền.

Nội dung đa ngôn ngữ. Nếu website chạy nhiều ngôn ngữ, hãy tính rằng cuộc di chuyển sẽ lâu hơn đáng kể. Cách xử lý ngôn ngữ đã được dựng lại sau Drupal 7, và nội dung đã dịch, cấu hình đã dịch cùng các quy tắc đường dẫn theo từng ngôn ngữ đều đòi hỏi sự chú ý riêng.

Sắp xếp thứ tự công việc thế nào

Thứ tự quan trọng hơn phần lớn các nhóm dự đoán, và làm sai thì phải làm lại.

Hãy bắt đầu bằng đợt rà soát mô đun cộng đồng và mã tự viết, trước mọi ước lượng. Sau đó đưa website lên một phiên bản PHP còn được hỗ trợ và lên bản phát hành mới nhất của nhánh chính hiện tại, vì việc đó gạt bỏ cả một nhóm nhiễu ra khỏi cuộc nâng cấp thật sự. Chỉ khi đó mới thử bước nhảy phiên bản lớn.

Hãy dựng môi trường mới bên cạnh môi trường cũ thay vì nâng cấp tại chỗ. Như vậy bạn có chỗ để chạy đi chạy lại việc chuyển nội dung, điều chắc chắn sẽ cần, bởi các cuộc chuyển dữ liệu được chạy rất nhiều lần trước khi được chạy một lần thật.

Hãy coi việc chuyển nội dung như mã nguồn. Bộ khung di chuyển của Drupal cho phép định nghĩa các bước chuyển trong cấu hình rồi chạy lại, nghĩa là bạn có thể đặt lại từ đầu, chỉnh ánh xạ và chạy tiếp. Những nhóm sửa nội dung bằng tay trong website mới thay vì sửa định nghĩa chuyển dữ liệu rốt cuộc không chạy lại được nữa, và từ đó một thay đổi nội dung nhỏ ở website cũ biến thành công việc đối chiếu thủ công.

Cuối cùng, hãy tính một khoảng đóng băng nội dung ở gần cuối và giữ nó thật ngắn. Đóng băng dài khiến người biên tập tìm cách lách qua bạn, và như thế sinh ra đúng cái lệch lạc mà bạn muốn tránh.

Có nên rời hẳn Drupal không?

Đây là câu hỏi chính đáng và xứng đáng có một câu trả lời thành thật thay vì phòng thủ.

Hãy ở lại với Drupal khi những lý do bạn chọn nó vẫn còn đúng: mô hình nội dung phức tạp, phân quyền chi li, yêu cầu đa ngôn ngữ, quy trình biên tập nặng, hoặc nghĩa vụ về khả năng tiếp cận và khu vực công. Drupal thật sự mạnh ở tất cả những điểm này, và lộ trình nâng cấp từ đây đã ổn định, với chu kỳ phiên bản lớn hai năm một lần có thể đoán trước.

Hãy cân nhắc chuyển đi khi website đã trôi xa khỏi những nhu cầu đó. Rất nhiều website Drupal 7 giờ đây thực chất chỉ là một trang giới thiệu kèm tin tức và một biểu mẫu liên hệ. Chuyển thứ đó trong nội bộ Drupal nghĩa là trả giá xây lại cho những năng lực bạn không còn dùng.

Quyết định nên dựa trên mô hình nội dung và khối lượng biên tập, chứ không phải nền tảng mà lập trình viên của bạn ưa thích. Nếu không ai nói rõ được Drupal đang làm gì cho bạn mà một nền tảng đơn giản hơn không làm nổi, bản thân điều đó đã nói lên nhiều.

Hãy rà soát trước khi xin báo giá

Mecanik nhận nâng cấp và di chuyển Drupal như một phần của dịch vụ phát triển website . Chúng tôi bắt đầu bằng đợt rà soát mô đun cộng đồng và mã tự viết, vì đó là thứ biến một dự án mở thành một phạm vi cố định, và nó đáng có ngay cả khi sau đó bạn giao việc cho nơi khác.

Với website Drupal 10, nước đi hợp lý là lên kế hoạch cho bước sang Drupal 11 ngay bây giờ chứ không phải vào tháng 11, khi ai cũng làm việc đó. Với website Drupal 7, riêng tình trạng an ninh đã là lý lẽ đủ mạnh. Nếu giới hạn của bạn là nhân lực chứ không phải chuyên môn, hướng dẫn của chúng tôi về thuê lập trình viên Drupal chỉ ra những gì cần tìm.

Hãy cho chúng tôi biết bạn đang ở phiên bản nào và website dùng khoảng bao nhiêu mô đun cộng đồng cùng mô đun tự viết, chúng tôi sẽ nói cho bạn biết thực tế bạn đang đối mặt với lộ trình nào trong số trên.

Bài viết liên quan: Hiện đại hóa PHP legacy: hướng dẫn 2026 , Symfony vs Laravel 2026: chọn framework PHP nào , Bảo mật API: Cách bảo vệ một API công khai năm 2026 , Phát triển website y tế và chăm sóc sức khỏe tại Vương quốc .

Câu hỏi thường gặp

Khi nào Drupal 10 hết được hỗ trợ? Drupal 10 kết thúc vòng đời vào ngày 9 tháng 12 năm 2026, đúng tuần Drupal 12 ra mắt. Sau mốc đó nó không nhận thêm bản phát hành nào nữa, kể cả bản vá bảo mật. Vì vậy mọi website còn ở lại phiên bản này đều đang chạy mà không có hỗ trợ.

Di chuyển Drupal tốn bao nhiêu tiền? Nâng cấp Drupal 10 lên 11 trên một website được chăm sóc tốt thường tốn 6.000 đến 15.000 bảng. Con số này tăng lên 15.000 đến 35.000 bảng khi mô đun và mã tự viết bị bỏ bê. Từ Drupal 7 lên Drupal 11 là xây lại kèm chuyển nội dung, thường rơi vào 40.000 đến 120.000 bảng hoặc hơn.

Vì sao từ Drupal 7 lên Drupal 11 lại đắt đến vậy? Bởi vì đó không phải một bản nâng cấp. Drupal 8 đã dựng lại nền tảng trên các thành phần Symfony, thay giao diện lập trình cho mô đun, lớp hiển thị và hệ thống cấu hình. Mô đun phải thay, giao diện phải viết lại bằng Twig, mã tự viết phải cài đặt lại, còn nội dung được đưa sang qua một quy trình chuyển dữ liệu dựng riêng.

Nâng cấp Drupal 10 lên 11 mất bao lâu? Hai đến bốn tuần với website có mô đun cộng đồng đều mới và mã tự viết ít. Sẽ là bốn đến tám tuần khi phải xoay xở với mô đun bị bỏ rơi hoặc giao diện lập trình đã bị gỡ. Chính đợt rà soát mô đun cộng đồng làm trước mới khiến con số ước lượng đáng tin.

Tôi có thể chuyển từ Drupal sang WordPress thay thế không? Đôi khi đó là lựa chọn đúng, nhất là khi một website Drupal 7 đã trở thành trang giới thiệu đơn giản, không cần mô hình nội dung phức tạp, phân quyền chi li hay đa ngôn ngữ. Hãy dựa vào mô hình nội dung và khối lượng biên tập của bạn để quyết định, thay vì dựa vào sở thích nền tảng.