There are multiple reasons why the database is not importable, a big factor is the way the KSDA handles deployment identifiers. The KSDA keeps track of scripted installs and images by assigning them an identifier (ID number based on what type of deployment it is). The KSDA database is full of pointers to these identifiers. If you were to export the database and then import it on another KSDA 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 KSDA instance when you import the image on your new KSDA instance, it will not retain that image id of 11, it will just use the next unused image id number available on the new KSDA 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 KSDA gets corrupted, support can try to import the backed up database, but this situation is not likely to occur.
