运营数据迁移方法、装置、设备及存储介质

技术领域

本申请涉及数据迁移技术领域，具体而言，涉及一种运营数据迁移方法、装置、设备及存储介质。

背景技术

目前代理游戏行业里，有时接管一款游戏或服务的运营，需要从原来的运营商手上接收原有老用户的数据(以下简称数据迁移)，以保证在变更运营商后，老用户仍然能够在原先数据的基础上，不间断地继续使用。

现有技术中，一般通过迁移数据库的方式实现用户的转移，例如将第一运营商对应的数据库中的用户信息迁移至新运营商对应的数据库中，以实现游戏或服务的运营接管。

在数据迁移过程中，由于运营商发生变更，因此可能会出现用户数据异常，继而影响用户正常使用的问题。

发明内容

本申请的目的在于，针对上述现有技术中的不足，提供一种运营数据迁移方法、装置、设备及存储介质，以解决现有技术中在数据迁移过程中，由于运营商发生变更，出现用户数据异常，继而影响用户正常使用的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种运营数据迁移方法，所述方法包括：

获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息；

根据所述令牌信息，从所述第一运营商的服务器获取所述待迁移用户的运营数据信息；

通过用于登录第二运营商的服务器的网页获取所述待迁移用户的第二账号信息；

建立所述第一账号信息和所述第二账号信息的对应关系；其中，所述对应关系用于所述第二运营商的服务器根据所述第二账号信息查找所述第一账号信息，并采用所述第一账号信息获取所述运营数据信息。

可选地，所述获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息，包括：

接收所述第一运营商的服务器发送的绑定查询消息；所述绑定查询消息包括：所述待迁移用户的第一账号信息；

查询所述第一账号信息是否在所述第二运营商的服务器中被绑定；

向所述第一运营商的服务器发送绑定查询结果，使得所述第一运营商的服务器在所述查询结果为未绑定时向用户推送迁移公告，其中，所述绑定查询结果用于指示所述第一账号信息是否在所述第二运营商的服务器中被绑定，所述迁移公告用于提示用户是否进行数据迁移；

接收所述第一运营商的服务器发送的所述令牌信息，所述令牌信息为所述第一运营商的服务器在接收到用户的迁移确认操作之后生成的信息。

可选地，所述通过用于登录第二运营商的服务器的网页获取所述待迁移用户的第二账号信息，包括：

对登陆信息进行校验；其中，所述登陆信息为通过用于登录第二运营商的服务器的网页获取的；

若校验通过，则根据所述登陆信息获取所述第二账号信息。

可选地，所述建立所述第一账号信息和所述第二账号信息的对应关系，包括：

对所述待迁移用户的第一账号信息和所述第二账号信息进行校验，并在校验通过后，建立所述对应关系。

可选地，所述向所述第一运营商的服务器发送绑定查询结果之后，还包括：

若所述绑定查询结果为所述待迁移用户的第一账号信息在所述第二运营商的服务器中已被绑定，则通过所述网页显示绑定失败的指示信息。

可选地，所述建立所述第一账号信息和所述第二账号信息的对应关系之后，所述方法还包括：

将所述对应关系写入预设存储系统中。

可选地，所述建立所述第一账号信息和所述第二账号信息的对应关系之后，所述方法还包括：

向所述第一运营商的服务器发送绑定成功的指示信息，并通过所述网页上显示所述绑定成功的指示信息。

第二方面，本申请另一实施例提供了一种运营数据迁移装置，所述装置包括：获取模块和建立模块，其中：

所述获取模块，用于获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息；根据所述令牌信息，从所述第一运营商的服务器获取所述待迁移用户的运营数据信息；通过用于登录第二运营商的服务器的网页获取所述待迁移用户的第二账号信息；

所述建立模块，用于建立所述第一账号信息和所述第二账号信息的对应关系；其中，所述对应关系用于所述第二运营商的服务器根据所述第二账号信息查找所述第一账号信息，并采用所述第一账号信息获取所述运营数据信息。

可选地，所述装置还包括：接收模块、查询模块和发送模块，其中：

所述接收模块，用于接收所述第一运营商的服务器发送的绑定查询消息；所述绑定查询消息包括：所述待迁移用户的第一账号信息；

