四，nexus-3.14.0升级到3.15.2

nexus内置的一种迁移方式：HTTP下载。也就是，只需要对着nexus点点点，即可实现一劳永逸的搬迁，这个方案，着实令人欣喜。

接下来，不废话，直接进入正题。

1，老私服配置Upgrade:Agent。

如果想实现迁移，首先要配置 Upgrade:Agent ，这个配置比较简单，直接通过截图来展示：

• 1，点击Capabilities。

• 2，New一个新的。

• 3，选择Upgrade: Agent。

• 4，创建一个Access Token，用于远程连接。这里设为123456。

创建之后查看一下：

2，新私服配置连接。

新服安装以及登陆，这且按下不表，可以参考前边的文章，这里直接进入配置环节。

1，点击Capabilities，New一个新的。

2，选择Upgrade。

3，创建。

4，配置链接开始升级。

5，配置老私服地址。

将老私服地址填入，并将刚刚定义的token写入。

就在当我以为一切都是这么愉快欢乐得的时候，问题来了：

说升级时，与版本关系紧密。还给了个建议，说2.14.8版本的好像更容易升级。

ok，既此开始，我陷入了无尽的版本深渊当中，也正是自此开始，我开始关注升级过程中，版本的重要性。

首先我们老私服的版本是2.14.5，这个版本说实话在2.x界是并不低的，而我现在所用的新私服版本是3.12.1的，于是我首先尝试安装了3.1.0的进行升级，发现仍旧会有这样那样的报错。

直到，我在官方文档当中碰到了这么一篇文章：升级兼容性 – Repository Manager 2到3。

就是遇到了这篇救命文章之后，这所有的问题，都不是问题了。

在文档当中有这样一个表格：

从表格当中，我看到了与公司老私服对应版本2.14.5可升级的3.7.1，也看到了如果想直接跳到3.12.1，则需要先将2.14.5升级为2.14.8，然后才能从2.14.8升级到3.12.1。

反正都是个升级，我最终选择了，在另一台测试机器上安装一个3.7.1版本的私服作为临时中转。

于是，安装，登陆，配置，说话间，就来到最关进的认证阶段：

此时此刻，看到绿色的success，不得不说，我眼含泪水，终于等到你。

剩下的就好办了，一路next即可。

不过这里稍微可以配置一下。

Destination：选择我们创建的blob：maven-use。

Method：这里边有三种类型，Hard link(文件系统硬链接)，Filesystem copy（文件系统复制），Download（HTTP下载）。

• 此三种类型区别，可以参考官网介绍：

• 数据传输方法。

此处我们选择默认的，就是我们用的HTTP下载的方式。

识别到了老私服里边的仓库，这里直接全选，吼吼。

万事已毕，只等一声令下：Begin。

历史瞬间，剪影留念。

接着，就可以看到迁移前的体检阶段：

检测已经结束，一共有59622项内容，点击继续即可同步。

看到这个界面，就是成功了：

当同步完成，我们可以在public里边看到这些从老私服同步过来的包。

然后把这个public加入到我们创建的group里边：

然后再将上回书中的项目进行构建，此时发现：

已经可以构建成功了，说明我们做的迁移工作，是生效了的。

当我看到成功的界面是，我止不住激动心情，去找到同事分享这种成就感以及喜悦！

4，两种成功的方式之总结。

上边列举了两种成功的方式，这两种方式的差别还是非常大的，我们来通过一个小小的数据来对比一下：

看了两个sonatype-work大小的对比，就能清晰了解到，在前边我们所担忧的问题，果不其然的在这里出现了，一个8G多，一个800多M，这两者之间的差距，恐怕就是我们需要让新老私服共存的时间差吧，于是乎，最终，我最推荐的方式还是HTTP下载的方式。

如果你想要使用最新版本的私服，那么可以先通过HTTP下载的方式从2.x升级到3.x，然后再直接将对应的sonatype-work复制到最新版本的私服当中，直接启动即可。