Managing wetkit releases and updates

We have a Drupal installation based on wetkit which has been customized with a few extra and custom modules by contractors and is now severely outdated (still has Panopoly, Core is oudated, etc.). The version I'm supposed to work with is located on a server to which I have no direct access where there is a requirement to manage updates manually and where there is several organization specific setups, like running Drupal on one Windows Server machine with IIS, Active Directory SSO integration, a separate MySQL server on Linux, and a Solr search hosted on yet another machine.

In this scenario, it is impossible for me, the main developer of the Drupal implementation, to get a copy and/or access to this environment, making it impossible, for instance, to use Git or another versioning system to manage releases. There's no real dev environment; I have to work with my own installation, which differs in setup, and then roll in the features live.

Considering this:

How would you go about updating the distribution?
Should the udpates be made through Drupal, or should we only use release versions of the distribution?
What happens when you do Drupal updates. How can I know removing Panopoly will not screw up something in my database?
How can I make sense of this restricted environment. Is it safe to say I can develop a module or some functionality through a setup which is not the same as the production one and then simply push it there? Is there a significant incentive to matching environments I could bring up to convince management to implement it a certain way / give me access to a development environment?

To See Full Issue Go to: https://drupal.org/node/2127181

Component: Release Management
Version: 7.x-1.x-dev
Priority: Minor
Category: Support request

StephenOTT / Test3

Managing wetkit releases and updates #15