Hello, Narasimha
For a proper migration, just moving the indices wouldn't be good, as the index files themselves can be different from a version to another. What you need to do is migrating the index contents, thus generating new indices with the same information. This can be done in a number of ways.
Probably, the simplest option in your case will be to generate the new indices not from your old indices, but from the alert log files. This will work if you still have all the alert logs under /var/ossec/logs/alerts for the length of time that you're interested in migrating. To do this, you'd first copy all logs under that path to the new server and then follow the procedure described here:
This involves setting up a script that will process all your alert logs and produce new indices with them. The process may take some time, so you'll be using nohup to allow your user to log out while the process keeps running. This script allows you to specify the start and finish dates, so you can do it in parts if you prefer. With this method, though, the new index files will have current dates. This will not affect the alert time stamps, but you may want to take it into account if you are using an index retention policy.
If you want to migrate the information directly from your indices, be it because you don't have the old alert logs or for any other reason, you can follow this guide:
With this, you'd be creating a snapshot from your old indices to a shared file system. Then, you'd be restoring this snapshot into your new indices. This has the advantage that your index files will retain their original time stamp. The choice of using a shared file system does not represent the only option in this case, as you could be using a cloud snapshot in an S3 bucket just as well. In any case, this process can take some time as well, so make sure you can allow your server that time to process the indices.
Hope this is of good use to you. Regards,
Lucas