哈佛大学运行 Drupal。耶鲁、普林斯顿、斯坦福和杜克也是如此。你的大学也是。你知道升级周期：D7 到 D8 是完全重建。D8 到 D9 需要大量工作。D9 到 D10 破坏了贡献模块。D10 到 D11 将在 2026 年末推出，采用 Symfony 7 和 Twig 4。对于一次 Drupal 迁移的成本，你的大学可以迁移到 Next.js + Supabase，再也不用面临强制的 CMS 迁移。

这是我们针对教育行业的迁移指南。有关一般概述，请参阅我们的 Drupal 迁移页面。本页涵盖了大学 Drupal 安装的独特复杂性，以及我们如何处理每一个方面。

Drupal 高等教育生态系统

大学 Drupal 安装与企业网站不同。它们是庞大的多利益相关者系统 — 特定教育的内容类型、深度嵌套的分类法、拥有独立编辑的部门子网站、与学生信息系统的集成。通用迁移方法将失败。

特定教育的内容类型

你的 Drupal 实例可能有 10 多个为高等教育构建的自定义内容类型：

• 课程 — 学位、证书和课程信息，包含学分、学费、授课方式、职业成果
• 教职员工 — 个人资料，包括研究兴趣、发表著作、教授课程、办公时间
• 部门 — 层次结构（工程学院 → 计算机科学系 → 人工智能实验室）
• 活动 — 学术日历、公开活动、毕业典礼、部门特定活动
• 新闻 — 大学新闻、部门新闻、研究公告、新闻稿
• 页面 — 数百个基本内容页面（关于、招生、财政援助）
• 发表 — 研究论文、报告、政策文件，带有 DOI 链接
• 职位发布 — 教职员位置、员工职位、学生就业
• 个人资料 — 非教职员工的员工目录条目
• 推荐 — 学生和校友成功故事

每个都映射到一个具有适当关系设计的 Supabase 表。课程获得 degree_level、subject_area_id、delivery_mode、tuition 和作为 JSONB 的 career_outcomes。教职员工获得 department_id 外键、作为 JSONB 的 publications 和作为数组的 research_areas。部门使用 parent_id 实现自引用层次结构。

这不是平坦的内容转储。这是一个适当的关系模式，使你的数据可以以 Drupal Views 永远无法实现的方式进行查询。

Drupal Views → Next.js 服务器组件

大学网站大量依赖 Drupal Views 进行可过滤的列表。每一个都变成更快、更灵活的 Next.js 页面：

• 课程查找器 — 按主题、学位级别、校园过滤的 Drupal View → 带有 Supabase 查询和基于 URL 的过滤器状态的 Next.js /programs 页面。准学生按兴趣领域过滤并获得即时结果。
• 教职员工目录 — 按部门、研究领域过滤的 Drupal View → 带有全文搜索和针对 Supabase 的部门过滤的 Next.js /faculty 页面。
• 活动日历 — 按日期、部门、类型过滤的 Drupal View → 带有日期范围过滤和 iCal 导出的 Next.js /events 页面。
• 新闻源 — 按部门、类别过滤的 Drupal View → 带有 ISR 的 Next.js /news 页面，以便新文章在发布后 60 秒内出现。
• 职位板 — 按部门、就业类型过滤的 Drupal View → 从 Supabase 提取的 Next.js /careers 页面，带有关闭日期逻辑。

区别：Drupal Views 在每次过滤更改时生成完整页面加载。带有 Supabase 的 Next.js 服务器组件在不到 100 毫秒内返回过滤结果，无需完整页面重新加载。

Drupal 分类法 → Supabase 关系

Drupal 分类法词汇映射到适当的关系表：

• 主题领域词汇 → subject_areas 表、programs.subject_area_id FK
• 部门词汇 → departments 表，其中 parent_id 用于层次结构
• 校园位置词汇 → campuses 表、programs.campus_id FK
• 研究领域词汇 → research_areas 表 + faculty_research_areas 联接表
• 活动类型词汇 → event_type 枚举列或查找表

Drupal 的实体引用字段变成适当的外键。多对多关系（教职员工 ↔ 研究领域）获得联接表。数据模型变得显式而不是隐藏在 Drupal 的实体 API 后面。

段落 + 布局生成器 → 组件块

Drupal 段落是大学迁移中最大的痛点。你的编辑已使用数十种段落类型构建页面：英雄横幅、统计部分、教职员工聚焦、课程卡网格、手风琴常见问题、嵌入式视频、行动号召块。

我们将这些存储为 Supabase 的 pages.blocks 列中的 JSONB：

[
  {"type": "hero", "title": "...", "subtitle": "...", "image": "...", "cta_url": "..."},
  {"type": "stats", "items": [{"number": "15:1", "label": "Student-Faculty Ratio"}]},
  {"type": "program_cards", "program_ids": [12, 45, 78]},
  {"type": "faculty_spotlight", "faculty_id": 234}
]

Next.js 组件注册表渲染每个块类型。编辑通过 Payload CMS 或自定义管理界面管理块。与段落相同的灵活性、更快的渲染速度，无需 Drupal 缓存重建等待。

多站点部门子网站

大型大学运行 15–30 个 Drupal 子网站 — 商学院、工程学院、文理学院 — 每个都在单独的 Drupal 安装或 Drupal 多站点上。这是一场运营噩梦：跨 20 个站点的模块更新、不一致的主题、重复的基础设施。

