如果是硬迁移，那就没什么说的了，相当于原来的不要了，搞得新的。如果想尽量保留原来的搜索引擎收录和外部链接可用性，有以下方法可以考虑。
例如，doku / vuepress / wiki.js 三者，url的定义都是自由的，甚至可以直接把 vuepress 的源文件目录拷贝到 wiki.js 的 git 仓库（当然内容格式需要微调）。
这种情况下，理论上可以做到等位替换，以往的链接都还可以打开，核心内容也没什么变化，这就可以视作无缝迁移了。
如果做不到等位替换，并且改变了网址，原来的网址至少继续维护一段时间，在每一个页面上放上指向新站的链接和迁移说明。
如果新旧网址之间的 uri 是等位替换那就简单了，直接在 web 服务上做一个 301 永久跳转，注意在跳转时保持 uri 不变，这样粗心的用户甚至可能注意不到自己点进来的网址不是搜索引擎显示的那个网址，搜索引擎也很快会（一两个月？对于搜索引擎挺快的了）更新链接。
上面一切考虑其实都是为了避免 404，但如果真的除了404其实也能利用。例如，使用caddy反向代理，在新旧迁移期间，把 404 的请求自动 302 跳转到已经移动了的旧站，而如果新站已经存在某个页面，则不进行跳转：
www.weiran.ink {
tls xxx.com
encode gzip zstd
import log blog_wiki_weiran_ink
reverse_proxy localhost:66666 {
# 匹配上游返回 404 的响应
@not_found {
status 404
}
# 当匹配到 404 时，跳转到旧网站对应路径
handle_response @not_found {
redir "https://old_temp.weiran.ink{uri}" temporary
}
}
}
如果站点自身不好进行 404 自定义，这里还可以实现检测到 404 就跳转到已经设计好了的迁移说明页面，例如这样的。
关键就是写在reverse_proxy字段内部的那个选择器以及handle_response.