所述查询模块，用于查询所述第一账号信息是否在所述第二运营商的服务器中被绑定；

所述发送模块，用于向所述第一运营商的服务器发送绑定查询结果，使得所述第一运营商的服务器在所述查询结果为未绑定时向用户推送迁移公告，其中，所述绑定查询结果用于指示所述第一账号信息是否在所述第二运营商的服务器中被绑定，所述迁移公告用于提示用户是否进行数据迁移；

所述接收模块，具体用于接收所述第一运营商的服务器发送的所述令牌信息，所述令牌信息为所述第一运营商的服务器在接收到用户的迁移确认操作之后生成的信息。

可选地，所述装置还包括：校验模块，用于对登陆信息进行校验；其中，所述登陆信息为通过用于登录第二运营商的服务器的网页获取的；

所述获取模块，具体用于若校验通过，则根据所述登陆信息获取所述第二账号信息。

可选地，所述建立模块，具体用于对所述待迁移用户的第一账号信息和所述第二账号信息进行校验，并在校验通过后，建立所述对应关系。

可选地，所述装置还包括：显示模块，用于若所述绑定查询结果为所述待迁移用户的第一账号信息在所述第二运营商的服务器中已被绑定，则通过所述网页显示绑定失败的指示信息。

可选地，所述装置还包括：写入模块，用于将所述对应关系写入预设存储系统中。

可选地，所述显示模块，具体用于向所述第一运营商的服务器发送绑定成功的指示信息，并通过所述网页上显示所述绑定成功的指示信息。

第三方面，本申请另一实施例提供了一种运营数据迁移设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当运营数据迁移设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如上述第一方面任一所述方法的步骤。

第四方面，本申请另一实施例提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如上述第一方面任一所述方法的步骤。

本申请的有益效果是：采用本申请提供的运营数据迁移方法，在获取到第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息后，可以根据令牌信息从第一运营商的服务器获取待迁移用户的运营数据信息，随后通过用于登陆第二运营商的服务器的网页获取待迁移用户的第二账号信息，并建立待迁移用户的第一账号信息和第二账号信息之间的对应关系，其中，对应关系用于第二运营商的服务器可以根据第二账号信息查找对应的第一账号信息，并采用第一账号信息获取运营数据信息，这样的设置方式使得用户在获取到运营数据信息后，通过用于登陆第二运营商的服务器获取第二账号信息，即可建立第一账号信息和第二账号信息的对应关系，从而实现根据第二账号信息和对应关系即可获取待迁移用户的运营数据信息，从而完成用户的迁移，避免运营商发生变更，造成影响用户正常使用的问题。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的运营数据迁移方法的流程示意图；

图2为本申请另一实施例提供的运营数据迁移方法的流程示意图；

图3为本申请另一实施例提供的运营数据迁移方法的流程示意图；

图4为本申请另一实施例提供的运营数据迁移方法的流程示意图；

图5为本申请另一实施例提供的运营数据迁移方法的流程示意图；

图6为本申请另一实施例提供的运营数据迁移方法的流程示意图；

图7为本申请一实施例提供的运营数据迁移装置的结构示意图；

图8为本申请另一实施例提供的运营数据迁移装置的结构示意图；

图9为本申请一实施例提供的运营数据迁移设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

另外，本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

需要指出的是，本申请所涉及的数据迁移可以为预设应用在运营接管的过程中，将第一运营商的服务器中针对该预设应用的运营数据迁移至第二运营商的服务器中，其中，第一运营商的服务器又称旧运营商(Old Operator)的服务器，第二运营商的服务器又称新运营商(New Operator)的服务器。该预设应用的运营数据例如可包括：该预设应用的用户数据，例如可以为游戏应用的玩家数据。通过执行第一运营商的服务器的运营数据至第二运营商的服务器，又称新旧运营商服务器的迁移，可实现将预设应用由第一运营商的服务器迁移至第二运营商的服务器接管。

例如，预设应用可以为预设游戏应用，此时该第一运营商的服务器即为旧游戏运营商(Old Game Operator，OGO)服务器，该第二运营商的服务器即为新游戏运营商(NewGame Operator，NGO)服务器，如此通过执行下述数据迁移方法便可实现游戏应用中运营数据的迁移，游戏应用中的运营数据例如可以包括：该游戏应用的游戏玩家数据。