我们将所有内容整合到一个具有 /departments/[slug] 路由的 Next.js 应用程序中。每个部门获得自己的部分，具有子品牌身份（大学设计系统内的自定义强调色）。部门页面、新闻、活动和教职员工都限定在他们的部门。

关键：Supabase 行级安全 (RLS)。部门编辑只能看到和编辑 department_id 与其分配部门相匹配的内容。商学院网络编辑无法意外编辑工程内容。RLS 在数据库级别强制执行这一点 — 不在应用程序代码中，不在 CMS 权限中。这是结构性的。

学生门户和 SSO 集成

你当前的 Drupal 网站通过 CAS 或 Shibboleth 对学生进行身份验证，连接到你的身份提供者（ADFS、Okta 或大学管理的 Shibboleth IdP）。学生看到个性化内容：他们的课程要求、顾问信息、部门特定资源。

Supabase Auth 原生支持 SAML 2.0。我们在 Supabase 中将你的大学身份提供者配置为 SAML 提供者。流程：

1. 学生点击 Next.js 网站上的"登录"
2. 重定向到大学 IdP (Shibboleth/ADFS/Okta)
3. 学生使用大学凭证进行身份验证
4. IdP 将 SAML 断言发送回 Supabase
5. Supabase 发布带有学生角色和部门的 JWT
6. RLS 政策控制他们看到的数据

无需自定义身份验证代码。无需会话管理麻烦。JWT 携带声明，Supabase RLS 读取它们。

用户角色迁移

大学的 Drupal 角色 — 网站管理员、网络编辑、部门编辑、教职员工、学生、校友 — 映射到 Supabase 中的 user_roles 表，具有每个用户的角色分配。RLS 政策引用这些角色：

• 网站管理员：对所有表的完整读/写访问
• 部门编辑：读/写 department_id = auth.jwt()->department_id 的位置
• 教职员工：更新他们自己的个人资料、添加发表
• 学生：对公开内容的只读、个性化仪表板数据

7 阶段教育迁移

阶段 1：发现和内容审计（1–2 周）

对每个 URL 进行尖叫青蛙爬虫。Google Search Console 流量分析以识别你的最高价值页面。跨所有子网站的内容类型库存。集成审计：什么连接到 Drupal？Banner？PeopleSoft？Canvas？Slate？使用 Lighthouse 分数和任何现有 ADA 投诉的可访问性基准。

阶段 2：架构和模式设计（1 周）

具有表、关系和 RLS 政策的 Supabase 模式。Next.js 路由结构。导航层次结构。关于管理界面的决定：为非技术编辑选择 Payload CMS 或自定义 Supabase 仪表板。SSO、SIS 数据提取和 CRM webhook 的集成架构。

阶段 3：从 Drupal 导出数据（1–2 周）

D8/D9/D10：通过 /jsonapi/node/program?page[limit]=50 的 JSON:API 导出，对每个内容类型进行分页。D7：针对 Drupal 字段表的直接 MySQL 查询。从 public:// 和 private:// 文件系统导出媒体。用户和分类法导出。菜单结构提取。

阶段 4：构建（3–8 周）

具有所有页面模板的 Next.js 应用程序。使用转换数据填充的 Supabase 表和活跃的 RLS 政策。带有分面过滤的课程查找器。带有搜索的教职员工目录。部门部分。带有 SSO 的学生门户。管理界面。所有集成 — SIS 数据提取、CRM webhook、校园参观预订。

阶段 5：内容导入和验证（1–2 周）

将 Drupal 导出转换为 Supabase 插入脚本。导入所有内容类型。将媒体上传到 Supabase Storage 或 Vercel Blob。重写内容中的媒体 URL。抽查每个内容类型的 10%。测试每个过滤器、搜索和导航路径。

阶段 6：重定向映射（1 周）

这对大学至关重要。你的 .edu 域有数千个来自其他教育机构、政府网站和研究数据库的反向链接。失去这些反向链接对 SEO 权限是灾难性的。我们映射每个 Drupal URL — 别名、系统路径 (/node/1234) 和子网站 URL — 到新的 Next.js 路由。通过 Next.js 中间件实现，具有无限的重定向容量。

阶段 7：启动和监控（持续进行）

DNS 切换。向 Google Search Console 提交新站点地图。前 30 天每天 404 监控。Payload CMS 或自定义管理员的员工培训。部门管理员培训。教职员工自我更新工作流培训。30 天的超级关怀，包括每日监控和与你的网络团队的每周检查。

定价

机构类型	页面	范围	时间线	投资
社区学院	少于 500	课程查找器、基本目录、新闻	6–8 周	$50–80K
中型大学	500–2,000	课程查找器、教职员工目录、部门部分、活动	8–12 周	$80–150K
大型大学	2,000+	多校园、部门子网站、学生门户、SSO、i18n	10–16 周	$120–200K

为什么现在：D11 时钟正在滴答

Drupal 11 在 2026 年末推出，采用 Symfony 7 和 Twig 4。D10 上的大学在未来 6–12 个月面临迁移决定。D10 到 D11 的迁移最少运行 $30–60K — 你将在另外 3–4 年内面临 D12。

根据范围的不同，Next.js + Supabase 迁移运行 $50–200K，但 5 年总拥有成本低于停留在 Drupal 上。无强制升级。无贡献模块破坏。无需要紧急补丁的 Drupal 安全咨询。你的框架按你的时间表更新，而不是 Drupal 的。

对于一次更多的 Drupal 迁移的成本，使其成为你的最后一次。