定制软件上线切换怎么做
定制软件要切到正式环境，先写好一份有顺序的切换手册，写明每一步由谁做、做到什么算过、什么情况退回旧环境。手册上还没有负责人和退回条件，就不要把正式环境交给用户。用户验收看的是谁按清单操作，验收标准看的是什么算完成；这一份手册看的是切换当晚的顺序。
目录
切换手册和验收清单分开写
切换手册是一份当晚照着做的顺序：先停哪一项、再搬哪一批数据、改完哪一个地址才让用户进来、做完哪一项核对才算切完。用户验收回答的是预定用户有没有按清单把结果做出来。验收标准回答的是旁人看得到的结果、谁负责、用演示还是用户验收。三份文件可以互相指到版本，不要把验收清单直接改成切换步骤。验收怎么逐条操作，见 定制软件 UAT 怎么做。什么算完成，见 定制软件验收标准怎么写。
范围在切换前若还要改，另开变更请求，不要在切换会议上把刚做好的画面写进手册。手册对上的是已经核准的规格版本。变更怎么留记录，见 定制软件范围变更怎么管。交付仍走 定制软件、网站与应用程序。手册的第一行写规格版本和预计切换的日期时刻，方便事后对回当时签的是哪一版。
AWS 范本先问做什么、谁做、何时做
2026年10月20日阅读的 AWS Prescriptive Guidance 切换手册范本 写明，切换手册应包含切换期间要做的全部活动，切换前的检查清单同样要写。两份可以并成一份文件，并回答三个问题：要做哪些活动、由谁做、应在何时做。该页附了切换前检查、切换手册和退回计划的例子，并用任务编号方便沟通。该页没有刊登日期，以上依这次阅读。范本里的任务是迁移例子，不是定制软件必须照抄的步骤。
同一页的切换表列出任务编号、任务、依赖、团队、负责人、计划开始与结束、实际开始与结束、状态和备注。例子从通知利害关系人停机、确认来源备份、停止来源服务，到迁移、核对基础设施、改 DNS、在目标端启动服务、做技术核对与业务核对、再通知迁移完成。退回表从停止目标端的应用与数据库服务开始，接着关闭目标服务器、把 DNS 指回来源、核对 DNS、启动来源、必要时把数据同步回去、在来源端启动服务，再做技术与业务核对，并通知已经退回。定制软件的手册沿用「每步有负责人、有计划时间、有实际时间、有状态」，步骤内容改写成这次上线真正要动的环境。
微软清单把切换和可否上线分开
2026年10月20日阅读的 Microsoft Learn：用上线清单确认方案是否就绪 把清单分成上线就绪、切换、方案范围复核、方案验收复核、用户验收完成、性能测试完成、系统集成测试完成、数据迁移就绪与验证、外部依赖确认、初期运营的变更管理，以及运营支持就绪。该页没有刊登日期。切换这一节只列三项：按顺序完成全部活动、达到退出条件、在切换的可否上线关口取得利害关系人签核。
上线就绪里有一项是建立切换计划，并考虑全部依赖、活动时点、角色与责任、操作说明、验证步骤，以及每项活动附带的其他文件。同一节还要求切换迁移用的脚本和程序先测试并由业务签核，外部依赖（例如伙伴系统）对上上线的时程和范围，并备好正式环境的监控与维护、以及把支持交给支持团队的安排。这些是该页列出的准备，不是定制项目必须采购 Dynamics 365 才做得到的事。手册上把「顺序、退出条件、可否上线的签核人」三行写出来，才对得上这一节在问的事。
每一步写负责人和先后
手册每一行写：步骤名称、必须先完成的前一步、负责的人（写名字，不写整组）、计划开始与结束、做完之后旁人看得到的结果、状态。AWS 切换手册最佳做法 写明，要指明执行任务的个人，而不是整队，才能把责任写清楚；并建议至少开两次走读，邀请任务负责人，最后一次走读放在实际切换前二至三日，以便当场提出最后的阻碍。该页同样没有刊登日期，2026年10月20日阅读。走读的出席和结论写在手册封面，不留在聊天里。
可以平行做的步骤要在手册上标出来，例如备份和准备目标环境可以同时进行，改对外地址则要等数据停下来之后。同一页最佳做法 以缩短停机为由，建议把能平行的任务归在一起，并先标出迁移必须完成的停机时段；若超过这个时段，就对齐一份退回计划。定制软件的停机时段由负责正式环境的人写在手册上，并写明超时由谁宣布改走退回。宣布的人要在关口之前就指名，不要等到当天再找。
可否上线由签核人在关口决定
可否上线的关口放在用户进来之前，不放在已经对外之后。关口上看三样：顺序里标成必须完成的步骤是否都有实际完成时间、退出条件是否达到、签核人是否在手册上签名。微软切换节写的就是按顺序完成、达到退出条件、在可否上线关口取得签核。签核人的名字在走读时写定。人当天不在，由手册上预先写好的代理人签，不在群组里临时改口。
退出条件用验收里已经通过、而且和这次切换有关的那几条，加上这次手册自己的核对，例如正式环境的登录、关键交易走完一笔、旧环境已停止写入。没有在验收里看过的新愿望，不在关口上临时加进退出条件。临时要加，回到变更请求，这次切换维持原手册。关口的结论只写「上线」或「退回」，并写时间和签名。
退回条件事先写在手册上
退回不是切换失败之后才开始设计。手册里单独有一段退回：谁宣布、从哪一步开始、数据以哪一份为准、对外地址改回哪里、做完哪一项核对才通知用户仍用旧环境。AWS 应用迁移流程 写明，应为失败预做准备；迁移若不成功，就执行切换计划里已经写出的退回程序。最佳做法页则把「超过停机时段」写成要对齐退回计划的一种情况。两页都在 2026年10月20日阅读，都没有刊登日期。
定制软件常见的退回触发，写在手册上由负责人预先勾选，例如：技术核对或业务核对没有过、停机时段已过仍不能让用户进来、正式环境写入了无法对回旧环境的数据。触发一出现，按退回表的顺序做，不在当场改顺序。AWS 范本的退回从停止目标端服务开始；若这次上线没有「目标服务器」这一步，退回表改写成这次真正要还原的环境，仍保留负责人、状态和通知。退回做完，在手册末行写实际完成时间和通知了谁。
切完之后核对再通知
切换表的后段是核对，不是宣布完成本身。AWS 范本把切换后的应用测试分成技术核对和业务核对，然后才通知主要利害关系人迁移完成。定制软件沿这个次序：负责正式环境的人先看服务是否起来、关键交易是否走完；预定用户或业务负责人再看一笔真实业务是否和手册写的结果一致。两笔核对都有时间和签名，才发「已经切到正式环境」的通知。通知里写支持由谁接、从什么时候开始。
微软运营支持就绪一节要求：正式环境有监控和维护计划、实施团队把运营支持交给支持团队、支持人员受过训练并有工具和权限、服务台和工单程序已经就位、系统可以进正式环境时通知利害关系人并提供支持联系人。该页把上线后提高支持力度的安排称为 hypercare，并把它列在运营支持与维护计划应包含的项目里。定制项目把这段支持的起迄、负责人和联系方式写在手册最后，不另发明一套时限。来源环境何时停用，等业务核对和健康状况都写进手册之后再定。
手册没写完就留在旧环境
负责人、退回条件、可否上线的签核人，这三样有一样还没写上名字，切换日就继续用旧环境。先补名字和退回表，再改切换日。走读没做、或最后一次走读上仍有未关闭的阻碍，同样不把用户指到新环境。阻碍写在手册的问题记录里，写明谁跟、何时再看。
停机长度、缺陷数和支持时限留在公司自己的规则里，并注明日期。AWS 范本页和微软清单页都没有给定制项目指定这些数字。手册写完之前，用三件事看这次切换有没有准备好：每一步是否有个人负责人和先后、可否上线是否有签核人、退回是否写了触发和顺序。三件事都在手册上，才把切换日写进通知。