应当理解该预设应用还可以为预设音乐应用、影音应用、社交应用，又或者电商应用等任一类似的应用，具体预设应用的类型可以根据用户需要灵活调整，并不以上述实施例给出的为限，如此通过执行下述数据迁移方法便可实现预设应用中的运营数据的迁移。

本申请的数据迁移方法，所应用的具体应用的类型，以及具体运营数据的类型本申请在此不作任何限制，可以根据用户需要灵活调整，只需涉及新旧运营商服务器的迁移即可，不以上述实施例给出的为限。

如下结合多个具体的应用示例，对本申请实施例所提供的一种运营数据迁移方法进行解释说明。图1为本申请一实施例提供的一种运营数据迁移方法的流程示意图，该运营数据迁移方法可由第二运营商的服务器，也就是新运营商的服务器执行。如图1所示，该方法包括：

S101：获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息。

可选地，令牌信息的设置可以避免数据传输过程中的数据安全问题，数据安全问题例如可以为：用户身份被冒用或盗用等；令牌信息例如可以为token，是一个不重复的随机字符串。在本申请的一个实施例中，每个用户均对应一个唯一的令牌信息，不同用户之间对应的令牌信息不相同，第二运营商的服务器获取第一运营商的服务器发送的待迁移用户的第一账号信息，例如可以为：用户的身份标识信息(user_id)。应当理解具体用户的第一账号信息和令牌信息的信息内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

可选地，在本申请的一个实施例中，令牌信息是第一运营商的服务器在检测到用户登陆成功后，将令牌信息和该用户对应的第一账号信息写入第二运营商的服务器提供的接口，该过程是两个运营商的服务器之间的交互，会互相增加访问白名单以及加密验证，从而保证数据传输过程中的可靠性和安全性。

S102：根据令牌信息，从第一运营商的服务器获取待迁移用户的运营数据信息。

可选地，在本申请的一个实施例中，运营数据信息例如可以为：用户账号信息(例如可以为：用户注册时对应的手机号信息、或邮箱信息、身份证信息，或其他信息等)，昵称信息、登录平台信息(例如可以为：登录系统信息，和/或登录服务区信息等)，具体运营数据信息包括的内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

例如，第二运营商的服务器可向第一运营商的服务器发送信息协议获取请求，该信息协议请求包括：该令牌信息，并接收该第一运营商的服务器返回的运营数据信息。该运营数据信息例如可以为该第一运营商的服务器基于该令牌信息，查询的该令牌信息对应的待迁移用户的运营数据信息。

S103：通过用于登录第二运营商的服务器的网页获取待迁移用户的第二账号信息。

可选地，在本申请的一个实施例中，仍以第一账号信息为user_id为例进行说明，由于user_id一般是根据用户注册的时间，自动生成的自增值，为了保证第二运营商的服务器中各迁移用户和新用户之间互不影响，即避免新用户的第一账号信息和迁移用户的第一账号信息之间发生冲突，导致数据混淆影响游戏异常的问题，可以在第一运营商的服务器和第二运营商的服务器进行数据迁移前，确定第一运营商的服务器中迁移数据对应的最大标识值，在该最大标识值的基础上，隔开一个较大的值，从而让新用户对应的标识值从该值往后自增；或者针对某些ID，例如可以为日志表对应的自增ID，由于这些ID不会被其他表引用到，所以这些ID数值改变不会带来任何的影响，因此对于这些没有意义的自增user_id，可以在数据迁移导入脚本的过程中，将这些值忽略，但这些值写入数据表时也保持自增；这样的设置方式使得数据之间具有隔离性，就可以保证第二运营商的服务器中的迁移用户和新用户之间互不影响。

S104：建立第一账号信息和第二账号信息的对应关系。

其中，对应关系用于第二运营商的服务器根据第二账号信息查找第一账号信息，并采用第一账号信息获取运营数据信息。

