There are multiple reasons why the database is not importable, a big factor is the way the K2000 handles deployment identifiers. The K2000 keeps track of scripted installs and images by assigning them an identifier (ID number based on what type of deployment it is). The K2000 database is full of pointers to these identifiers. If you were to export the database and then import it on another K2000 instance (whether it’s the same server or not), the existing identifiers do not change in the database. When you import your image packages, they get assigned an identifier based on the order they are uploaded. If your Student Lab Image has an image id of 11 on your old K2000 instance when you import the image on your new K2000 instance, it will not retain that image id of 11, it will just use the next unused image id number available on the new K2000 instance. If the last used ID number was 33, it would assign an ID of 34.
If IDs do not match, there isn’t any point to leaving the deployment data in there, which for the most part leaves basic setup (assigning hostname, IP address, etc) and linking RSAs/Kboxes. For the vast majority of our customers, this is not time-consuming and can be done relatively quickly. The real use for an exported database is if the database on a K2000 gets corrupted, support can try to import the backed up database, but this situation is not likely to occur.