![]() |
![]() |
[ Bottom of Page | Previous Page | Next Page | Contents ]
Now that you have an overview of the migration process, you can see that it is quite complex and time consuming, and requires the implementation of a detailed plan. There are also choices that you might want to make about your new environment that might result in having to waste migrated data. And finally, you may be using V1.1.1 in such a way that the maintenance of data between V1.1.1 and V2.1 is not very important to you. Is there an alternative?
The only alternative to migrating is starting afresh. In this case you would ignore the existence of your previous version and implement V2.1 servers and databases on new computers, redeploying all agents to version 2.1. This scenario has these disadvantages:
It should be noted that you cannot make a fresh installation of the administration server and database, and then register V1.1.1 runtime servers with it. V1.1.1 runtime servers are only compatible with a migrated administration server database. Similarly, although a V2.1 administration server and runtime server can continue to support existing V1.1.1 agents that are on platforms not supported in V2.1, such agents cannot be deployed on V2.1 (see Component compatibility).
[ Top of Page | Previous Page | Next Page | Contents ]