示例地，建立对应关系后，只是实现了第一账号信息和第二账号信息之间绑定关系的登记，此时不会有实际上的数据迁移，在一些可能的实施例中，例如可以在第一运营商的服务器对登记的绑定关系进行确认，并确认绑定关系无误后，以预设形式将待迁移用户的运营数据信息发送至第二运营商的服务器，从而完成运营数据信息的交付；其中，预设形式例如可以为：数据表等形式，本申请在此不做任何限制，具体数据迁移的方式和过程可以根据用户需要灵活调整，本申请在此不做任何限制。

采用本申请提供的运营数据迁移方法，在获取到第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息后，可以根据令牌信息从第一运营商的服务器获取待迁移用户的运营数据信息，随后通过用于登陆第二运营商的服务器的网页获取待迁移用户的第二账号信息，并建立待迁移用户的第一账号信息和第二账号信息之间的对应关系，其中，对应关系用于第二运营商的服务器可以根据第二账号信息查找对应的第一账号信息，并采用第一账号信息获取运营数据信息，这样的设置方式使得用户在获取到运营数据信息后，通过用于登陆第二运营商的服务器获取第二账号信息，即可建立第一账号信息和第二账号信息的对应关系，从而实现根据第二账号信息和对应关系即可获取待迁移用户的运营数据信息，从而完成用户的迁移，避免运营商发生变更，造成影响用户正常使用的问题。

可选地，在上述实施例的基础上，本申请实施例还可提供一种运营数据迁移方法，如下结合附图对上述方法中获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息的实现过程进行示例说明。图2为本申请另一实施例提供的一种运营数据迁移方法的流程示意图，如图2所示，S101可包括：

S105：接收第一运营商的服务器发送的绑定查询消息。

绑定查询消息包括：待迁移用户的第一账号信息。

S106：查询第一账号信息是否在第二运营商的服务器中被绑定。

其中，由于后续的数据迁移是一对一的，因此为保证用户的使用体验和使用安全性，每个用户的第一账号信息只可被绑定一次，不能重复绑定，并且绑定成功后也不可更改绑定，因此需要对用户的第一账号信息是否被绑定进行查询和验证，只有待迁移用户的第一账号信息未被绑定的情况下，才可以进行后续的数据迁移。

S107：向第一运营商的服务器发送绑定查询结果，使得第一运营商的服务器在查询结果为未绑定时向用户推送迁移公告。

其中，绑定查询结果用于指示第一账号信息是否在第二运营商的服务器中被绑定，在未被绑定时，向用户推送迁移公告；迁移公告用于提示用户是否进行数据迁移；迁移公告上例如可以包括：迁移时间、迁移内容、用户补偿内容等，具体迁移公告具体包括的内容可以根据用户需要灵活调整，本申请在此不做任何限制。

其中，查询用户的第一账号信息是否在第二运营商的服务器中被绑定，可以防止用户的第一账号信息重复绑定，影响用户的正常使用等问题。

S108：接收第一运营商的服务器发送的令牌信息。

其中，令牌信息为第一运营商的服务器在接收到用户的迁移确认操作之后生成的信息。

其中，由于数据迁移不止是两个运营商的服务器之间的数据交互，还需要用户的参与，因此数据迁移需要先经过用户的同意，只有在用户同意迁移触发迁移确认操作后，才会进行后续的数据绑定等步骤，若用户不同意迁移，则不会进行后续的数据绑定步骤，因此需要先接收到用户的迁移确认操作，再进行后续的步骤，否则向用户返回提示信息，例如返回迁移公告信息等。

可选地，在上述实施例的基础上，本申请实施例还可提供一种运营数据迁移方法，如下结合附图对上述方法中控制应用客户端跳转至第二运营商的登陆网页的实现过程进行示例说明。图3为本申请另一实施例提供的一种运营数据迁移方法的流程示意图，如图3所示，S103可包括：

S109：对登陆信息进行校验。

其中，登陆信息为通过用于登录第二运营商的服务器的网页获取的。

可选地，在本申请的一个实施例中，登录信息可以由第二运营商的服务器进行校验；在本申请的另一实施例中，登录信息也可由第一运营商的服务器向第二运营商的登录服务器发送，以使得第二运营商的登录服务器对该登录信息进行校验，从而实现登录信息的远程校验，具体第二运营商包括一个服务器还是多个服务器可以根据用户需要灵活调整，并不以上述实施例给出的为限。

