本文经客户授权发布，应要求对工作室名称与部分细节做了模糊处理。
星野设计是一家 20 人规模的独立设计工作室，客户以消费品牌与互联网公司为主。今年年初，他们做了一个在同行看来"有点较真"的决定：把用了三年的 SaaS 任务管理工具，整体迁移到私有化部署的 PriTime。本文记录这三周迁移过程的真实样本——包括两个计划外的坑。
为什么迁移：一个具体事件，而不是抽象理念
促使工作室下决心的不是某篇隐私文章，而是一次续费评估。创始人阿哲在整理账号时发现三个问题叠在了一起：
- 任务清单成了敏感信息集散地：客户资料核对、报价审批、未发布的品牌方案，全在任务描述和附件里，而服务器在境外、账号权限按席位管理
- 一个前外包人员的账号在离职半年后仍能通过历史邀请链接看到部分项目——虽然没造成后果，但排查过程让他们意识到自己根本不清楚数据的实际可见边界
- 按席位订阅的费用，三年累计已经超过一台好服务器的价格
"我们可以接受工具不完美，但不能接受不知道谁知道我们在做什么。"阿哲的总结很直接。
迁移三周：实际做了什么
第一周：并行试运行（只迁一个项目）
- 用 Docker 在一台内网服务器上部署 API 与 Web 端，半天完成，比预期快（部署指南）
- 选一个即将收尾的客户项目做平行记录：新旧系统同时更新
- 每天收工前花 5 分钟对比两边的任务状态，确认同步与提醒的可靠性
计划外的坑 ①：团队习惯用手机随手拍参考图直接扔进任务，第一周发现移动端 App 需要单独连接自建服务器，配置花了半小时才弄对。后来看文档才发现先配 API 地址再登录就一步到位。
第二周：整体切换（设定"切换日"）
- 周三定为切换日：之后的新任务只进新系统，旧系统标记为只读
- 迁移策略是只迁进行中项目，历史项目导出归档——"搬家是扔东西的最好机会"，他们借机清理了 40% 的僵尸任务
- 建立新的协作约定：任务状态流转规则、每周回顾定在周五下午
计划外的坑 ②：切换日当天有客户在旧系统里留了反馈，差点遗漏。教训是把"切换公告"提前发给所有相关方，并在旧系统置顶一条"已迁移"的说明任务。
第三周：收尾与固化
- 旧系统导出归档（CSV + 附件包），存入工作室自己的备份盘
- 配置了每日自动备份：数据库快照 + 附件目录，异地存一份
- 与官网文档对照做了一次权限复查，确认只有在职成员可访问
六周后的回访数据
迁移完成六周后，我们回访了团队的使用情况：
- 续费成本：服务器年费用约为原订阅费用的 1/4，且不再随人数增长
- 使用情况：全员日常使用，无一人要求退回旧工具；设计师们最喜欢的是课程表视图（用于排设计档期）和专注计时（画图时防打断）
- 数据边界：所有数据不出办公室内网，远程访问走 VPN
- 维护投入：由一位对 Docker 熟悉的设计师兼任，每月投入约 1 小时（更新镜像 + 检查备份）
被问及"有没有后悔"，阿哲的回答是："唯一后悔的是没早点做。之前三年，我们把报价和方案存在别人的服务器上，居然觉得理所当然。"
给考虑迁移的团队的三条建议
- 找一个"低风险项目"先并行一周，验证同步、提醒、附件这些日常动线，再全面切换
- 切换日要设公告，且旧系统至少保持两周只读，防止信息断档
- 迁移是最好的断舍离——只迁活的任务，历史数据归档而不是照搬，新系统的启动成本会低很多
详细的迁移步骤与部署方式，可以参考私有化部署完全指南与官网的开源说明。如果你的团队也在评估类似方案，欢迎联系我们交流。
结语
这个案例里没有技术奇迹，只有一次被具体事件触发的、朴素的数据主权觉醒。对内容创意行业来说，"正在做的方案"就是核心资产——它值得放在自己手里。