Indices disappear after database migration

If you deactivate/activate the plugin it will check for the indices and create them if needed. That will very likely solve the issue.

If not, then you can try this:
– Deactivate the plugin
– Delete the wp_asp_index database table
– Activate the plugin again
– Reindex the contents
This process should create the index table from scratch, and will include the fresh indexes.

Oh wait, I thought you meant the actual table indexes on the database level were not transfered to the new database.

If it took you 12 hours, that could mean that the counting process simply fails and reports back 0. In MySQL/MariaDB databases counting large number of rows can timeout very easily – it is a known flaw. You probably have multi million rows and that explains it.

Your data is very likely completely fine if you migrated, the counter is only reporting the incorrect numbers.

That could indicate a database related issue then. Just to be sure, check if the index table is indeed enabled.

I strongly suggest running a database repair and table optimize queries on the whole database to make sure the data was correctly imported and it’s not fragmented. 15 million rows is a lot, but not tragic. Fragmentation can cause a huge memory issue with the actual table index structure on the database level.
I would also suggest looking at the server memory and space usage, just to make sure it has enough resources.

By 15 million rows I meant the index table size.

Okay, this sounds like a serious issue with the actual database, I suspect fragmentation or data corruption. I strongly recommend doing table repair commands, checking the memory usage and the available space for the database.

It might be the best to completely delete the wp_asp_index table, deactivate and re-activate the plugin so it is recreated automatically, then doing a full database repair, as well as optimize table commands on all of the database tables. Those are crucial. There is no other reason for the plugin not to work on this server, if it worked just fine on the other – unless there is an underlying issue on the database/server layer.

Nothing will happen if you hibarnate, you can click continue and that’s it.

1600 items in 10 hours? There is something very wrong with the database there. I just tested a single core virtual machine with 512MB of ram with 50 000 items, and it indexed in like 45 minutes and almost 0 CPU load, that should be a piece of cake for that machine.
The server specification is definitely all right, that is a super high specification for such small amount of data.

Do you have any strong data replication or data restoration service running on that server? I mean a service which lets you roll back to any point in time on your database?
That could explain the problem, as it has to store a a lot of redundant data before every single database row insertion. The plugin tries to insert thousands of rows and the server might be trying to remember and log all of the changes and it basically kills the CPU.