其中，由于第一运营商的服务器和第二运营商的服务器之间是相互独立的，不能通过时域session来获取信息，因此在本申请的实施例中，均通过网页链接参数的传递来获取并确认用户身份。示例的，在具体实现过程中，可由第二运营商的服务器在获取到运营数据后，将网页链接参数修改为该第二运营商的登录网页，该登陆网页用于登陆第二运营商的服务器，如此，就可以实现基于该网页链接参数，通过用于登陆第二运营商的服务器的网页获取登陆信息。

其中，登录信息例如可以为用户通过在登录网页上输入账号密码的方式输入的登录信息，或通过指纹输入的登录信息，或通过音频输入的登录信息，或通过人脸识别输入的登录信息，具体登录信息包括的内容和登录方式，可以根据用户需要灵活调整，并不以上述实施例给出的为限。

若校验通过，则执行S110。

S110：根据登陆信息获取第二账号信息。

示例地，在一些可能的实施例中，在根据登陆信息获取第二账号信息之前，还需要查询该登录信息是否在第二运营商的服务器中被注册；即该登陆信息是否在建立对应关系之前，就已经在第二运营商的服务器中被注册，若查询得到该登录信息已被注册，则返回绑定失败；若查询得到该登录信息未被注册，则根据登录信息获取第二账号信息。

举例说明：若查询得到登陆信息在建立对应关系之间，就已经在第二运营商的服务器中登录并注册了其他角色信息，则当前登录信息对应的第二账号信息无法与第一账号信息建立对应关系，则说明此时待迁移用户的登陆信息未通过校验，无法与第一运营商的服务器中的第一账号信息进行绑定。

可选地，在本申请的一个实施例中，若校验未通过，则通过网页显示绑定失败的指示信息，指示信息中例如可以包括未通过类型和提示，用于提示用户选择其他的账号信息进行绑定，提示方式例如可以为：若登陆信息已在第二运营商的服务器中注册过，则第二运营商的服务器通过网页显示指示信息，提示当前登陆信息已被注册，不能重复绑定或不能更改绑定等指示信息，并指示用户选择其他登陆信息进行绑定。

可选地，第二账号信息中例如可包括：第二账号信息，以及该待迁移用户的登录互联网协议(IP)等信息。

示例地，在一些可能的实施例中，例如可以为根据预设的账号信息获取接口，根据登陆信息，通过预设的账号信息获取接口，获取该登录信息唯一对应的第二账号信息，第二账号信息例如可以为登录信息在第二运营商的服务器中唯一对应的用户身份第二账号信息，具体获取第二账号信息的方式和第二账号信息包括的内容可以根据用户需要灵活调整，本申请在此不做任何限制。

可选地，在上述实施例的基础上，本申请实施例还可提供一种运营数据迁移方法，如下结合附图对上述方法中建立待迁移用户的第一账号信息和第二账号信息的对应关系的实现过程进行示例说明。图4为本申请另一实施例提供的一种运营数据迁移方法的流程示意图，如图4所示，S104可包括：

S111：对待迁移用户的第一账号信息和第二账号信息进行校验，并在校验通过后，建立对应关系。

其中，待迁移用户的第一账号信息和第二账号信息建立对应关系后，实现了第一运营商的服务器和第二运营商的服务器之间用户的一对一绑定关系。

示例地，在一些可能的实施例中，对待迁移用户的第一账号信息和第二账号信息进行校验的方式例如可以为：查询待迁移用户的第一账号信息是否在第二运营商的服务器中已绑定；若已绑定，则返回绑定失败指示，若未绑定过，则确定待迁移用户的第一账号信息和第二账号信息校验通过。

举例说明：若第一账号信息在第二运营商的服务器中，已经与不是第二账号信息的其他账号信息进行了绑定，则当前第一账号信息对应的账号信息与第二账号信息不匹配，则说明此时待迁移用户的第一账号信息未通过校验。

可选地，在本申请的一个实施例中，若校验未通过，则通过网页显示绑定失败的指示信息，其中，指示信息中例如可以包括未通过类型和提示，用于提示用户选择其他的账号信息进行绑定，提示方式例如可以为：若待迁移用户的第一账号信息已在第二运营商的服务器中与其他账号信息绑定过，则第二运营商的服务器可以通过网页显示指示信息，例如“当前用户已绑定”或“无法更改绑定账户”等提示；具体返回内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

可选地，在上述实施例的基础上，本申请实施例还可提供一种运营数据迁移方法，如下结合附图对上述方法的实现过程进行示例说明。图5为本申请另一实施例提供的一种运营数据迁移方法的流程示意图，如图5所示，S104之后，该方法可包括：

S112：将对应关系写入预设的存储系统中。

示例地，在本申请的一个实施例中，例如可以将对应关系写入第二运营商的服务器对应的存储系统中，该存储系统例如可以为预设的数据库，如关系型数据库管理系统MySQL，应当理解具体存储系统的数据库类型可以根据用户需要灵活调整，并不以上述实施例给出的为限。

可选地，在上述实施例的基础上，本申请实施例还可提供一种运营数据迁移方法，如下结合附图对上述方法的实现过程进行示例说明。图6为本申请另一实施例提供的一种运营数据迁移方法的流程示意图，如图6所示，S104之后，该方法可包括：

S113：向第一运营商的服务器发送绑定成功的指示信息，并通过网页上显示绑定成功的指示信息。

可选地，在本申请的另一实施例中，还可在绑定成功后向第一运营商的服务器发送绑定成功指示信息，用于提示用户当前绑定已完成。

举例说明：在本申请的一个实施例中，例如第二运营商的服务器可以根据第一运营商的服务器提供的预设返回接口，返回绑定成功指示信息至第一运营商的服务器，绑定成功指示信息的返回方式例如可以为：通过应用内邮件的形式返回，或弹窗的形式返回，具体返回方式和返回内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

示例地，在一些可能的实施例中，为了避免第一运营商的服务器提供的数据不完整，导致第二运营商的服务器无法保证用户体验的问题，可以让第一运营商的服务器在数据迁移前，提供测试数据和对应的导出数据的脚本，以便第二运营商的服务器进行全方位的回归测试，若发现数据不完整导致测试有问题，可以及时与第一运营商的服务器进行沟通，持续迭代优化导出的脚本，从而保证第二运营商的服务器在接手后，仍可保证用户的正常使用，保证用户体验。

示例地，在其他一些可能的实施例中，为了避免第一运营商的服务器和第二运营商的服务器环境之间的差异，可以使用应用容器引擎，来间接保证各服务器环境的一致，例如可以为：第一运营商的服务器操作系统是centos，而第二运营商的服务器操作系统是debian，则可以在debian操作系统上用docker新建centos的容器来提供服务，从而避免无法保证服务器环境一致的问题。

可选地，在本申请的另一实施例中，为了避免在数据迁移过程中，数据结构的变更导致迁入数据时第二运营商的服务器对迁入数据进行报错，或者字段错乱的问题。对于一些必要的数据结构变更，可以使用数据库版本迁移工具，例如可以为：flyway)，来记录管理数据的变更记录，防止遗漏。然后可以依次对这些变更，在导入脚本里根据实际需求进行赋值。需要说明的是，每次记录被修改后，都需要进行回归测试。

示例地，在一些可能的实施例中，对于某些不能迁移的依赖性数据，例如应用信息为游戏时，除了游戏玩家对应的自身数据外，可能会用到其他游戏玩家的数据或一些公用数据，这些数据即为依赖性数据，例如可以为：游戏玩家的帮派数据或联盟数据；由于想要获取游戏玩家的联盟信息，需要依赖于联盟数据，但是联盟数据是不可迁移的；或需要获取游戏玩家的好友信息时，需要依赖于好友的数据，但是游戏玩家对应的好友数据不一定会迁移至第二运营商平台；缺少依赖性数据不会影响用户的正常使用，但可能会导致用户有一定程度的损失；虽然每个应用对应的依赖性数据不同，但是不同用户对应的依赖性数据大致是一样的，所以为保证用户利益，可以以用户为单位来编写和导出脚本，由于用户数据存储在数据库中，通常会根据其第一账号信息来进行关联或间接关联，所以一般通过传入用户的第一账号信息来导出用户对应的数据，为了解决依赖性数据不能迁移，可能会造成用户损失的问题，在本申请的一个实施例中，可以预先对用户的损失程度进行评估，并根据评估结果进行相应的补偿。这个过程是需要进行不断地调试迭代，导出再导入测试，直至将一个用户数据调整合适后，再尝试批量地导出-导入-测试-完善。

采用本申请提供的数据迁移方法，在获取到第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息后，可以根据令牌信息从第一运营商的服务器获取待迁移用户的运营数据信息，随后通过用于登陆第二运营商的服务器的网页获取待迁移用户的第二账号信息，并建立待迁移用户的第一账号信息和第二账号信息之间的对应关系，其中，对应关系用于第二运营商的服务器从第一运营商的服务中获取待迁移用户的运营数据信息，从而完成第一账号信息和第二账号信息之间的一一绑定，并根据绑定关系获取待迁移用户的运营数据，从而实现第一运营商的服务器中的运营数据信息迁移至第二运营商的服务器中。

下述结合附图对本申请所提供的运营数据迁移装置进行解释说明，该运营数据迁移装置可执行上述图1-图6任一运营数据迁移方法，其具体实现以及有益效果参照上述，如下不再赘述。

图7为本申请一实施例提供的运营数据迁移装置的结构示意图，如图7所示，该装置包括：获取模块201和建立模块202，其中：

获取模块201，用于获取第一运营商的服务器发送的待迁移用户的第一账号信息和令牌信息；根据令牌信息，从第一运营商的服务器获取待迁移用户的运营数据信息；通过用于登录第二运营商的服务器的网页获取待迁移用户的第二账号信息。

建立模块202，用于建立第一账号信息和第二账号信息的对应关系；其中，对应关系用于第二运营商的服务器根据第二账号信息查找第一账号信息，并采用第一账号信息获取运营数据信息。

图8为本申请另一实施例提供的运营数据迁移装置的结构示意图，如图8所示，该装置还包括：接收模块203、查询模块204和发送模块205，其中：

接收模块203，用于接收第一运营商的服务器发送的绑定查询消息；绑定查询消息包括：待迁移用户的第一账号信息。

查询模块204，用于查询第一账号信息是否在第二运营商的服务器中被绑定。

发送模块205，用于向第一运营商的服务器发送绑定查询结果，使得第一运营商的服务器在查询结果为未绑定时向用户推送迁移公告，其中，绑定查询结果用于指示第一账号信息是否在第二运营商的服务器中被绑定，迁移公告用于提示用户是否进行数据迁移。

接收模块203，具体用于接收第一运营商的服务器发送的令牌信息，令牌信息为第一运营商的服务器在接收到用户的迁移确认操作之后生成的信息。

图8所示，该装置还包括：校验模块206，用于对登陆信息进行校验；其中，登陆信息为通过用于登录第二运营商的服务器的网页获取的；

获取模块201，具体用于若校验通过，则根据登陆信息获取第二账号信息。

可选地，建立模块202，具体用于对待迁移用户的第一账号信息和第二账号信息进行校验，并在校验通过后，建立对应关系。

图8所示，该装置还包括：显示模块207，用于若绑定查询结果为待迁移用户的第一账号信息在第二运营商的服务器中已被绑定，则通过网页显示绑定失败的指示信息。

图8所示，该装置还包括：写入模块208，用于将对应关系写入预设存储系统中。

可选地，显示模块207，具体用于向第一运营商的服务器发送绑定成功的指示信息，并通过网页上显示绑定成功的指示信息。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital singnal processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(CentralProcessing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

图9为本申请一实施例提供的运营数据迁移设备的结构示意图，该运营数据迁移设备可以集成于服务器或者服务器的芯片。该服务器可以为预设应用的第二运营商的服务器，即新运营商服务器。

如图9所示，该运营数据迁移设备包括：处理器501、存储介质502和总线503。

处理器501用于存储程序，处理器501调用存储介质502存储的程序，以执行上述图1-图6对应的方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种程序产品，例如存储介质，该存储介质上存储有计算机程序，包括程序，该程序在被处理器运行时执行上述方法对应的实施例。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。