1. An increased performance speed and ability.
Currently, our instance of CA is running in a Windows 7 UI. This setup is fine for a test of the system. But in the long run, it's not the most efficient platform for the database. We're moving the backend to live in a Windows Server environment instead.
2. Safety and security.
In my mind, I can't begin to understand why anyone would want to try to hack into a historic properties database. But it's not as silly as it might seem. In fact, the point of breaking into a site like this would be to gain a foothold. So if our front end was directly connected to the backend, and the backend to the network, then anyone ramming into our database would simply find themselves with a nice place to rest and think about where to move laterally from there. So really, it's just a best practice to separate out the front and back ends.
I'll be working on this new setup in November. At the moment, our plan is to have SCHPR launched in January 2016. At this point, we have 16870 objects with associated metadata in SCHPR; this includes historic properties, historic resource surveys, and national register listings. We have about 50 digitized items associated with historic properties also in SCHPR. Going forward, the goal is to finish uploading all of our born-digital metadata -- historic property information in Access -- and begin data entry from and digitization of legacy data -- historic property site cards in the archives. We'll also work on a batch media upload of digitized national register files. All that said, when SCHPR does go live in January, it will have plenty of material already present. We'll just be working on bulking it up even more.
I'll keep you posted!