Got some coding #realtalk for you on these lines of code.
1. The framework's ConfigurationManager isn't a great way to handle application configuration because it's painful to deal with. For Black Mesa, I've got a Mongo database set up for [Configuration](https://github.com/hudl/black-mesa/blob/AddWebApp/WebApp/WebApp/Models/Configuration.cs). (If you do use the framework-provided config, check out project [Settings](http://msdn.microsoft.com/en-us/library/aa730869\(v=vs.80\).aspx). The ConnectionStrings component of the configuration should only be used for connection strings, though, not any old thing. We only use it to connect to the Mongo database.)
2. I'd encourage you to practice the [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself) principle in development. Sure, it's easy to duplicate a line, change a few characters and move on, but maintenance is a real pain and in this case you're paying a performance penalty by calling the same methods repeatedly and unnecessarily.
3. Comma-delimited settings are probably not a great idea. You don't know the type, the order, or if it even exists. For instance, what happens if we prepend "ids," to each setting? The indexes are now all incorrect. If there isn't a comma in there for whatever reason, we'll get an OutOfBoundsException when it tries to access array[1]. For someone looking at the configuration, the numbers themselves will be almost meaningless ("BasecampFieldIds? Why are there two? What do they correspond to?")
4. Less important, but worth mentioning: try to avoid setting global JavaScript properties. @lshearer is a great resource to answer questions about good JavaScript practices.

I'd like to see you get rid of all ConfigurationManager references in the project and move them into the Mongo database and the related configuration class. I can answer questions on that. I'm thinking the current errors on the production system will go away if you do this, too. :smiley: