GitHub组织迁移至Enterprise Cloud：配置与实操问题咨询

1. 先配置企业级SSO单独IdP，再迁移组织用户的方案可行性 #

完全可行，但需把控以下关键细节：

• 将现有Org纳入Enterprise Cloud后，不要立即强制组织继承企业SSO，先保留原组织的SAML SSO配置，同步完成企业级IdP的设置。
• 企业SSO配置完成后，逐步推进用户迁移：先引导用户通过企业SSO完成首次认证（关联企业身份），再批量移除原组织SAML下的用户关联，最后关闭原组织的独立SAML配置，切换为继承企业SSO。
• 必须确保企业IdP的用户核心属性（如邮箱）与原Org用户的属性完全匹配，否则会出现用户身份无法合并的问题。

2. 私有仓库转Internal解决InnerSource问题的合理性 #

这个思路是成立的：

• GitHub的Internal仓库权限允许企业内所有成员查看和协作，刚好适配InnerSource在企业内部共享代码的需求，无需逐个配置团队或用户权限。
• 但转换前务必做好排查：
  • 确认仓库内是否包含仅原Org成员可见的敏感数据，避免扩大权限范围后引发泄露。
  • 评估企业内其他Org成员是否需要访问这些仓库，避免不必要的权限开放。

3. 迁移中的意外问题与避坑建议 #

结合实际迁移经验，常见的风险和应对方法如下：

• SSO切换导致登录中断：
  • 迁移前创建企业测试用户，验证企业SSO的登录流程，确保IdP配置（如断言属性、签名算法）无问题。
  • 保留原组织SAML配置至所有用户完成企业SSO认证后再关闭，避免用户突然无法登录。
• 仓库权限变更引发访问异常：
  • 转换Internal仓库前，导出原仓库的权限列表（包括团队、外部协作者），避免遗漏特殊权限需求。
  • 对敏感仓库，可先维持Private状态并添加特定企业团队权限，而非直接转Internal。
• 许可席位冲突：
  • 迁移前核对企业许可的席位数量，确保覆盖原Org的所有付费用户，避免用户被强制转为免费账户。
  • 注意：企业级许可会自动合并所有下属Org的席位，无需重复购买，但要提前清理已离职或不再需要访问的用户。
• 第三方应用授权失效：
  • 原Org的第三方应用（如CI/CD工具）基于组织SAML授权，迁移至企业SSO后，需要重新授权这些应用使用企业身份体系。
  • 提前梳理所有集成的第三方应用，制定重新授权的时间表，避免业务中断。
• 团队结构混乱：
  • 迁移前整理原Org的团队层级，将需要跨Org共享的团队升级为企业级团队，避免重复创建和权限冗余。

内容的提问来源于stack exchange，提问作者mikey