The RAID configuration information is stored on the controller and on the drives.  Any time the configurations do not match, the controller wants you to decide which one it should use.  You always want to use the configuration on the drives in this case.   (The RAID battery keeps cache data alive on the RAID memory - it does not store configuration data for the array; configuration data is stored in non-volatile RAM on the controller itself - not the cache DIMM.)   Whether you put the drives into this system or another, the process will be the same - you will need to view the config first (View/Add - if there are multiple configurations (NVRAM / Disk), it will ask which you want to see).  Once you like what you see, you then save the config on exit.  Either way, it won't affect anything on the drives.  All we are dealing with here is telling the controller which config to use.   It is possible that once you switch to RAID  and accept the scary message, that the controller will recognize and accept the configuration automatically and everything will be fine.  BUT if you see a message about a mismatch, you will need to save the Disk config in View/Add.
Recently got a call whereby a company went to access a (rarely used) server and couldn't access it.  The server was offline and wouldn't boot.  They replaced both power supplies and got it past post but it's not recognizing the RAID configuration.  Here's the details: Given that they know nothing about what the configuration is supposed to be I think the best place to start is to try and determine what the configuration was.  Is there a tool that anyone is aware of that can help analyze this based on reading the drive headers and/or information from the on-board RAID? If I switch the BIOS to RAID mode will it really destroy data on the drives or will it use the existing header data to recognize the existing RAID configuration? Any other ideas/input? Thanks, Chris      
Lost RAID configuration